Hello,

I have a CPropertySheet-derived dialog, which is called with
                dlg.DoModal();
so it normally shows modal. So far so good.
In its OnInitDialog(), it also shows some modal popups here and there.

In certain (repetitive and reproductible) sequences, after displaying
the modal popups, it comes out as modeless! I mean I am able to click
around and the main application reacts to that. Somehow the messages
get to the main window message loop instead of the modal window's own.

I really can see no difference between the calls that make it modeless
and those who doesn't alter its expected modal state... They do way
too much to be pasted here, like working with threads, windows, such,
so I think somehow something gets altered. But aynway what should I
look for?
Is there a message, a property, or something, which makes the
DoModal() create a modeless window? The docs say: 'call DoModal() get
a modal, call Create() get a modeless'. But look, I can create 2 modal
dialogs at the same time :) or even more.
I tried also to add in OnInitDialog():  
AfxGetApp()->m_pMainWnd->EnableWindow(FALSE);
This doesn't change it a bit... main window is up and getting
messages.

Otherwise all windows and actions work as expected... just the modal
is modeless now. Any hints, what I should look at? I'm running VC 6.0
latest SP on W2000 latest SP.

Thank you,
Sorin

Try explicitly specifying the parent window in the code where you
create the instance of the property sheet.

        CMySheet dlg( IDD_WHATEVER, parent window );

MFC dialogs are always modeless, they just disable their parent window
to simulate modal operation.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

That doesn't help either.
So apparently it's not a matter of the dialog losing its parent. It's
the messages going _always_ to the main pump. Or the window (parent or
main) does not stay disabled, something reenables it. I also went
directly to disable the main toolbar, just to see if
EnableWindow(FALSE) works here. It didn't disable it... am I missing
something with this EnableWindow() function?

Hum... that's good to know anyway.

Sorin

The messages always come from the main message pump - unless you do
something about it.

I'd assume that the parent window isn't getting disabled.

With the suggestion I gave, does it at least make things consistent?

If it doesn't, then you need to find out what's really happening. If
it is consistent, but the main window is still enabled, are you sure
you've passed the correct window as the parent?

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

I'm quite sure I passed the right one, and I tried with parents and
grandparents too, nothing gets _ever_ disabled in that particular
situation. So that didn't bring any change unfortunately. The Dialog
Manager seems to slip some messages also to the wrong window.
I've seen a patch in ServicePack4 of VC6 which addresses a bug like
this (a ListView which stays enabled when a modal dialog is ontop),
but I run already SP5 :) and the application is freshly rebuilt from
scratch. Could be some library pre-SP4 or something like that still
{*filter*} around?

Sorin

I doubt it.

Try starting from a clean project and see if you can reproduce the
problems in a more controlled situation.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq