CDialog::Create never returns when it contains a CPropertySheet
I have a modeless property sheet that worked perfectly (under all of 95/98/ME/NT/2K/XP), but I wanted to make this dockable. I also have several modeless dialogs that I wanted to make dockable, so for simplicity I wanted to create a class derived from CDialogBar which would act as the base class for all my dockable windows.
Hence the first step was to convert my modeless CPropertySheet to a modeless CDialog. I just did this by creating a CDialog and placing the property sheet as a child window in it (and resizing when it resizes). This worked fine under Windows 2000/XP so I went ahead and changed the derived class from CDialog to (a class derived from) CDialogBar. With a lot of work it all worked fine under Windows 2000 and XP.
Then about a month later I discovered it fails miserably under Windows 95/98/ME.
I went back to my first step (property sheet in modeless CDialog) and even that fails under 9X. The call to CDialog::Create never returns. I stepped through the MFC code down to a call to API function CreateDialogIndirect which never returns. If I break I can see that there are various window messages being passed around (WM_SETCURSOR etc) but nothing ever gets drawn (obviously since CreateDialogIndirect never returns).
I think this is something that MFC is doing but I can't work it out. I also don't want to make major changes as I have spent a lot of time refining it as it is (under 2000).
Some questions:
What is going wrong here?
How do I fix it without major changes?
Why does Win9X behave differently to 2000/XP?
How can doing something so simple be so disastrous?
Hence the first step was to convert my modeless CPropertySheet to a modeless CDialog. I just did this by creating a CDialog and placing the property sheet as a child window in it (and resizing when it resizes). This worked fine under Windows 2000/XP so I went ahead and changed the derived class from CDialog to (a class derived from) CDialogBar. With a lot of work it all worked fine under Windows 2000 and XP.
Then about a month later I discovered it fails miserably under Windows 95/98/ME.
I went back to my first step (property sheet in modeless CDialog) and even that fails under 9X. The call to CDialog::Create never returns. I stepped through the MFC code down to a call to API function CreateDialogIndirect which never returns. If I break I can see that there are various window messages being passed around (WM_SETCURSOR etc) but nothing ever gets drawn (obviously since CreateDialogIndirect never returns).
I think this is something that MFC is doing but I can't work it out. I also don't want to make major changes as I have spent a lot of time refining it as it is (under 2000).
Some questions:
What is going wrong here?
How do I fix it without major changes?
Why does Win9X behave differently to 2000/XP?
How can doing something so simple be so disastrous?
ASKER
The property sheet worked fine under Windows 9X. It appears that just putting it inside a CDialog has caused the problem. I have tweaked a few other things which may have a bearing. But as it was a while ago I can't remember exactly what I have done.
I know I should try to isolate the problem and maybe even post some code. But this will take a fair bit of work to do and I was hoping someone would have seen this type of thing before.
And I just don't know why it works under 2000/XP but not 9X, and why MFC does not give some sort of assertion to tell me what I have done wrong.
I know I should try to isolate the problem and maybe even post some code. But this will take a fair bit of work to do and I was hoping someone would have seen this type of thing before.
And I just don't know why it works under 2000/XP but not 9X, and why MFC does not give some sort of assertion to tell me what I have done wrong.
If you put in in a CDialog, the per-window number of controls is bigger than using it as a modeless property sheet so this still might be a reason.
ASKER
No, I made the whole window just a child window of the dialog. The dialog has no controls only this child window. The property sheet has exactly the same pages and controls as when it worked.
just a guess...check your dialog resource's property...is it in WS_CHILD?, if yes, change to WS_POPUP
bundle your aplication with the required libraries .... mainly comctrl32.dll ..... old versions of these libraries can cause problems sometimes
I used to use embedded CPropertySheets in the past, but I run into too many problems with them. Now I only use CTabCtrl's anymore. It's a bit harder to use a CTabCtrl the first time you do this, but one you get the method worked out, it's not more work than embedding a property sheet.
ASKER
roshmon said:
> is it in WS_CHILD?, if yes, change to WS_POPUP
I have tried both. However, the doc for CDialogBar says it should be WS_CHILD, which it currently is.
bkfirebird said:
> bundle your aplication with the required libraries .... mainly comctrl32.dll ...
I will try. (Haven't had time to yet.) However, although it was reported by some else on Windows 98, I have reproduced it under Windows ME and other Windows 9X machines. Seems unlikely they all have the same problem DLL(s), esp. as I have never had any other problems.
khkremer said:
> I used to use embedded CPropertySheets .... Now I only use CTabCtrl's ...
This is probably good advice. I have done a lot with property sheets over the years and there are lots of gotchas. But if you use a TabCtrl won't that make your dialog a real mess in the dialog editor with the controls for all the pages on top of each other?
One other piece of info. Even though CreateDialogIndirect never returns, the window seems to be getting heaps of WM_GETDLGCODE messages sent to it, after WM_SETCURSOR message(s). I saw this before but I now think this is significant. Why all these messages unless the dialog thinks it is trying to process some user input events? At that point there would not be any user input events as the window has not even appeared on the screen.
It looks like Windows is in some sort of loop sending WM_GETDLGCODE messages and hence nothing else happens for the dialog window.
I also finally managed to hook Spy++ up to the window. (Its hard to do before the window appears on the screen.) When Spy++ is monitoring messages for the window evrything works fine.
I am now thinking it is some sort of order of events problem. This would explain the difference between Windows 9X and XP/2K. But I don't understand why the WM_GETDLGCODE messages are being sent even before the window appears.
> is it in WS_CHILD?, if yes, change to WS_POPUP
I have tried both. However, the doc for CDialogBar says it should be WS_CHILD, which it currently is.
bkfirebird said:
> bundle your aplication with the required libraries .... mainly comctrl32.dll ...
I will try. (Haven't had time to yet.) However, although it was reported by some else on Windows 98, I have reproduced it under Windows ME and other Windows 9X machines. Seems unlikely they all have the same problem DLL(s), esp. as I have never had any other problems.
khkremer said:
> I used to use embedded CPropertySheets .... Now I only use CTabCtrl's ...
This is probably good advice. I have done a lot with property sheets over the years and there are lots of gotchas. But if you use a TabCtrl won't that make your dialog a real mess in the dialog editor with the controls for all the pages on top of each other?
One other piece of info. Even though CreateDialogIndirect never returns, the window seems to be getting heaps of WM_GETDLGCODE messages sent to it, after WM_SETCURSOR message(s). I saw this before but I now think this is significant. Why all these messages unless the dialog thinks it is trying to process some user input events? At that point there would not be any user input events as the window has not even appeared on the screen.
It looks like Windows is in some sort of loop sending WM_GETDLGCODE messages and hence nothing else happens for the dialog window.
I also finally managed to hook Spy++ up to the window. (Its hard to do before the window appears on the screen.) When Spy++ is monitoring messages for the window evrything works fine.
I am now thinking it is some sort of order of events problem. This would explain the difference between Windows 9X and XP/2K. But I don't understand why the WM_GETDLGCODE messages are being sent even before the window appears.
With a CTabCtrl you still have individual controls that you create and manage one dialog at a time. It's really not that different than working with an embedded property sheet. You have to do a little more work to manage switching the tabs, but you save a lot of time working around these "gotchas".
ASKER
I have rewritten the dialogs and property sheets to get rid of dependencies on WM_INITDIALOG and DDX. (CDialog does not support these so I had been calling the functions myself.)
This seems to have fixed the problem, although I never tracked down exactly what was going wrong. However, it seems that it was some sort of order of window events problem. I suspect that Windows 9X and descendants vs NT and descendants vary in the order they send some messages and/or how handling of some messages creates other messages.
Thanks to all who posted comments.
This seems to have fixed the problem, although I never tracked down exactly what was going wrong. However, it seems that it was some sort of order of window events problem. I suspect that Windows 9X and descendants vs NT and descendants vary in the order they send some messages and/or how handling of some messages creates other messages.
Thanks to all who posted comments.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
- Can you open this modeless property sheet (without CDialog) under Win9x?
- Can you open the property sheet using standard WinAPI functions?
Another option is if you have non-standard controls (e.g., other than buttons, edits, static texts), try to remove them one by one. They may call some functions that work differently under Win9x or doesn't work at all or you cannot call them under Win9x.