Thanks for all the input, everyone. I'm currently trying out AppVerifier, something I wasn't previously aware of. It helped me figure out that there's a buried call to LoadLibrary() within a DllMain() and I'm just testing now to see if that's our issue.
That was it! We had a DLL unrelated to C++/CLI that was triggering a buried LoadLibrary() within its DllMain. Once removed, it's running fine. Talk about a red herring: it had nothing to do with C++/CLI, it just happened that by linking in that project, it pushed the app over the edge (but only in Debug and only in Win7). Nasty. It's a problem that's been plaguing us for months (but we were able to avoid it up until recently).
Thanks John for suggesting Application Verifier. Of course it didn't say "hey, this is wrong", but it did raise a flag in the DLL that was causing all the trouble and got me to focus on what was going on there. And that's exactly what I was looking for: not necessarily "tell me what's wrong with my code" but "how do I figure out what's wrong" and your suggestion helped nail it. And jschell, you were right about it being a bug in a different library whereas I had focused mainly on the C++/CLI project itself.
So thanks both to John Schroedl and to jschell for taking the time to respond, and to CodeProject for the great site. Much appreciated!
You want less than a millisecond? Our eyes cannot even see such speed. I do not know of anything that is faster than a timer in .NET... If your animation is not running to subtle, maybe you should look for smaller pixels or move the image by more than a dot instead of faster images.
No idea how to do that though. Just saying speed might not be the problem.
It's the only way I could get the collision working properly.
Obviously there are other ways. Here are a few ideas:
1. you don't need to draw anything to detect collisions, you could do it mathematically. That is modelling rather than animation. The model would generate the exact time and location of the collisions, animation would only be used to show the required frames.
2. even when collision detection is based on actual frames, you don't need to do it in real-time, you could calculate a number of new frames ahead of time (at the expense of more memory), and only show some of them, at the right pace.
Either way, you may choose to use floating-point for extra accuracy while calculating, and turn the relevant data into integers when calculating the actual frames.
Using Microsofts own ErrorExit code, I get the following message when CreateWindow returns NULL:
CreateWindow failed with error 0: the operation completed successfully
What confuses me is that the MSDN documentation on CreateWindow() says that if the function fails, it returns NULL and to use GetLastError to find out what it was. Well, it returns a null, but then reports that there is no error.
most if not all asynchronous events are handled by threads from the ThreadPool, not by the main thread, which means you can't touch GUI Controls right away from those handlers. You need to use InvokeRequired/Invoke, as I explain in this article[^] of mine (with C# and VB.NET examples, no C++/CLI, sorry, although the principles are exactly the same).
I want to statically link to a DLL, 'USBm.dll'(From USBMicro.com, a Hardware Interface that allows one to interface Relays etc. via a USB device they sell.)
I use VC5.00, so I require a Lib file to link with. My Compiler generates from a C-function named foo() the 'Decorated' name: '_foo' (it adds a leading Underscore). Unfortunately, the functions in the DLL are exported without such leading underscore. (The DLL has Borland Compiler suggestions in the way it was put together, I suspect that that's the compiler they (who wrote the DLL)use)
Normally I would create a DLL project with 'DoNothing' functions for each of the functions in the DLL Header. Discard the DLL, but, keep the Lib.
How do I convince My VC 5.00 compiler to emit obj files without decorating the function name. Is there an Obscure Command Line Switch
this sounds like a native C/C++ question, not a managed C++/CLI question, hence IMO you're in the wrong forum.
If your code is native C, I know of three ways to avoid C++ identifier decoration:
1. use the .c extension; that should be enough to tell the compiler it is not C++ code, it works for Visual Studio.
2. use some compiler switch, depends on the specific tool suite.
3. use the extern "C" keyword thingies, as in: