I have a MFC Dialog based application, and when I get a certain user-defined windows message I do the following:
ShellExecute(NULL,NULL,(const char*)WLC.Settings.FinishURL, NULL,NULL,SW_SHOW);
That FinishURL is just a basic CString. Anyway, this causes Dev Studio 2008 to crash. I can rum my app stand alone by going into the build folder and running the debug or release version and it runs just fine.
I know this is a long shot, but does anyone know why this is crashing Dev Studio 2008 and how I can fix it? I have since added some #ifndef DEBUG around it, but I would rather it actually execute while I am testing.
Could you give us some more information? Like what kind of 'crash' are you getting and what the call stack looks like? Have you tried debugging to see if any of the variables contain garbage data when making the call?
Last edited by Access_Denied; June 21st, 2012 at 03:46 PM.
2. To make sure I get the char * type of pointer. CString does this with a cast. I just want to make sure I end up with a pointer to a buffer of *char and not a reference to an object.
3. I am using ANSI, the build works fine, the app runs until it hits that statement then Dev Studio crashes. Not my App, but the development environment.
4. Message Handler hook?
5. It constains, "https://www.google.com". You can launch URLs this way and it will use the default system web browser.
If these do not crash, then the suspicion is that you've corrupted the CString object in some way, or the CString doesn't contain the string you say it contains. If the "whatever" version crashes, then there still is a suspicion of corruption (since CString uses reference counting).
I can rum my app stand alone by going into the build folder and running the debug or release version and it runs just fine
Means very little, seriously. Many buggy app can "run fine" when run under one circumstances, but when run under the debugger, or another computer, then all heck breaks loose. C++ isn't Java or C#, where if you make a mistake, you're guaranteed some sort of diagnostic to be produced.
Last edited by Paul McKenzie; June 21st, 2012 at 07:51 PM.
and this also crashes Visual Studio 2008. Putting in the string directly in place of the CString works without a crash.
If the build is Unicode, those casts are incorrect. As a matter of fact, why are you doing all of those C-style casts to begin with?
Any time I see casting all over the place like that, it gives the indication that the code would never have compiled unless you forced the compiler to keep quiet by casting. So to be honest with you, I am not surprised the call crashes or the string being pointed to is not correct.
The ShellExecute function takes LPCTSTR as the string parameters, not const char*. This very simple example should have worked:
The reason why you should try this with an untouched, new program is because CString can get corrupted due to it being a reference counted type. If you've messed up the reference counting in some way, then all bets are off.