MDI windows, MDIClient and mdiclient
Hi all, I am trying to make an application work under wine. The app is probably an MFC app, that defenitely uses MDI. The problem boils down to this - it tries to create an MDI window by doing SendMessageA to a message of type "WM_MDICREATE". Here's the catch - the class it wants to use is in Unicode. This fails for obvious reasons. I'm trying to find my way around the MDI setting, and phrase a regression test. However, I cannot seem to create the exact same circumstances. When looking at the original app using Spy++, I see that the application has a window from the very start of the app (long before it sends WM_MDICREATE), which does not appear to have WS_EX_MDICHILD set, but which has a child window of class "MDIClient". Running the same app in Wine using --debugmsg +win,+class, I can see that it asks to open a window of class "mdiclient". I do not, however, see anywhere that such a class was ever registered! Furthermore - the call succeeds. Can anyone enlighten me? Is this window necessary whenever an MDI is present? If so, what function do I use on the parent window to tell it that it is to be an MDI container? Many thanks, Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Shachar Shemesh wrote:
Hi all,
I am trying to make an application work under wine. The app is probably an MFC app, that defenitely uses MDI. The problem boils down to this - it tries to create an MDI window by doing SendMessageA to a message of type "WM_MDICREATE". Here's the catch - the class it wants to use is in Unicode. This fails for obvious reasons.
I'm trying to find my way around the MDI setting, and phrase a regression test. However, I cannot seem to create the exact same circumstances. When looking at the original app using Spy++, I see that the application has a window from the very start of the app (long before it sends WM_MDICREATE), which does not appear to have WS_EX_MDICHILD set, but which has a child window of class "MDIClient".
Running the same app in Wine using --debugmsg +win,+class, I can see that it asks to open a window of class "mdiclient". I do not, however, see anywhere that such a class was ever registered! Furthermore - the call succeeds.
Can anyone enlighten me? Is this window necessary whenever an MDI is present? If so, what function do I use on the parent window to tell it that it is to be an MDI container?
Many thanks,
Shachar
Hi all, I THINK I found the answer. I need to create a child window with the "MDICLIENT" class, and pass it a CreateClientStruct. I'm not sure what I need to put in the struct, but I'll guess I'll figure it out as I go along. Now the question - is there a decent tutorial that does not require me to dig through MFC and Wine sources, just so that I find how to do 100% standard and supposedly documented things? Why can't I find it in MSDN? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
I am using MSDN July 2001. Just look up WM_MDICREATE at the bottom of the page you have links to an over-view and all important functions/messages. Basically you: - Create any frame window but call MdiFrameProc for default processing. - Create a child MDIClient as you have seen. sub-class it or use it as is. (It is a global class registered by Window/Wine) - Create all MDIChild frames by doing an WM_MDICREATE on the MDIClient .Call MDIChildProc for default processing. - Menu Creation/handling differs - other stuff all taken care by MFC or WTL Free Life Boaz Shachar Shemesh wrote:
Shachar Shemesh wrote:
Hi all,
I am trying to make an application work under wine. The app is probably an MFC app, that defenitely uses MDI. The problem boils down to this - it tries to create an MDI window by doing SendMessageA to a message of type "WM_MDICREATE". Here's the catch - the class it wants to use is in Unicode. This fails for obvious reasons.
I'm trying to find my way around the MDI setting, and phrase a regression test. However, I cannot seem to create the exact same circumstances. When looking at the original app using Spy++, I see that the application has a window from the very start of the app (long before it sends WM_MDICREATE), which does not appear to have WS_EX_MDICHILD set, but which has a child window of class "MDIClient".
Running the same app in Wine using --debugmsg +win,+class, I can see that it asks to open a window of class "mdiclient". I do not, however, see anywhere that such a class was ever registered! Furthermore - the call succeeds.
Can anyone enlighten me? Is this window necessary whenever an MDI is present? If so, what function do I use on the parent window to tell it that it is to be an MDI container?
Many thanks,
Shachar
Hi all,
I THINK I found the answer. I need to create a child window with the "MDICLIENT" class, and pass it a CreateClientStruct. I'm not sure what I need to put in the struct, but I'll guess I'll figure it out as I go along.
Now the question - is there a decent tutorial that does not require me to dig through MFC and Wine sources, just so that I find how to do 100% standard and supposedly documented things? Why can't I find it in MSDN?
Shachar
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
I am trying to make an application work under wine. The app is probably an MFC app, that defenitely uses MDI. The problem boils down to this - it tries to create an MDI window by doing SendMessageA to a message of type "WM_MDICREATE". Here's the catch - the class it wants to use is in Unicode. This fails for obvious reasons.
And what are that obvious reasons? AFAICS we do proper ansi/unicode conversions for WM_MDICREATE message in windows/winproc.c. -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
I am trying to make an application work under wine. The app is probably an MFC app, that defenitely uses MDI. The problem boils down to this - it tries to create an MDI window by doing SendMessageA to a message of type "WM_MDICREATE". Here's the catch - the class it wants to use is in Unicode. This fails for obvious reasons.
And what are that obvious reasons? AFAICS we do proper ansi/unicode conversions for WM_MDICREATE message in windows/winproc.c.
When you send things via the "SendMessageA", I would assume they need to be ANSI. As such, the "obvious reasons" are that it appears, to my understanding of things, that this SHOULD fail. I'm trying to write a regression test, to see whether it doesn't fail on Windows. If anyone has any idea how to create traces on Windows that are similar to --debugmsg +relay, please let me know (I remeber that someone said something about it in the past). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
I always use OutputDebugString (Win32 API), or TRACE macros under msvc headers. Than it shows under the Debugger. And if on-site, Just download for free the DebugMon application from: www.sysinternals.com <http://www.sysinternals.com> It will catch and display all your Traces and let you save them to file and more.. Free Life Boaz Shachar Shemesh wrote:
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
I am trying to make an application work under wine. The app is probably an MFC app, that defenitely uses MDI. The problem boils down to this - it tries to create an MDI window by doing SendMessageA to a message of type "WM_MDICREATE". Here's the catch - the class it wants to use is in Unicode. This fails for obvious reasons.
And what are that obvious reasons? AFAICS we do proper ansi/unicode conversions for WM_MDICREATE message in windows/winproc.c.
When you send things via the "SendMessageA", I would assume they need to be ANSI. As such, the "obvious reasons" are that it appears, to my understanding of things, that this SHOULD fail.
I'm trying to write a regression test, to see whether it doesn't fail on Windows. If anyone has any idea how to create traces on Windows that are similar to --debugmsg +relay, please let me know (I remeber that someone said something about it in the past).
Shachar
Boaz Harrosh wrote:
I always use OutputDebugString (Win32 API), or TRACE macros under msvc headers. Than it shows under the Debugger. And if on-site, Just download for free the DebugMon application from: www.sysinternals.com <http://www.sysinternals.com> It will catch and display all your Traces and let you save them to file and more..
Free Life Boaz
Doesn't help me much when I have sources for neither program nor APIs. I'm trying to see why a propritery program misbehaves under wine, by comparing it to Windows. When running it under Windows, I don't have the luxury of OutputDebugString. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Doesn't help me much when I have sources for neither program nor APIs.
I'm trying to see why a propritery program misbehaves under wine, by comparing it to Windows. When running it under Windows, I don't have the luxury of OutputDebugString.
What about Spy++ for messages? For system calls you'd need to intercept all calls to dlls, either with some hooking or by replacing the original dlls (which in return call the originals). Maybe this can help you: http://www.codeproject.com/dll/apihijack.asp bye Fabi
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
When you send things via the "SendMessageA", I would assume they need to be ANSI. As such, the "obvious reasons" are that it appears, to my understanding of things, that this SHOULD fail.
No, it shouldn't. The conversion should take place in the case of a unicode window. A +relay,+msg,+win,+mdi log should help. If it's under 100Kb compressed you can send it to me directly.
I'm trying to write a regression test, to see whether it doesn't fail on Windows. If anyone has any idea how to create traces on Windows that are similar to --debugmsg +relay, please let me know (I remeber that someone said something about it in the past).
Look for "Debugging Tools for Windows" on the MS site, it has logger.exe and a viewer for the logs created by it. -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
When you send things via the "SendMessageA", I would assume they need to be ANSI. As such, the "obvious reasons" are that it appears, to my understanding of things, that this SHOULD fail.
No, it shouldn't. The conversion should take place in the case of a unicode window. A +relay,+msg,+win,+mdi log should help. If it's under 100Kb compressed you can send it to me directly.
As the application was installed with "win98" as the target platform, I find it extremely hard to believe that the window was created Unicode. I will, however, check. the log you mentioned is 228MB uncompressed. I'm currently compressing it, but I doubt it will be below 100K, partly because bzip2 isn't THAT good, but mostly because it's already over 2.5MB. I'll put it up on my site somewhere for anyone interested.
I'm trying to write a regression test, to see whether it doesn't fail on Windows. If anyone has any idea how to create traces on Windows that are similar to --debugmsg +relay, please let me know (I remeber that someone said something about it in the past).
Look for "Debugging Tools for Windows" on the MS site, it has logger.exe and a viewer for the logs created by it.
So that's where the windows symbols are hiding. MS site's navigation is terrible. I recently upgraded a W2K to SP4, and now my symbols turned out of date. Thanks! P.S. While terrible, not as bad as fsf.org, mind you. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
When you send things via the "SendMessageA", I would assume they need to be ANSI. As such, the "obvious reasons" are that it appears, to my understanding of things, that this SHOULD fail.
No, it shouldn't. The conversion should take place in the case of a unicode window. A +relay,+msg,+win,+mdi log should help. If it's under 100Kb compressed you can send it to me directly.
In case anyone is interested - http://shemesh.biz/winetrace.bz2 Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
In case anyone is interested - http://shemesh.biz/winetrace.bz2
Again unicows.dll (Microsoft Layer for Unicode) plays bad games with Wine. Could you regenerate the log with additional +snoop? -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
In case anyone is interested - http://shemesh.biz/winetrace.bz2
Again unicows.dll (Microsoft Layer for Unicode) plays bad games with Wine. Could you regenerate the log with additional +snoop?
Same location. What is +snoop? Also in the file are a couple of "ERR" I placed to follow the SendMessage, in an attempt to trace when it was translated. While talking about it, what is unicows.dll? I've tried to find anything about it in the list archives. Will trying to get the same program to work on Windows NT mode solve this problem? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Shachar Shemesh wrote:
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
In case anyone is interested - http://shemesh.biz/winetrace.bz2
Again unicows.dll (Microsoft Layer for Unicode) plays bad games with Wine. Could you regenerate the log with additional +snoop?
Same location. What is +snoop?
Also in the file are a couple of "ERR" I placed to follow the SendMessage, in an attempt to trace when it was translated.
While talking about it, what is unicows.dll? I've tried to find anything about it in the list archives. Will trying to get the same program to work on Windows NT mode solve this problem?
Shachar
I forgot to mention something important. The logs are from wine 20030709. Some regression prevents the app from working on more advanced versions. I figured that I'll first solve this problem, and then find the regression. If, however, someone made changes in unicows.dll that you think may be relevant to this problem, I will sort out the regression first, so that we can check whether this problem still happens on the latest Wine (right now things blow up way too early to tell). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
While talking about it, what is unicows.dll? I've tried to find anything about it in the list archives.
It's the "Microsoft Layer for Unicode" allowing to run under win9x some unmodified applications which use unicode win32 APIs.
Will trying to get the same program to work on Windows NT mode solve this problem?
Probably.
I forgot to mention something important. The logs are from wine 20030709. Some regression prevents the app from working on more advanced versions. I figured that I'll first solve this problem, and then find the regression.
Of course it would be much better to work with currenct CVS, so finding a regression should become a #1 task. -- Dmitry.
Hi I hope I'm not stating the obvious here, I'm just trying to help.
I'm trying to find my way around the MDI setting, and phrase a regression test. However, I cannot seem to create the exact same circumstances. When looking at the original app using Spy++, I see that the application has a window from the very start of the app (long before it sends WM_MDICREATE), which does not appear to have WS_EX_MDICHILD set, but which has a child window of class "MDIClient".
Running the same app in Wine using --debugmsg +win,+class, I can see that it asks to open a window of class "mdiclient". I do not, however, see anywhere that such a class was ever registered! Furthermore - the call succeeds.
Can anyone enlighten me? Is this window necessary whenever an MDI is present? If so, what function do I use on the parent window to tell it that it is to be an MDI container?
The MDIClient is the window which will hold all the child windows. It's the dark background in the empty MDI app. That's the main difference between an SDI and MDI app. The MDIClient takes care of messages such as MDICreate, MDITile, MDINext (from CTRL-TAB) and such. In our application we can dock various tools to the borders of the main window. The MDIClient is then resized to the remaining visible part so a maximized child window will have the right size (and will not be overlapped by the docked tool). Actually I don't know if this is normal or just in our application :) In the Create function is this: dwStyle |= WS_VISIBLE | WS_CHILD | WS_BORDER | WS_CLIPCHILDREN | WS_CLIPSIBLINGS|MDIS_ALLCHILDSTYLES; // allow children to be created invisible CLIENTCREATESTRUCT ccs; ccs.hWindowMenu = pMenu->GetSafeHmenu(); ccs.idFirstChild = AFX_IDM_FIRST_MDICHILD; // Create MDICLIENT if (!CreateEx(dwExStyle, _T("mdiclient"), NULL, dwStyle, rect.left... HTH bye Fabi
participants (4)
-
Boaz Harrosh -
Dmitry Timoshkov -
Fabian Cenedese -
Shachar Shemesh