Re: lParam of WM_CREATE for MDI children

[Steven Edwards]

Hello Dmitry,

--- Dmitry Timoshkov  wrote:
> applications use something like the following code in order to pass
> a custom parameter to a newly created MDI child:

<snip>
> Any ideas how to proceed without breaking too much assumptions in
> the current code?

You may want to take a look at the ReactOS implementation of MDI as we
have done quite a bit of work on this and shell32 of late to get the
ReactOS Explorer working. I dont know if Filip or Martin has already
fixed the MDI bugs but if so we should have something to merge when
Alexandre gets back.

Thanks
Steven

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

lParam of WM_CREATE for MDI children

[Dmitry Timoshkov]

"Steven Edwards"  wrote:
> You may want to take a look at the ReactOS implementation of MDI as we
> have done quite a bit of work on this and shell32 of late to get the
> ReactOS Explorer working. I dont know if Filip or Martin has already
> fixed the MDI bugs but if so we should have something to merge when
> Alexandre gets back.

No offence intended, but I don't see anything useful in the diff:

1. lots of useless #ifdef __REACTOS__/#endif
2. MDICLIENTINFO is allocated twice: in WM_NCCREATE and WM_CREATE.
3. again, as everywhere in the ReactOS I see complete misuse of ansi/unicode
macros vs. real win32 API names. You guys really want to disable use of macros
based on the UNICODE preprocessor define, like it's done in Wine. Otherwise
you will get *a lot* of mess and headache in the long run.

For instance

SetWindowLongPtr(hwnd, 0, (LONG_PTR) ci);

what version A or W of SetWindowLongPtr is intended to be used in this
particular case and in this particular place of the code?

lParam of WM_CREATE for MDI children

[Steven Edwards]

Hello Dmitry,

--- Dmitry Timoshkov  wrote:
> No offence intended, but I don't see anything useful in the diff:

No offence taken. I didnt know if there would be anything useful in
there or not. We have been doing a bit of work on MDI because Martin's
explorer clone depends on it so I thought we might have already fixed
some of the bugs. Quite a few of our developers also use MDI text
editors though I dont understand why.....
> - lots of useless #ifdef __REACTOS__/#endif

I agree. We need to better split the Win16/32 stuff in some of the
sources we are adopting and abstract some of the code better so Wine
and ReactOS can share it without needing these. I will send a patch for
this today.
> - MDICLIENTINFO is allocated twice: in WM_NCCREATE and WM_CREATE.

Yes this is a problem too.
> - again, as everywhere in the ReactOS I see complete misuse of
>
> ansi/unicode
> macros vs. real win32 API names. You guys really want to disable use
> of macros
> based on the UNICODE preprocessor define, like it's done in Wine.
> Otherwise
> you will get *a lot* of mess and headache in the long run.
>
> For instance
>
> SetWindowLongPtr(hwnd, 0, (LONG_PTR) ci);
>
> what version A or W of SetWindowLongPtr is intended to be used in
> this
> particular case and in this particular place of the code?

Your right. We have the same problem in the controls and I think this
causes a good bit of problems for us.

Well sorry for the noise,
Thanks
Steven

__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003