MDI windows, MDIClient and mdiclient

[Shachar Shemesh]

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]

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

[Boaz Harrosh]

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

[Dmitry Timoshkov]

"Shachar Shemesh"  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.

[Shachar Shemesh]

Dmitry Timoshkov wrote:
> "Shachar Shemesh"  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]

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"  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]

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

[Fabian Cenedese]

> 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

[Dmitry Timoshkov]

"Shachar Shemesh"  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.

[Shachar Shemesh]

Dmitry Timoshkov wrote:
> "Shachar Shemesh"  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]

Dmitry Timoshkov wrote:
> "Shachar Shemesh"  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

[Dmitry Timoshkov]

"Shachar Shemesh"  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?

[Shachar Shemesh]

Dmitry Timoshkov wrote:
> "Shachar Shemesh"  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]

Shachar Shemesh wrote:
> Dmitry Timoshkov wrote:
> > "Shachar Shemesh"  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

[Dmitry Timoshkov]

"Shachar Shemesh"  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.

[Fabian Cenedese]

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