Prev: Error writing file: VS2005
Next: deploying mfc-based ActiveX control (VC++ 2005)
From: tomasu on 15 Jan 2007 13:04
> In your call stack I do not see the call to your derived
> WinApp::InitInstance(), but I do see calls to
> CPropertyPage::CPropertyPage() and CPropertyPage::CommonConstruct().
>
> Do you have a global CPropertyPage object? If so, why?

I have one main dialog and a number of additional CPropertyPage dialogs
(public classes). At startup, a blank property page (with some text)
is loaded, and when a device is attached to the computer and
'autodetected' by my application, my code adds the appropriate
CPropertyPage (embedded in the main dialog) with device-specific tools.
I was under the impression that in order to add, remove, and set
active property pages from my main dialog, the property pages would
need to be public.

This application has been growing and working great so far and only
recently broke when I tried to call 'GetOpenFileName' on one of my
property pages (see top of thread). I used CFileDialog instead and
this assertion failure went away. Now I get the same exact assertion
using 'ShellExecute' on my main dialog... Commenting out the single
'ShellExecute' line makes the assertion go away. What exactly is an
"afx resource" anyway?

From: David Wilkinson on 15 Jan 2007 13:28
tomasu(a)gmail.com wrote:

>>In your call stack I do not see the call to your derived
>>WinApp::InitInstance(), but I do see calls to
>>CPropertyPage::CPropertyPage() and CPropertyPage::CommonConstruct().
>>
>>Do you have a global CPropertyPage object? If so, why?
>
>
> I have one main dialog and a number of additional CPropertyPage dialogs
> (public classes). At startup, a blank property page (with some text)
> is loaded, and when a device is attached to the computer and
> 'autodetected' by my application, my code adds the appropriate
> CPropertyPage (embedded in the main dialog) with device-specific tools.
> I was under the impression that in order to add, remove, and set
> active property pages from my main dialog, the property pages would
> need to be public.
>
> This application has been growing and working great so far and only
> recently broke when I tried to call 'GetOpenFileName' on one of my
> property pages (see top of thread). I used CFileDialog instead and
> this assertion failure went away. Now I get the same exact assertion
> using 'ShellExecute' on my main dialog... Commenting out the single
> 'ShellExecute' line makes the assertion go away. What exactly is an
> "afx resource" anyway?
tomasu:

This is not making much sense to me. But once again: do you have a
global (or class-static) CPropertyPage in your application?

CPropertyPage is supposed to be used with CPropertySheet. Normally, the
pages are members of the sheet. What is your "main dialog"? is this a
CPropertySheet? And what does "the property pages would need to be
public" mean? "Public" is not the same as "global".

The thing that is bothering me is that you say that the app gives the
assert on startup, but I do not see InitInstance() in your call stack.
So either the error is happening before InitInstance() is called (this
is what I thought) or after InitInstance() has returned. Put a break
point at the beginning of InitInstance() and see if it is called. If
not, I would say you must have global or class-static object(s) that are
causing the assertion.

David Wilkinson



From: tomasu on 15 Jan 2007 14:03
> This is not making much sense to me. But once again: do you have a
> global (or class-static) CPropertyPage in your application?
>
> CPropertyPage is supposed to be used with CPropertySheet. Normally, the
> pages are members of the sheet. What is your "main dialog"? is this a
> CPropertySheet? And what does "the property pages would need to be
> public" mean? "Public" is not the same as "global".
>
> The thing that is bothering me is that you say that the app gives the
> assert on startup, but I do not see InitInstance() in your call stack.
> So either the error is happening before InitInstance() is called (this
> is what I thought) or after InitInstance() has returned. Put a break
> point at the beginning of InitInstance() and see if it is called. If
> not, I would say you must have global or class-static object(s) that are
> causing the assertion.

Hi Dave,

I just put a break point at InitInstance() and still got the assert...

I am declaring "CPropertySheet myPropSheet" at the top of my main
dialog's source file. I then do myPropSheet.AddPage(&tab_Blank), etc.
throughout the main dialog.

I'm sorry for not understanding what was meant by "global." I looked
it up and declarations for my property pages and property sheet are all
sitting at the top of my main dialog's source page (right below the
includes, not within any functions). I believe this makes them global.
So I most likely have global or class-static object(s) that are
causing the assertion. This is great news (at least now I know what
I'm looking for).

I'm going to take a look at alternatives to defining these
propertypages as global variables and let you know if I can make this
dang assertion go away.

Thanks so much!
Tom

From: David Wilkinson on 15 Jan 2007 14:25
tomasu(a)gmail.com wrote:

>>This is not making much sense to me. But once again: do you have a
>>global (or class-static) CPropertyPage in your application?
>>
>>CPropertyPage is supposed to be used with CPropertySheet. Normally, the
>>pages are members of the sheet. What is your "main dialog"? is this a
>>CPropertySheet? And what does "the property pages would need to be
>>public" mean? "Public" is not the same as "global".
>>
>>The thing that is bothering me is that you say that the app gives the
>>assert on startup, but I do not see InitInstance() in your call stack.
>>So either the error is happening before InitInstance() is called (this
>>is what I thought) or after InitInstance() has returned. Put a break
>>point at the beginning of InitInstance() and see if it is called. If
>>not, I would say you must have global or class-static object(s) that are
>>causing the assertion.
>
>
> Hi Dave,
>
> I just put a break point at InitInstance() and still got the assert...
>
> I am declaring "CPropertySheet myPropSheet" at the top of my main
> dialog's source file. I then do myPropSheet.AddPage(&tab_Blank), etc.
> throughout the main dialog.
>
> I'm sorry for not understanding what was meant by "global." I looked
> it up and declarations for my property pages and property sheet are all
> sitting at the top of my main dialog's source page (right below the
> includes, not within any functions). I believe this makes them global.
> So I most likely have global or class-static object(s) that are
> causing the assertion. This is great news (at least now I know what
> I'm looking for).
>
> I'm going to take a look at alternatives to defining these
> propertypages as global variables and let you know if I can make this
> dang assertion go away.

Tomasu:

You should absolutely not have the property sheet and property pages as
global objects. In fact an MFC program should not (or certainly need
not) have any global objects except the CWinApp-derived object, which is
called theApp.

Normally, the property pages should be members of the property sheet,
and the property sheet should be a member of whatever class it is
launched from.

[I still have not understood the architecture of your application, and
how the property sheet is related to the "main dialog".]

David Wilkinson

From: tomasu on 15 Jan 2007 14:41
Hi David,

I moved my CPropertyPage declarations from the top of my main dialog to
within the functions where they were used and the assertion failure
went away.

I'm still not sure what was happening, but I am going to take your
obviously great advice and do away with any and all global variables
that are still lingering in my application. I'll also do some more
digging and try and report here what was going wrong. I find it
strange that I wasn't having any assertions until just last week...

Thanks!
Tom

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Error writing file: VS2005
Next: deploying mfc-based ActiveX control (VC++ 2005)