C / C++ / MFC

Re: Migrating from Visual Studio 2005 to Visual Studio 2015 Still Tries to Link MFC 8

31-Dec-16 3:04

As Richard said you are linking the lib files manually of which there are only three ways to do

1.) #pragma comment(lib, "mfc80d.lib") .. given you have searched for mfc80d.lib it can only be a macro name so just search for "#pragma comment". Something stupid like #pragma comment(lib, "mfc" _MFC_FILENAME_VER "d.lib")
2.) Under project properties Linker->Input->Additional Dependencies .. look for the name
3.) Under project properties Linker->command Line->Additional Options .. look for name (its usually blank)

Has to be in one of those 3.

daouuid.lib is an obsolete XP service pack 2 library file it wont be available in none XP builds. There is an XP build option on VS2015 it will probably link in that build.

In vino veritas

modified 31-Dec-16 9:14am.

SP Chapman3-Jan-17 6:06

SP Chapman

3-Jan-17 6:06

I did, indeed, find "#pragma comment(lib, "mfc" _MFC_FILENAME_VER "d.lib")" in Afx.h under C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include\afx.h. However, _MFC_FILENAME_VER is declared by:

#ifndef _MFC_FILENAME_VER
#define _MFC_FILENAME_VER "140"
#endif

in afxver.h.

I tried adding the declaration explicitly to the project StdAfx.h file but it made no change to the linker error. "#pragma comment" is not found anywhere in the project itself. There are no explicit references to MFC 80 in the linker settings.

Once I get a few beginning of the year things cleaned up, I am going to try a release build.

As for DAO, I am no longer targeting XP or Vista. I will need to fight that battle once I win this one.

Thanks for your advice. I will continue to tilt at this as I may, but I may be stuck with VS2005 compilations for some time.

Happy New Year to you.

FF

Re: Migrating from Visual Studio 2005 to Visual Studio 2015 Still Tries to Link MFC 8

leon de boer8-Jan-17 3:47

Re: Migrating from Visual Studio 2005 to Visual Studio 2015 Still Tries to Link MFC 8

8-Jan-17 3:47

The simpler way is simply delete all the project and solution files and set them up from scratch using the create project from existing code option on the menu Smile | :)

In vino veritas

SP Chapman9-Jan-17 5:44

SP Chapman

9-Jan-17 5:44

Yes, I am just about to that point. I have been redirecting my energies the past week or so, so I haven't had at this problem very much. I was actually considering moving the older library files into the project just to get things to link. I haven't tried a release build, yet, but if the release build does not link, moving the older files may resolve the problem but then cause a distribution nightmare, requiring 2005 and 2015 manifests. A new project with old code and resource files is a much better approach.

Thanks for your time

SPC

Re: Migrating from Visual Studio 2005 to Visual Studio 2015 Still Tries to Link MFC 8

Stefan_Lang27-Jan-17 2:31

Stefan_Lang

27-Jan-17 2:31

If any of your projects links another 3rd party library, that library, too, needs to be compiled with VS2015 - otherwise it will attract old MFC libs.

There's a very useful tool called depends that can show for each executable or dll what other binaries it depends on. You can use it to locate the dependency path that is responsible for attracting mfc80.dll. See Dependency Walker (depends.exe) Home Page[^]

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Re: Migrating from Visual Studio 2005 to Visual Studio 2015 Still Tries to Link MFC 8

SP Chapman27-Jan-17 5:26

SP Chapman

27-Jan-17 5:26

Hi Stefan...

Thanks for the observation. And yes, I have been pursuing this same line. I am having trouble getting a reply from the the third party vendor. Meanwhile, other matters have pushed this to the side, so I haven't been giving it a lot of attention.

I will leave this reply up for the weekend, then remove/resolve this message.

Thanks again and have a great weekend.

SPC

WM_SHOWWINDOW not called

_Flaviu29-Dec-16 9:56

29-Dec-16 9:56

Hi. I have noticed something interesting: in an MDI app, I handled ON_WM_SHOWWINDOW() in CChildFrame, just like this:

C++

void CChildFrame::OnShowWindow(BOOL bShow, UINT nStatus) 
{
	CMDIChildWnd::OnShowWindow(bShow, nStatus);

	// TODO: Add your message handler code here
TRACE("%d\n", bShow);
}

and whenever I create a new childframe (several times), I see the TRACE, so, this message are handled.

But, if I maximize the child frame, the next childframes opened are not handle this message at all ... why ? Strange ... once I maximize the childframe, whenever I create the new childframes, this message are not handled (I mean, I don't see any TRACE) ! If I restore the child frame, next child open are handle this message ... why ?

Thank for any explanation, words, everything !

But,

Richard MacCutchan29-Dec-16 21:38

Richard MacCutchan

29-Dec-16 21:38

See the Remarks section at https://msdn.microsoft.com/en-us/library/windows/desktop/ms632645(v=vs.85).aspx.

_Flaviu29-Dec-16 21:58

29-Dec-16 21:58

Thank you ... I wonder how to know for sure when a childframe have been created ... I will do some tests.

leon de boer29-Dec-16 22:33

29-Dec-16 22:33

Same way as your last question handle the WM_CREATE message of the child window (or WM_MDICREATE of the parent MDICLIENT) and you know when it's created.

It's a basic thing if you want to know absolutely about something (without delay) then insert code in that handler instead of trying to determine it from a parent or associated window where the message chain gets involved. It's easier and safer than the alternatives.

The other key things with MDI's is children will by default be handled by DefMDIChildProc and be inside an MDIClient window (which is like an invisible window that sits inside an normal window) for them to operate correctly. So basically your app window contains an MDICLient, and the MDICLient contains the MDI children. So be careful the children are not actually children of the APP window as such. If you try to insert an MDIChild directly into a normal window it won't operate correctly they must be in an invisible MDIClient window pane.

In vino veritas

modified 30-Dec-16 4:54am.

_Flaviu29-Dec-16 23:36

29-Dec-16 23:36

Kindly thank you for your information. Actually I want to setup the window placement which have been saved in CChildFrame::OnDestroy():

C++

void CChildFrame::OnDestroy() 
{
	CMDIChildWnd::OnDestroy();

	// TODO: Add your message handler code here

	WINDOWPLACEMENT wp;
	GetWindowPlacement(&wp);
	if(wp.showCmd == SW_SHOWMINIMIZED)
		wp.showCmd = SW_SHOWMAXIMIZED;
	AfxGetApp()->WriteProfileBinary(_T("Settings"), _T("WindowPlacementChild"), (LPBYTE)&wp, sizeof(wp));
}

and previously I setup the window placement on first CChildFrame::OnShowWindow call:

C++

void CChildFrame::OnShowWindow(BOOL bShow, UINT nStatus) 
{
	CMDIChildWnd::OnShowWindow(bShow, nStatus);

	// TODO: Add your message handler code here
	if(bShow && ! IsWindowVisible() && m_bOnce)
	{
		m_bOnce = FALSE;
		UINT nBytes = 0;
		WINDOWPLACEMENT* lwp;
		if(AfxGetApp()->GetProfileBinary(_T("Settings"), _T("WindowPlacementChild"), (LPBYTE*)&lwp, &nBytes))
			SetWindowPlacement(lwp);
		delete []lwp;
	}
}

but I discovered that this handler are not called when the previous child frame open are maximized ... where should be the proper place to set the child frame placement on opening ?

modified 30-Dec-16 6:32am.

_Flaviu29-Dec-16 23:37

29-Dec-16 23:37

"Same way as your last question handle the WM_CREATE message of the child window (or WM_MDICREATE of the parent MDICLIENT) and you know when it's created"

You mean on creation of child frame ?

_Flaviu30-Dec-16 1:07

30-Dec-16 1:07

I don't think that WM_CREATE is the right place to set child frame placement:

C++

int CChildFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) 
{
	if (CMDIChildWnd::OnCreate(lpCreateStruct) == -1)
		return -1;

	// TODO: Add your specialized creation code here

	UINT nBytes = 0;
	WINDOWPLACEMENT* lwp;
	if(AfxGetApp()->GetProfileBinary(_T("Settings"), _T("WindowPlacementChild"), (LPBYTE*)&lwp, &nBytes))
		SetWindowPlacement(lwp);
	delete []lwp;

	return 0;
}

Once as I put here this code, I have not child frame system menu anymore.

leon de boer30-Dec-16 3:15

30-Dec-16 3:15

You are returning zero and exiting ... try breaking and dropping thru to the default handler. I warned you about needing the default handler Smile | :)

MFC is always funky with its wrapper around the raw API so it's probably return one or some strange value to continue thru to the default handler.

If all you are trying to do is reset the window placement use WM_WINDOWPOSCHANGED it is always called from WM_CREATE anyhow.

I have did a sample with a different OPENGL in each MDICHILD here and the handler is in the text discussion even
Native Win32 API OpenGL Tutorial - Part 2[^]

You can ignore the OpenGL itself but the MDI does everything you wanted, it resize, minimizes, maximizes. tiles, cascade etc and you can see the messages I handled.

In vino veritas

modified 30-Dec-16 9:30am.

_Flaviu30-Dec-16 3:18

30-Dec-16 3:18

I guess I have found the right place to restore the child frame window placement:

C++

void CChildFrame::ActivateFrame(int nCmdShow) 
{
	// TODO: Add your specialized code here and/or call the base class

	CMDIChildWnd::ActivateFrame(nCmdShow);

	if(! m_bOnce)
		return;

	m_bOnce = FALSE;
	UINT nBytes = 0;
	WINDOWPLACEMENT* lwp;
	if(AfxGetApp()->GetProfileBinary(_T("Settings"), _T("WindowPlacementChild"), (LPBYTE*)&lwp, &nBytes))
		SetWindowPlacement(lwp);
	delete []lwp;
}

leon de boer30-Dec-16 3:38

30-Dec-16 3:38

That should only work for the focused child window. Unless MFC overrides windows and activates each window in Z order.

Windows normally when it brings up a group of children will only activate them along the focus chain in non MFC. Its very specific on the API.
WM_ACTIVATE message (Windows)[^]
Sent to both the window being activated and the window being deactivated. If the windows use the same input queue, the message is sent synchronously, first to the window procedure of the top-level window being deactivated, then to the window procedure of the top-level window being activated.

By default each window will call down to it's parent to make sure it is activated in a direct line along the focus chain. You can basically follow the activation chain upwards from the application window and arrive at the focus window which is how keyboard messages etc find there way to the right window. So at no stage should two MDI children be active and the active one generally paints it's frame a different colour and brings itself to top (that is the default behviour). The only other child window that would get a normal windows API message is the one losing the focus chain. However if you had 3 children there would always be one window that would never get an activation message no matter what you did as it will neither be gaining or losing activation/focus chain.

I would not expect that behaviour on MFC unless it does it's own thing and does a lot of repainting that is totally not done on actual windows API. Given the weird nature of that call with nCmdShow that is possible, all be it a bit naft and horrible hack.

The WM_WINDOWPOSCHANGED I gave you does go to each and every child which is also why they tell you that you probably want to override it
WM_WINDOWPOSCHANGED message (Windows)[^]
By default, the DefWindowProc function sends the WM_SIZE and WM_MOVE messages to the window. The WM_SIZE and WM_MOVE messages are not sent if an application handles the WM_WINDOWPOSCHANGED message without calling DefWindowProc. It is more efficient to perform any move or size change processing during the WM_WINDOWPOSCHANGED message without calling DefWindowProc.

In vino veritas

modified 30-Dec-16 10:01am.

_Flaviu31-Dec-16 11:49

31-Dec-16 11:49

Thank you for explanation. I have noticed something weird also: I open two child frames. Both of them are maximized. I have following code:

C++

void CChildFrame::OnDestroy() 
{
	WINDOWPLACEMENT wp;
	GetWindowPlacement(&wp);
TRACE("Window state: %d\n", wp.showCmd);

	CMDIChildWnd::OnDestroy();

	// TODO: Add your message handler code here
}

I repeat: both of child frames are maximized. I close one of them: the result of TRACE are

C++

Window state: 1

which mean SW_SHOWNORMAL, not maximized.
Then, I close the next child frame opened, the result is:

C++

Window state: 3

which mean that is SW_MAXIMIZED .... although all child frame opened were maximized, the only last one tell me that was maximized ... rest of them tell me that was SSHOWNORMAL ? Why ?

leon de boer5-Jan-17 22:05

5-Jan-17 22:05

When you close one child, the focus first shifts to the next child window. So at that point the window is not technically maximized, in that maximized is more than about size it is about focus as well. Think about the pesky icons placed in the parent frame that is the window that is maximized.

So technically you can't have two child windows WM_MAXIMIZED you can have two of them maximum size but that isn't the same thing Smile | :)

In vino veritas

_Flaviu8-Jan-17 20:39