BUG: CFrameWnd::OnDDEExecute MFC 7.1

  • Thread starter Thread starter Marc Gustafson
  • Start date Start date
M

Marc Gustafson

This function is executed when a application file is
double-clicked to open in a VC++ application.
Specifically, this function is enabled by
RegisterShellFileTypes () in the application's
InitInstance.
However, under MFC 7.1 for VC++ .NET 2003,
CFrameWnd::OnDDEExecute has a bug that repeatedly
generates this error message in the debugger

Error: failed to execute DDE command ''.

Therefore, the problem is that the command is not being
propagated properly to this function, since the string
should be something like
'[open("C:\YourFileNameHere")]'
rather than the empty string
''

Examining the code for this function in more detail, we
can see the bug here:

LPCTSTR lpsz = (LPCTSTR)GlobalLock(hData);
int commandLength = lstrlen(lpsz);
if (commandLength >= _countof(szCommand))
{
// The command would be truncated. This
could be a security problem
TRACE0("Warning: Command was ignored
because it was too long.\n");
return 0;
}
GlobalUnlock(hData);

The data string '[open("C:\YourFileNameHere")]' is stored
in the LPCTSTR lpsz. Then a check is done to make sure
that the length of this string is not longer than the new
buffer szCommand. However, the string is never copied in
szCommand, and the data is effectively released by
GlobalUnlock! Then when this command is executed

if (!AfxGetApp()->OnDDECommand(szCommand))

szCommand is empty, and the error is generated.

Hopefully, Microsoft will address this bug and issue a
patch. Please respond to this posting to indicate if this
problem is being addressed.

Thank you,
Marc Gustafson
 
Marc said:
This function is executed when a application file is
double-clicked to open in a VC++ application.
Specifically, this function is enabled by
RegisterShellFileTypes () in the application's
InitInstance.
However, under MFC 7.1 for VC++ .NET 2003,
CFrameWnd::OnDDEExecute has a bug that repeatedly
generates this error message in the debugger

Error: failed to execute DDE command ''.

Therefore, the problem is that the command is not being
propagated properly to this function, since the string
should be something like
'[open("C:\YourFileNameHere")]'
rather than the empty string
''

Examining the code for this function in more detail, we
can see the bug here:

LPCTSTR lpsz = (LPCTSTR)GlobalLock(hData);
int commandLength = lstrlen(lpsz);
if (commandLength >= _countof(szCommand))
{
// The command would be truncated. This
could be a security problem
TRACE0("Warning: Command was ignored
because it was too long.\n");
return 0;
}
GlobalUnlock(hData);

The data string '[open("C:\YourFileNameHere")]' is stored
in the LPCTSTR lpsz. Then a check is done to make sure
that the length of this string is not longer than the new
buffer szCommand. However, the string is never copied in
szCommand, and the data is effectively released by
GlobalUnlock! Then when this command is executed

if (!AfxGetApp()->OnDDECommand(szCommand))

szCommand is empty, and the error is generated.

Hopefully, Microsoft will address this bug and issue a
patch. Please respond to this posting to indicate if this
problem is being addressed.
Click to expand...

Known problem. The solution I've seen recommended is to handle
WM_DDE_EXECUTE in your main frame window, copy the code from the MFC source,
and adding the missing line.
 
Hi Marc,

Thank you very much for your post and feedback on the product.

Doug is right. This is a know issue. To workaround it, we could handle
WM_DDE_EXECUTE and add:

* Problem: CFrameWnd::OnDDEExecute in VC7/8 omitted the following 2 lines:
LPCTSTR lpsz = (LPCTSTR)GlobalLock(hData);
lstrcpyn(szCommand, lpsz, _countof(szCommand));
* Solution: add the missing lines (or better, use strings).

The issue will be fixed in VS.NET 2003 SP1.

If you have follow up questions, please post here.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! ¨C www.microsoft.com/security
This posting is provided ¡°as is¡± with no warranties and confers no rights.
 
Handled WM_DDE_EXECUTE in my MainFrame class and
implemented this work-around solution.
It's good to know that it will be fixed in SP1.

Thanks,
Marc
 
Hi Marc,

Thanks a lot for your feedback! :-)

Have a nice day!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! ¨C www.microsoft.com/security
This posting is provided ¡°as is¡± with no warranties and confers no rights.
 
Back
Top