OpenEuphoria

2. Re: URLDownloadToFile call back?

• Posted by Robert Craig <rds at RapidEuphoria.com> Apr 30, 2005
• 793 views

Greg Haberek wrote:
> Attention C++ programmers! Help me make this work!
> 
> I want to use the call back feature of URLDownloadToFile. Apparently I
> need to setup a IBindStatusCallback interface so the function can call
> my IBindStatusCallback::OnProgress method. I know jack about C++ so I
> need to be able to do this in Euphoria.
> 
> ~Greg
> 
> P.S. Why can't this just call a normal call back funtion like 90% of
> the rest of the Windows API?

Mic has something in the Archive that might help:

http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=urldownload

I can see that he uses callbacks somehow, but I'm not
sure if it's exactly what you are looking for.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

4. Re: URLDownloadToFile call back?

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Apr 30, 2005
• 807 views

Greg Haberek wrote:
> 
> Attention C++ programmers! Help me make this work!
> 
> I want to use the call back feature of URLDownloadToFile. Apparently I
> need to setup a IBindStatusCallback interface so the function can call
> my IBindStatusCallback::OnProgress method. I know jack about C++ so I
> need to be able to do this in Euphoria.
> 

You've now entered the COM zone.  Technically, you need to set up the entire
interface, including the IUnknown (which is part of every interface).  So
by default, you'll need these three up front:

QueryInterface
AddRef
Release

You have to remember to add a 'this' parameter to your fuctions (C++ does
this implicitly).  I'd recommend creating at least empty functions for 
each of the interface functions, because if windows tries to call one, and
it's not defined, you will crash.  Basically, you're going to create an 
array of pointers to your functions (i.e., callbacks) in memory, and then
create another pointer to point to the table (a VTable--virtual table).

So, here's sorta what you need to do:

atom vtable
vtable = allocate( 44 ) -- there are 11 functions in this interface
                        -- see below for the definitions and vtable
                        -- order
poke4( vtable, my_callbacks )  -- I'm assuming you've created the functions
                               -- elsewhere and put the callbacks into
                               -- a sequence: my_callbacks
atom my_ibindstatuscallback
my_ibindstatuscallback = allocate( 4 )
poke4( my_ibindstatuscallback, vtable )  -- now you should be able to pass
                                         -- my_ibindstatuscallback to 
                                         -- URLDownloadToFile, and your
                                         -- functions should be called

 From the urlmon.h header: 
http://doc.ddart.net/msdn/header/include/urlmon.h.html 
(remember to add query interface, add ref and release--here's how
I have them defined in EuCOM--take a look in eucom.ew for the full
implementations):

-- the iid's are sequences, because I'm usually getting these through
 -- a dispinterface, where I've already converted the IID from a poiner
 -- to a sequence:
global function i_query_interface( atom this, sequence iid, atom ppv )
global function i_add_ref( atom this, sequence iid )
global function i_release( atom this, sequence iid )

    IBindStatusCallback : public IUnknown
    {
    public:
        virtual HRESULT STDMETHODCALLTYPE OnStartBinding( 
            /* [in] */ DWORD dwReserved,
            /* [in] */ IBinding __RPC_FAR *pib) = 0;
        
        virtual HRESULT STDMETHODCALLTYPE GetPriority( 
            /* [out] */ LONG __RPC_FAR *pnPriority) = 0;
        
        virtual HRESULT STDMETHODCALLTYPE OnLowResource( 
            /* [in] */ DWORD reserved) = 0;
        
        virtual HRESULT STDMETHODCALLTYPE OnProgress( 
            /* [in] */ ULONG ulProgress,
            /* [in] */ ULONG ulProgressMax,
            /* [in] */ ULONG ulStatusCode,
            /* [in] */ LPCWSTR szStatusText) = 0;
        
        virtual HRESULT STDMETHODCALLTYPE OnStopBinding( 
            /* [in] */ HRESULT hresult,
            /* [unique][in] */ LPCWSTR szError) = 0;
        
        virtual /* [local] */ HRESULT STDMETHODCALLTYPE GetBindInfo( 
            /* [out] */ DWORD __RPC_FAR *grfBINDF,
            /* [unique][out][in] */ BINDINFO __RPC_FAR *pbindinfo) = 0;
        
        virtual /* [local] */ HRESULT STDMETHODCALLTYPE OnDataAvailable( 
            /* [in] */ DWORD grfBSCF,
            /* [in] */ DWORD dwSize,
            /* [in] */ FORMATETC __RPC_FAR *pformatetc,
            /* [in] */ STGMEDIUM __RPC_FAR *pstgmed) = 0;
        
        virtual HRESULT STDMETHODCALLTYPE OnObjectAvailable( 
            /* [in] */ REFIID riid,
            /* [iid_is][in] */ IUnknown __RPC_FAR *punk) = 0;
        
    };

6. Re: URLDownloadToFile call back?

• Posted by Jay <jgbetzold at yahoo.com> May 02, 2005
• 791 views

So apparently the OnProgress() (in urlmon.ew) function in the URLMON.zip found
 in the archive doesn't work?  I messed with it some, OnProgress() only gets
 called a total of 4 times during the whole process of downloading a file.  
The progress details are only available after the download completes.

I'm I understanding this correctly? Or Am I totally missing the boat?

8. Re: URLDownloadToFile call back?

• Posted by Jay <jgbetzold at yahoo.com> May 03, 2005
• 778 views

Yep!  You're right it does work!  Like a charm.  Thanks much.

So what does the code that Matt Lewis talks about in this thread 
do that urlmon.ew doesn't?

10. Re: URLDownloadToFile call back?

• Posted by Jay <jgbetzold at yahoo.com> May 03, 2005
• 786 views

Greg Haberek wrote:
> 
> > So what does the code that Matt Lewis talks about in this thread
> > do that urlmon.ew doesn't?
> 
> Well, since URLDownloadToFile is a COM-based routine, it is expecting
> to see a series of call-back routines, rather than just one. These
> call-back pointers are in a COM structure in memory. Matt was
> explaining how to setup this structure as well as which routines are
> called most often.
> 
> ~Greg
> 
> 

Oh... Looks like I've got a lot more contemplating to do.  

Thanks much for the info.

The other cal-back routines provide more/better error checking or maybe
better control of the data transfer?