🚀 go-pugleaf

Mike Collins wrote:

>  My code is pretty straightforward (as shown below) but it seems to to 
>failing on the GetProcAddress.  Can anyone see where i'm going wrong:

You don't report failure to load the library.
Add failure code to show the szWNetPath.


>   // Dynamically Load WinINet.dll...
>   AnsiString szWINetPath = "";
>   szWINetPath.SetLength(MAX_PATH+1);

>   szWINetPath.SetLength(GetSystemDirectory(szWINetPath.c_str(), 
>szWINetPath.Length()));

I find that line confusing.
Also not sure if length isn't calculated before GetSystemDirectory
sets it?
Also, since everything in here uses cstrings, why not use cstrings
instead complicating things with  AnsiString?

	char  szWINetPath[MAX_PATH+1];
	GetSystemDirectory( szWINetPath,  MAX_PATH);
	lstrcat( szWINetPath, "\\wininet.dll");
	hINetDLL = LoadLibrary(szWINetPath);

	But, I'd prefer this:
	hINetDLL = LoadLibrary("wininet.dll");

BTW#2: AnsiString isn't an sz. Probably an 'as' or plain 's'.

>   szWINetPath = AnsiString(szWINetPath + "\\wininet.dll");
>   hINetDLL = LoadLibrary(szWINetPath.c_str());



>   // If ineternet connection established, then close it...
>   if (hINetHnd)
>      InternetCloseHandle(hINetHnd);
>
>   if (hINetDLL)
>      FreeLibrary(hINetDLL);

Proper use of flow control will eliminated those extra if()s at the
end...

   if (hINetDLL)
   {
         if (hINetHnd)
         {
	// use the internet
	// .....

	InternetCloseHandle(hINetHnd);
        }else{
	// handle hNet failure
         };

         FreeLibrary(hINetDLL);
   }else{
	//handle dll failure
   };

Hay Bob, thanks for the pointers.

1) I might not report load library failure but i test for it...  This is 
just work in progress code...

2) LoadLibrary works fine, the dll is being loaded - GetProcAddress seems to 
be failing to locate or load the functions.

3) As for :

szWINetPath.SetLength(MAX_PATH+1);
szWINetPath.SetLength(GetSystemDirectory(szWINetPath.c_str(), 
szWINetPath.Length()));

- I've used this 1000's of times without issue.  GetSystemDirectory returns 
the size of the returned string so it's perfect for setting the ansistring 
length when returned.

4)   >>BTW#2: AnsiString isn't an sz. Probably an 'as' or plain 's'.  - 
Point of conjections - old habits die hard - i'll always get pulled up about 
this - can't make my fingers type different.

5) >> Proper use of flow control will eliminated those extra if()s at the 
end... -  Work in progress - code isn't working yet so i'm not going to 
worry to much about slickness at this point.

Thanks again - any ideas why GetProc is failing???

Mike C

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 

"Mike Collins" <its@TheBottomOfThePost.com> wrote in message
news:44c3590d$1@newsgroups.borland.com...

> it seems to to failing on the GetProcAddress.

That is because you are loading the wrong function names to begin with  You
are not taking into account that some of the functions you are trying to use
have ASCII and Unicode variants available which have different exported
names.

> InternetOpen = (TInternetOpen)GetProcAddress(hINetDLL, "InternetOpen");

    #ifdef UNICODE
    InternetOpen = (TInternetOpen)GetProcAddress(hINetDLL, "InternetOpenW");
    #else
    InternetOpen = (TInternetOpen)GetProcAddress(hINetDLL, "InternetOpenA");
    #endif

> InternetConnect = (TInternetConnect)GetProcAddress(hINetDLL,
"InternetConnect");

    #ifdef UNICODE
    InternetConnect = (TInternetConnect)GetProcAddress(hINetDLL,
"InternetConnectW");
    #else
    InternetConnect = (TInternetConnect)GetProcAddress(hINetDLL,
"InternetConnectA");
    #endif

> hINetHnd = InternetOpen("KidSafe Live Update", 0, 0, 0, 0);

    hINetHnd = InternetOpen(TEXT("KidSafe Live Update"), 0, NULL, NULL, 0);

> HINTERNET hHTTPHnd = InternetConnect(hINetHnd,
> "www.softwareassociates.nu/", INTERNET_DEFAULT_HTTP_PORT,
> "", "", INTERNET_SERVICE_HTTP, 0, 0);

    HINTERNET hHTTPHnd = InternetConnect(hINetHnd,
TEXT("www.softwareassociates.nu/"), INTERNET_DEFAULT_HTTP_PORT, TEXT(""),
TEXT(""), INTERNET_SERVICE_HTTP, 0, 0);


Gambit

Ops, forgot that...

Normally when you call the api, the macro works it our for you i.e. either 
to call the ASCII or Unicode - I didn't realise that you had to specify this 
when calling GetProcAddress - is there not a standard InternetOpen which 
then resolves to either ASCII or Unicode - no real problems as long as it 
works :)

Also, out of interest, what is the exact purpose of the TEXT?

Many thanks and many steps further forward,

Mike C



"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:44c3c972$1@newsgroups.borland.com...
>
> "Mike Collins" <its@TheBottomOfThePost.com> wrote in message

"Mike Collins" <its@TheBottomOfThePost.com> wrote in message
news:44c3f241$1@newsgroups.borland.com...

> Normally when you call the api, the macro works it our for you i.e. either
> to call the ASCII or Unicode - I didn't realise that you had to specify
this
> when calling GetProcAddress

You have to specify an actual exported name, not the name that the
precompiler macros create for you.

> is there not a standard InternetOpen which then resolves to either
> ASCII or Unicode

No.  That would not be possible.  The whole reason for having A and W
versions of any given function in the first place is because LPTSTR and
LPCTSTR parameters are different - char* for Ansi and wchar_t* for Unicode -
depending on whether UNICODE is defined.  The two are not interchangable at
runtime.  The only reason you can write just InternetOpen() in your code
instead of having to specify InternetOpenA() and InternetOpenW() is because
of the use of precompiler macros that hide that detail from your code.  But
you can't ignore it when you decide to import functions manually instead of
letting the linker do it for you.

> Also, out of interest, what is the exact purpose of the TEXT?

It is a precompiler macro that defines string literals to either char* or
wchar_t* at compile time, depending on whether or not UNICODE is defined.


Gambit