15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


Beware MFC DDE support is broken

Dave Kolb -- sasdxk@unx.sas.com
Thursday, June 27, 1996

VC++ 4.1/Windows NT 4.0 beta 2 and Windows 95 w/ SP2

MFC MDI apps have built in DDE support for the Explorer that is poorly coded
and also broke. Try MULTIPAD for instance and use the Explorer to RMB open a
file then RMB print a file then RMB open another. The app dissapears off the
screen and taskbar. RMB open another and it's back. Also, the MFC DDE code
does not check that the app was already visible and tries to hide it without
trying to restore it (and actually does neither if it's already running) and
does not check that the file was already open and closes it after printing.

Some specific problems I noticed were: docmgr.cpp/OnDDECommand line 546
improperly assigns m_nCmdShow from the ptr m_pCmdInfo with a forced cast
(usually always a bad idea) and line 629 sets SW_HIDE but never resets it
and never reshows the window till the next open which then hides the app at
the wrong time.

I am circumventing the app hiding by overriding CWinApp::OnDDECommand by
save/restoring m_nCmdShow myself for now around the base method call.

I have called this into Microsoft support as a problem and they left a msg
that they coded a CDocManager circumvention that I don't have but likely
will later today.

Dave Kolb                     Compuserve: 72410,407@compuserve.com
SAS Institute, Inc.           EMAIL:      sasdxk@unx.sas.com
SAS Campus Drive - R3282      Phone:      (919) 677-8000 x6827
Cary, NC  27513-2414 USA      FAX:        (919) 677-8123




Roger Onslow -- Roger_Onslow@compsys.com.au
Monday, July 08, 1996

[Mini-digest: 2 responses]

Dave,

>MFC MDI apps have built in DDE support for the Explorer that is poorly coded
>and also broke.
>...
>I have called this into Microsoft support as a problem and they left a msg
>that they coded a CDocManager circumvention that I don't have but likely
>will later today.

Interesting -- thanks for the warning.

Does this bug also apply to SDI apps?
Can you please put the fix from MS up on the mailing list when you get it?
Also the fix you used in your app?

Again, thanks for sharing this with us.

           /|\        Roger Onslow
      ____|_|.\       ============
    _/.........\Senior Software Engineer
   /CCC.SSS..A..\
  /CC..SS...A.A..\   Computer
 /.CC...SS..AAA...\       Systems
/\.CC....SSAA.AA../            Australia
\ \.CCCSSS.AA.AA_/
 \ \...........//      Ph: +61 49 577155
  \ \...._____//      Fax: +61 49 675554
   \ \__|_/\_//    RogerO@compsys.com.au
    \/_/  \//


-----From: Dave Kolb 

Here is my fix for the disappearing app problem. I never got the MSFT fix so
will have to give them a call. MSFT made a new CDocManager class and fixed
the bad methods but I'm not sure how they managed to wire it in since it is
not used directly by the user. There is an instance ptr in CWinApp they may
have reset perhaps.

Dave Kolb

BOOL CsvApp::OnDDECommand( LPTSTR lpszCommand )
{
	int nCmdShow;
	BOOL rc;

	// NOTRES save show flag since CDocManager::OnDDECommand screws it up for
printing
	nCmdShow = m_nCmdShow;
	
	rc = CWinApp::OnDDECommand(lpszCommand);

	// NOTRES restore show flag since CDocManager::OnDDECommand screws it up
for printing
	m_nCmdShow = nCmdShow;

	return rc;
}

Dave Kolb                     Compuserve: 72410,407@compuserve.com
SAS Institute, Inc.           EMAIL:      sasdxk@unx.sas.com
SAS Campus Drive - R3282      Phone:      (919) 677-8000 x6827
Cary, NC  27513-2414 USA      FAX:        (919) 677-8123





| Вернуться в корень Архива |