Drag&Drop works in IDE but crashes in EXE

I have a dialog that accepts a Drag&Drop of a file. I have it working, without a problem, in the IDE while testing. I can compile it without error. But when I try it from the EXE, it crashes the program.

Putting some windows prompts, I can see that it goes through the entire Drag&Drop routine without a problem but when that function apparently ends, that is where it crashes.

Here's the code:

Code:

---


class CMayDlg : public CDialog
{
// Construction
public:
        CString m_sFiles;
        void OnDropFiles(HDROP hdrop);
        ...

};





BEGIN_MESSAGE_MAP(CMyDlg, CDialog)
        //{{AFX_MSG_MAP(CMyDlg)
        ...
        ON_MESSAGE(WM_DROPFILES,OnDropFiles)
        //}}AFX_MSG_MAP
END_MESSAGE_MAP()

void CMyDlg::OnDropFiles(HDROP hdrop)
{
        UINT uNumFiles;
        TCHAR szNextFile[8096];

        UpdateData(true);

        // Get the # of files being dropped.
        uNumFiles = DragQueryFile ( hdrop, -1, NULL, 0 );


        m_sFiles="";

        for ( UINT uFile = 0; uFile < uNumFiles; uFile++ )
        {
                // Get the next filename from the HDROP info.
                if ( DragQueryFile ( hdrop, uFile, szNextFile, 8096 ) > 0 )
                {
                        m_sFiles += szNextFile;
                        m_sFiles +="\r\n";
                }
        }

        // Free up memory.
        DragFinish ( hdrop );
}

---

As said, I am at a loss. Not sure if this is a VC++ v6 bug or I accidentally overlooked something. Not sure how to debug this any further because I am leaving the "called" routine via the WM_MESSAGE. It's something after that that is crashing it appears.

Any help is greatly appreciated.

Quote:

---

Originally Posted by pbrama

I can compile it without error.

---

That doesn't mean the program will run correctly. All a successful compilation means is that the syntax is valid. It doesn't test whether the program will behave correctly.

Quote:

---

But when I try it from the EXE, it crashes the program.

---

Which means your program has a bug that's hidden when you run it in the IDE -- it still means your program is buggy.

Quote:

---

Putting some windows prompts,

---

What do you mean by "window prompts"? Message boxes?

If so, don't debug using MessageBox, as a MessageBox can interfere with the message pump of the application, and that in itself causes errors. Instead use TRACE() or OutputDebugString() to display messages.

Regards,

Paul McKenzie

I realize what a compile does as well as running an application. Yes, there is a bug... realize that too. Could be a coding bug, or could be a VC++ v6 bug.... not sure, as stated.

I tried messageboxes, and I tried trace... didn't matter, still crashes. Again, as stated, I put a messagebox OR a trace as the very last line of the OnDropFiles function... hits it just fine, then crashes after.

Also as stated, as I step through it with the IDE, it works fine. So there is something different between the IDE version and the compiled version. Again, I realize that is nothing new. BUT, I still am not 100% sure how to figure out what it is or where it is.

This is the very first time I have tried Drag&Drop. The Drag&Drop code, as listed, was the only thing I added to an application with hundreds of thousands of lines of code, that basically works... pretty thoroughly debugged.

If someone could look over my code and see if it "looks" correct... and / or can make a suggestion or too as to HOW to figure out what is going on, that would be greatly appreciated. The client would like to have this feature, I just have to figure out why, after reviewing many websites with sample code and such, this doesn't want to work correctly even though it appears it is correct.


Thanks

It might be some limit in VC6 CString. I don't have that installed anymore so I can't check the documentation. Does it crash regardless of the number of dropped files?

Another thought is what happens if DragQueryFile for some reason returns < 0 in the middle of the loop. If so you continue the loop like nothing has happened. Might be alrigth or not.

Thanks for your reply....

No it crashes whether or not it is a single file or multiple files. I checked all the variables with in the routine and they are in spec.... nothing odd.

Plus, it gets through the entire function, right past the DragFinish without erroring, nor does it error when stepping through in the IDE... works as expected even with about 20+ items dropped.

I am thinking it has something to do with the handling of the WM_MESSAGE because by all intensive purposes, that is what called this function to begin with. Just not sure "where" to look.

Quote:

---

Originally Posted by pbrama

I am thinking it has something to do with the handling of the WM_MESSAGE because by all intensive purposes, that is what called this function to begin with. Just not sure "where" to look.

---

What is WM_MESSAGE? :confused:
I never heard about this Windows message nor did I see it in your code snippets...

Whoops, sorry... was a bit tired from too many hours working....

what I meant to say was ON_MESSAGE with WM_DROPFILES.

Quote:

---

Originally Posted by pbrama

Thanks for your reply....

No it crashes whether or not it is a single file or multiple files. I checked all the variables with in the routine and they are in spec.... nothing odd.

Plus, it gets through the entire function, right past the DragFinish without erroring, nor does it error when stepping through in the IDE... works as expected even with about 20+ items dropped.

I am thinking it has something to do with the handling of the WM_MESSAGE because by all intensive purposes, that is what called this function to begin with. Just not sure "where" to look.

---

The grammar nazi in me feels compelled to point out the expression is "for all intents and purposes".

With that out of the way, try building a release version with debug information in it and debugging that if it still crashes. Even stepping through the debug code may show you something that's not obvious just from looking at the code.

Ok, I changed the settings in my IDE project and set NDEBUG and _DEBUG in the preprocessor. Now when I compile and step through the program in the IDE, I get it too to fail too with a message.

Code:

---

UNHANDLED EXCEPTION IN MYAPP.EXE (MFC42.DLL) 0xC0000005: ACCESS VIOLATION

---

This good in the fact that it now fails but unfortunately, I can't figure out where to go from here. Of course, unlike other errors, the IDE stepping usually shows an "area" of code that might have an issue or variable or something. With this, even when I hit OK, i end up in the "Disassembly" code which doesn't seem to help me much either. I am sure I am overlooking something or some call, but I am still at a loss.

Any suggestions on what I might need to look at or towards to get this to work. Just a recap, for whatever reason, it works in the IDE with the aforementioned changes NOT implemented.

Thanks again....

Quote:

---

Originally Posted by pbrama

Ok, I changed the settings in my IDE project and set NDEBUG and _DEBUG in the preprocessor.

---

You cannot use both NDEBUG and _DEBUG in the same build simultaneously. :cool:
It must be either NDEBUG (for release build) or_DEBUG (for debug one)

To avoid mistakes, use ClassWizard as much as possible to map messages.
It correctly maps WM_DROPFILES to void OnDropFiles(HDROP hDropInfo) using ON_WM_DROPFILES macro, and not ON_MESSAGE.
However, in case you don't find a message in the wizard's list or you have to map user-defined message, you can do this manually but you have to take care of correct message handler signature.
In case of ON_MESSAGE, the right handler function is LRESULT member_function(WPARAM, LPARAM).

It's a general issue in VS6.0 and older: you can map a wrong message handler, the code compiles then may run without problems in the debug build, but crashes for sure in the release.
That's because the framework makes somewhere a C-style cast for a pointer to member function (which finally is a pointer to your handler).
Newer versions of Visual Studio get rid of this issue by performing a static_cast. If you provide a wrong handler, the compiler gives an error and prevent headaches at run-time.

See also:

• What I already said about this issue here: http://forums.codeguru.com/showthrea...pe#post2069775
• Microsoft Suport: Incorrect Function Signatures May Cause Problems in Release

Quote:

---

Originally Posted by pbrama

Ok, I changed the settings in my IDE project and set NDEBUG and _DEBUG in the preprocessor. Now when I compile and step through the program in the IDE, I get it too to fail too with a message.

Code:

---

UNHANDLED EXCEPTION IN MYAPP.EXE (MFC42.DLL) 0xC0000005: ACCESS VIOLATION

---

This good in the fact that it now fails but unfortunately, I can't figure out where to go from here. Of course, unlike other errors, the IDE stepping usually shows an "area" of code that might have an issue or variable or something. With this, even when I hit OK, i end up in the "Disassembly" code which doesn't seem to help me much either. I am sure I am overlooking something or some call, but I am still at a loss.

Any suggestions on what I might need to look at or towards to get this to work. Just a recap, for whatever reason, it works in the IDE with the aforementioned changes NOT implemented.

Thanks again....

---

Did you try the call stack?

Quote:

---

Originally Posted by GCDEF

Did you try the call stack?

---

I can bet that shooting in the call stack is no longer necessary after correctly mapping the WM_DROPFILES message. ;)
See the OP code and my previous post.

I had a feeling I was dealing with another v6 issue, especially after getting help with my other issue with the SetSel. I always use the ClassWizard and am not 100% confident in "hand coding" what the CW doesn't handle well or at all.

This was the case with the DropFiles... the ClassWizard didn't have what I needed. After searching CodeGuru as well as Google, the code I found was what I used.

I changed the ON_MESSAGE to ON_WM_DROPFILES and that corrected the problem entirely.

Thanks again for everyone's help!!!

[QUOTE=pbrama;2070401]I had a feeling I was dealing with another v6 issue, especially after getting help with my other issue with the SetSel. I always use the ClassWizard and am not 100% confident in "hand coding" what the CW doesn't handle well or at all.

This was the case with the DropFiles... the ClassWizard didn't have what I needed. /QUOTE]I have no idea what you meant by "ClassWizard didn't have what I needed" :confused:

I've just tried to add a message handler for WM_DROPFILES in some VC++6.0 (with SP6) project and I have now the correct macro in the message map

Code:

---

ON_WM_DROPFILES()

---

as well as the correct handler:

Code:

---

void CSomeClass::OnDropFiles(HDROP hDropInfo)
{
        // TODO: Add your message handler code here and/or call default
       
        CSomeBaseClass::OnDropFiles(hDropInfo);
}

---

VS6.0 ClassWizard filters messages list for several types of classes (frame, dialog, etc).
For example, dropping files in a dialog has generally no much sense so, if your class is derived from CDialog, most possible WM_DROPFILES is missing from the list.

However, it is also possible you really have to do that, let's say drop an image file in the dialog's background (just an example).
This case, you have two choices:

1. Manually map WM_DROPFILES as already discussed and of course, again, beware of handler signature!
2. Prevent ClassWizard from filtering WM_DROPFILES message, as shown in this FAQ: How to show all messages in ClassWizard list?