If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: deployment catch 22

Do you ever get the feeling that you're wandering in circles?

Even though I finally got InternetOpen and InternetOpenUrl to work to download and read the update file from the website, it will not work in the Program Files (x86) directory and indicates Debugging from there indicates the InternetOpen operation completed successfully but the _fopen attempt failed. LastError == 'Access us denied'. Now, if you run this directly from the Program Files (x86) environment as 'Administrator', it works just fine to download and read the file. So it appears that I'm right back where I started from -- 'Catch 22'.

Is there no way for a non-administrator user to check for updates ?

At this point, I've given up and simply grayed out the menu option if the user is a non-administrator. What a whimp!

Re: deployment catch 22

Paul, I do try to use GetLastError whenever I encounter a runtime problem. But getting the error message out is never pleasant, a fact attested to by the many complaints voiced on the internet concerning the difficulties of using FormatErrorMessage.

Turns out that one can use the following to get the system error message much more easily using the little known _com_error class:
See:
Lookup and Display Win32/COM Error Strings With One Line of Code By Brian C Hart, 31 Dec 2005 http://www.codeproject.com/Articles/...trings-With-On
The _com_error class

Code:

_com_error::ErrorMessage();

However, the returned message with both methods often as not returns 'Unknown error' or the like and one is forced to look the error number returned by GetLastError up on the web. A minor but annoying inconvenience.

Re: deployment catch 22

Even though I finally got InternetOpen and InternetOpenUrl to work to download and read the update file from the website, it will not work in the Program Files (x86) directory

Mike, you definitely are going in circle. It's not a problem to read from internet being running in Program Files (x86) directory, but it's a problem to write somewhere under it. Just stop trying to write there, and you're fine. Read your version info to memory, parse it there in memory and ultimately download your binary to %TEMP% folder or elsewhere under user profile. Did it ever occurred to you that you're not obliged to write it next to your exe? And you always can make the path for writing to point wherever you want to?

Re: deployment catch 22

Thanks for that idea, Igor. It occurred to me also, but I was unable to get the text from memory -- the void * szTemp buffer made it quite difficult for me and my attempts to trace it returned gibberish. It appears that the sample code downloads the server file in 'chunks', so how to read it into and out of memory without writing it to disk.

Re: deployment catch 22

The last parameter denotes the number of bytes to set, not the number of VOID*'s.

Code:

memset(szTemp, 0x00, 1024 * sizeof(VOID*));

But given this, it's still wrong from the outset.

Reading the documentation to InternetReadFile states that you need a buffer that will receive the data. Just because the prototype shows LPVOID doesn't mean you declare a VOID pointer and pass it to the function. The pointer has to point somewhere, and your example doesn't do this.

Re: deployment catch 22

Thanks, Igor. Yours is a far more sophisticated approach than mine and seems to work quite nicely. I removed the single break point in your code, but it still hangs when I attempt to run in debug config and use Start Debug. But if I just use Start Without Debugging or Release config, no such problem occurs. I cannot find any error messages or hidden breakpoints, so I am puzzled as to this behaviour as I have not seen this before. Also, using Start Without Debugging while running dbgview.exe, it runs fine and there are no error messages or memory leaks detectable. Can you explain this behaviour?

In addition, I have encountered considerable difficulty in converting your code to Unicode. Specifically, I cannot get meaningful text from LPWSTR pContent.

Re: deployment catch 22

Thanks. I'll try that. Please note that I edited my last post regarding Unicode just as you posted your last comment.

When I use devenv ueberkrypt.exe from the VS command prompt, a new VS 2010 interface comes up containing the exe. When I use Start Debugging I get the same hang. I presume that I am using a build with debug capabilities because I'm not certain how to build the whole dialog-based app from the command prompt and it's already been built.