Active Desktop odd behaviour only with the exe

[tedsmith]

I have written a vb6 app that uses a few APIs using User32, Kernal32 to get the computer name and Avicap32 to capture webcam frames.
It functions perfectly well however when I run the complied exe, after a while, when I close it, I see the desktop is all white with a "restore your active desktop" button.

This does not happen when I run it in the VB editor.

Any clues?

 

[dilettante]

Same behavior if compiled to p-code?

 

[tedsmith]

Sorry but I have never compiled to P=code because I don't really understand what the difference is apart from what's in the help.
The documentation describes what it is but does not explain it or if there are any benefits to be gained by P-code.

What would be the advantages and disadvantages of using P-code and what would be the conclusion if it fixed the problem?

 

[dilettante]

One advantage is that it compiles to a smaller executable and in many cases the performance penalty isn't significant.

I only asked because there are things that are handled slightly differently in p-code vs. native code. If it worked compiled to p-code your problem would be related to that rather than something about the environment inside the IDE.

I don't have a list of differences. Microsoft says INFO: Differences of Behavior in Debug Mode and Compile Mode but there are more than this implies. For one thing there are native code compilation bugs in API call parameter passing, though you can usually track these down. Typically these seem to be problems passing a VB literal value (like 1&) to a ByVal parameter. Just using a local variable set to 1 and passing that fixes it. There are also issues with calling a CDECL entrypoint in a DLL that you can get around in one mode and not the other.

I suspect that implicit type coercion might be different in a few edge cases too. I've gotten into the habit of using CInt(), CLng(), CSng(), etc. very liberally whenever I know I want conversion.

Your problem sounds like it might have something to do with passing and processing window messages, but that's just a wild guess. The message pump and WndProc linkage is slightly different in the IDE vs. native code. I can't say whether p-code will work exactly like the IDE but it ought to be close.

 

[dilettante]

Here's another difference: BUG: Order of Evaluation Change Between Native Code and P- Code.

Also Bug Proofing Visual Basic: Discussion: Performance Tips talks a little about reasons to compile to p-code. For anything computation-bound you could always compile a separate native-code DLL and use that.