I am trying to add a CPropertySheet with three CPropertyPages to my MFC application. My problem is that the Property sheet only shows for less than a second then closes. When I open a different modal dialog after creating the CPropertySheet, the CPropertySheet stays open and I can use it with no problems. Here is my code:
BOOL CSLIMOptCplusplusApp::InitInstance()
{
CWinApp::InitInstance();
SQLHENV m_1;
EnvGetHandle(m_1);
Login lgn;
lgn.DoModal();
CImageSheet* imagedlg = new CImageSheet("Image Capture Dialog" );
CImageDisplay* pageImageDisplay = new CImageDisplay;
CImageDimensions* pageImageDimensions = new CImageDimensions;
ListOption* pageListOption = new ListOption;
ASSERT( imagedlg );
ASSERT( pageImageDisplay );
ASSERT( pageImageDimensions );
ASSERT( pageListOption );
imagedlg->AddPage( pageListOption);
imagedlg->AddPage( pageImageDimensions );
imagedlg->AddPage( pageImageDisplay );
imagedlg->Create( NULL,
-1,
WS_EX_CONTROLPARENT | WS_EX_TOOLWINDOW );
imagedlg->ShowWindow( SW_SHOW );
I think my problem may be at imagedlg->Create( when I use NULL as the first parameter. The tutorial I was following used this in place of the NULL. However, that gives the error:
IntelliSense: argument of type "CSLIMOptCplusplusApp *" is incompatible with parameter of type "CWnd *"
I also tried imagedlg->Create(); and it also only flashes for a moment.
I would like my CPropertySheet to stay open until it is closed. Thanks for any help!
EDIT:
Here is an image of what I wish my property sheet to look like. My first tab used a ListControl to change database options, the other two tabs are going to do other things. My intent is to keep the dialog/propertysheet looking the same as it does now, but to stay open instead of closing.
Your problem lies in trying to construct a property sheet within a dialog based application. Actually, your choice of executing everything within InitInstance can be problematic at times.
For starters, there's no need to create all of your objects on the heap (ie. using 'new'). But, if that's what you want, ok. As for your original problem of the sheet only displaying for a moment, InitInstance is designed to return immediately if not told otherwise. Thus, you see the sheet for an instance. This is due to MFC expecting a valid pointer to the CWinApp class derived member variable called 'm_pMainWnd' (actually, CWinThread::m_pMainWnd). If you want to start a property sheet, or, main dialog from within InitInstance, you need to set that variable to a valid window. Here's a quick sample I wrote:
CPropertySheet* m_pdlgPropertySheet = new CPropertySheet(_T("Simple PropertySheet"));
ASSERT(m_pdlgPropertySheet);
// Add three pages to the CPropertySheet object. Both m_pstylePage,
// m_pcolorPage, and m_pshapePage are data members of type
// CPropertyPage-derived classes in CView-derived class.
Page1* m_pstylePage = new Page1;
m_pstylePage->Construct(IDD_DIALOG1);
Page2* m_pcolorPage = new Page2;
m_pcolorPage->Construct(IDD_DIALOG2);
m_pdlgPropertySheet->AddPage(m_pstylePage);
m_pdlgPropertySheet->AddPage(m_pcolorPage);
m_pMainWnd = m_pdlgPropertySheet;
INT_PTR nResponse = m_pdlgPropertySheet->DoModal();
Note the line above DoModal. If you need additional info, take a look at Creating a full application using the CPropertySheet. Lastly, you may want to read up on how MFC starts an application and what is expected.
Related
I am new to MFC and have built an "outlook" style MFC app using the wizard. I've extended the CMFCShellTreetCtrl using CMyShellTreeCtrl and had data member variables and all was working fine. Now I want to move the data over to the CDocument class. Since there is several accesses to the data as each item is clicked or enumerated, I thought I would create a member variable m_pDoc to access the public variables in the CDocument. The problem I'm having, I can't find where to get the CDocument as it appears it's not setup when the trees OnCreate is called. That is in OnCreate
CWnd* pWndMain = AfxGetMainWnd();
ASSERT(pWndMain);
ASSERT(pWndMain->IsKindOf(RUNTIME_CLASS(CFrameWnd)) && !pWndMain->IsKindOf(RUNTIME_CLASS(CMDIFrameWnd))); // Not an SDI app.
m_pDoc = (CMyDoc*) ((CFrameWnd*)pWndMain)->GetActiveDocument();
returns NULL in m_pDoc and if I tried in an AfterCreate() (which is called after CreateOutlookBar) it's too late as m_pDoc is already being used and get a crash.
// Create and setup "Outlook" navigation bar:
if (!CreateOutlookBar(m_wndNavigationBar, ID_VIEW_NAVIGATION, m_wndTree, m_wndCalendar, 250))
{
TRACE0("Failed to create navigation pane\n");
return -1; // fail to create
}
m_wndTree.AfterCreate();
Any Ideas?
TIA!!
I came up with the following but I'm not sure if this is the proper way. Again, I'm new to MFC (I always have used Win32 directly). This works so it's AN answer, but is it THE correct answer?
POSITION docpos = AfxGetApp()->GetFirstDocTemplatePosition();
CDocTemplate *doctemplate = AfxGetApp()->GetNextDocTemplate(docpos);
docpos=doctemplate->GetFirstDocPosition();
m_pDoc = (CMyDoc*)doctemplate->GetNextDoc(docpos);
ASSERT(m_pDoc);
ASSERT(m_pDoc->IsKindOf(RUNTIME_CLASS(CMyDoc)));
TIA!!
The below code, creating a Property Sheet, works without problem in an Application File.
.......
CProp_Sheet Pr_Sheet(_T("PS"));
CPr_Page_1 Pr_Page_1;
CPr_Page_2 Pr_Page_2;
Pr_Sheet.AddPage(&Pr_Page_1);
Pr_Sheet.AddPage(&Pr_Page_2);
m_pMainWnd = &Pr_Sheet;
int nResponse = Pr_Sheet.DoModal();
However, when I put the same code in a DLL, and call it from a menu item in another Application, m_pMainWnd cannot be used (the menu in the Application is to remain visible behind the Property Sheet).
I have tried to create a handle
CWnd* m_pWnd = &Pr_Sheet;
and use m_pWnd in the CProp_Sheet constructor, but although compiling correctly at run time failure always occurs at
CProp_Sheet::OnInitDialog().
Thanks in advance for any comments.
I have a color button on toolbar, it was created in CMainFrame, how can I get a pointer to the color button which is CMFCColorMenuButton derived class from View, like the code below(part of MSOffice2007Demo Sample)? :
CMFCRibbonBar* pRibbon = ((CMainFrame*) GetTopLevelFrame())->GetRibbonBar();
ASSERT_VALID(pRibbon);
CMFCRibbonColorButton* pFontColorBtn = DYNAMIC_DOWNCAST(CMFCRibbonColorButton, pRibbon->FindByID(ID_FONT_COLOR));
The process to access button controls in a toolbar requires a number of steps to navigate to the control in question. The following list illustrates this:
Get a pointer to the frame window hosting the toolbar.
Get a pointer to the toolbar control.
[optional] Get the button index for a specific command ID.
Get a pointer to the button at the specified index.
Convert the base class button type to derived class.
// Get pointer to mainframe window
CMainFrame* pFrameWnd = DYNAMIC_DOWNCAST( CMainFrame, AfxGetMainWnd() );
// Get pointer to the toolbar
CBasePane* pPane = pFrameWnd->GetPane( AFX_IDW_TOOLBAR );
CMFCToolBar* pToolBar = DYNAMIC_DOWNCAST( CMFCToolBar, pPane );
// Find button index for command ID
int index = pToolBar->CommandToIndex( ID_COLOR_PICKER );
// Retrieve button
CMFCToolBarButton* pButton = pToolBar->GetButton( index );
// Convert button to appropriate type
CMFCColorMenuButton* pColorButton = DYNAMIC_DOWNCAST( CMFCColorMenuButton,
pButton );
A few notes on the implementation:
Error handling has been omitted for brevity. Whenever there is a DYNAMIC_DOWNCAST the return value can be NULL and has to be checked. Likewise, the call to CommandToIndex can fail and requires error handling.
DYNAMIC_DOWNCAST is similar to a C++ dynamic_cast in that it evaluates whether a runtime type can be converted to another type. While not all Windows control relationships can be modeled as a C++ class hierarchy, MFC provides its own conversion tool: DYNAMIC_DOWNCAST.
The ID passed to the call to CommandToIndex is the command ID assigned to the CMFCColorMenuButton either through a resource script or at runtime, depending on how the control is created.
I have followed this link to get the window handle of a ActiveX control
Sample Code from microsoft's site
// The following code should return the actual parent window of the ActiveX control.
HWND CMyOleControl::GetActualParent()
{
HWND hwndParent = 0;
// Get the window associated with the in-place site object,
// which is connected to this ActiveX control.
if (m_pInPlaceSite != NULL)
m_pInPlaceSite->GetWindow(&hwndParent);
return hwndParent; // Return the in-place site window handle.
}
But in my case I keep finding that "m_pInPlaceSite" is always NULL. I'm trying to run this code in my controls FinalConstruct. Is there something else I need to implement for the m_pInPlaceSite to be given a value? Or do I need to Query to get the value.
Thanks
FinalConstruct is way too early. In FinalConstruct your class is just being created and is not yet initialized. There is no "in place" site, there is no yet site at all.
Your control will be called by its owner, it will be given its site, then activated - only then you will possibly have m_pInPlaceSite available.
It is necessary to switch off the "ClearType" property of the default font for all dialog controls. It is possible to do that for one control by setting
logfont.lfQuality = ANTIALIASED_QUALITY
There are a lot of suggestion how to do the same for modal dialogs (http://neelaakash.wordpress.com/2007/12/31/change-default-dialog-font-of-cdialog/ and others), but that should be done for non-modal dialogs (are instantiated with new and Create(...) methods). I've tried to do that myself:
Override 'Create' method, and modify dialog template:
BOOL CActivationChildDialogLicenseInfo::Create(UINT nIDTemplate,
CWnd* pParentWnd)
{
CDialogTemplate dlt;
int nResult;
// load dialog template
if (!dlt.Load(MAKEINTRESOURCE(nIDTemplate))) return -1;
// set your own font, for example “Arial”, 10 pts.
dlt.SetFont(L"Arial", 12);
// get pointer to the modified dialog template
LPSTR pdata = (LPSTR)GlobalLock(dlt.m_hTemplate);
// let MFC know that you are using your own template
m_lpszTemplateName = NULL;
InitModalIndirect(pdata);
// display dialog box
nResult = CActivationChildDialog::Create(nIDTemplate, pParentWnd);
// unlock memory object
GlobalUnlock(dlt.m_hTemplate);
return nResult ;
}
Seems like this method do nothing (it is called, I've checked that with putting break-point inside).
I've tried to call
nResult = CActivationChildDialog::Create(NULL, pParentWnd);
...but got a lot of ASSERTs.
I've also tried to override the 'OnSetFont' method:
void CActivationChildDialogLicenseInfo::OnSetFont(CFont *pFont)
{
CActivationChildDialog::OnSetFont(pFont);
LOGFONT logfont;
pFont->GetLogFont(&logfont);
LOGFONT logfont2=logfont;
pFont->DeleteObject();
logfont2.lfItalic = true;
logfont2.lfQuality = ANTIALIASED_QUALITY;
pFont->CreateFontIndirect(&logfont2);
}
That causes ASSERT during run-time and resulted in a VERY big font being used (lost default font settings, doesn't accept new specified settings)... I don't know why.
Please advise, how can I change a default dialog font that will be "inherited" by all dialog controls?
Thank you very much.
First off: the simple, reliable way to do this is to create the dialog and then send WM_SETFONT (or call SetFont()) to the dialog and each control in it. I'll show you how to do that below, but first, here's why the two strategies you've already tried didn't (and can't) work:
Modifying the dialog template
First off, you should be calling CDialog::CreateIndirect() if you wish to use a dialog template that you've already loaded.
But don't bother. The dialog template contains only the face name and point size - it does not allow you to specify other LOGFONT values such as lfQuality. If it did, you could simply specify that in your resource definition and avoid writing any runtime code at all!
Intercepting WM_SETFONT
In theory, you could make this work. But it's not practical. Your code has several problems: first off, you'd have to intercept this message for every child control in order for it to do anything useful: the dialog itself probably doesn't render any text. But worse, you're passing the original font to the base class (which hands it to the default window procedure, which stores it internally for later use) and then immediately destroying it - this means the dialog (and everything else using that font, including all of the child controls) will be trying to draw text using a bogus font, and reverting to the default font as a result. Finally, you're creating a new font attached to a temporary object (pFont) created and destroyed by MFC - internally, the CFont object you're working with will be detached from the font handle and destroyed, leaking a handle to a font object that nothing uses.
Leaky abstractions: a note on HFONT and CFont
HFONT is a handle type that Windows uses to represent a font object. Like most of GDI, there are specific functions for creating fonts, and the general-purpose DeleteObject() function for destroying them.
CFont is a light-weight wrapper class for HFONTs. A CFont instance can be attached and detached from an existing HFONT, or used to create a new one. If a CFont instance is still attached to a HFONT when its deconstructor executes, it will call DeleteObject() to destroy the underlying object. Internally, MFC utilizes temporary CFont instances that are attached and detached from HFONTs when calling various message handlers (such as OnSetFont). It's worth remembering that internally, Windows knows nothing about CFont, and a single HFONT may belong to 0 or more CFont instances at any given point in time.
A note on fonts and WM_SETFONT
When you create a new font - whether or not it is wrapped in a CFont object - you are the owner of that font, and it is your responsibility to destroy it once you are finished using it. Passing it to WM_SETFONT (CWnd::SetFont()) doesn't change ownership! This is actually quite useful, as it allows you to pass the same font to multiple windows without worrying about which one will destroy it - you're still the owner, and so you can (and must) destroy it yourself (once there are no windows still using it).
Finally - how to quickly create and set a font on a dialog and all its children
So you should now have enough background to understand the necessary steps:
Create the dialog
Create the desired font
Pass the font to the dialog and its children (by either sending WM_SETFONT messages, or by calling CWnd::SetFont... which itself send a WM_SETFONT message).
When the dialog is destroyed, also destroy your font.
Example
// define this as a class member - class destructor then handles step four!
CFont m_nonCleartypeFont;
BOOL CActivationChildDialogLicenseInfo::Create(UINT nIDTemplate,
CWnd* pParentWnd)
{
// step one: create dialog normally
BOOL nResult = CActivationChildDialog::Create(nIDTemplate, pParentWnd);
// step two: create custom font
// relying on destructor to destroy font once we're done with it
// so be careful to only create it once!
if ( NULL == m_nonCleartypeFont.m_hObject )
{
CFont* pOriginalFont = GetFont(); // use template font as... template!
// pull information from original font
LOGFONT logfont;
pOriginalFont->GetLogFont(&logfont);
// make font adjustments:
// specify italics
logfont.lfItalic = true;
// and non-cleartype antialiasing
logfont.lfQuality = ANTIALIASED_QUALITY;
// create our font based on adjusted information
m_nonCleartypeFont.CreateFontIndirect(&logfont);
}
// step three: set our custom font on the dialog and all children
SetFont(&m_nonCleartypeFont, FALSE);
// Send message to quickly set this font for all children.
// See documentation for SendMessageToDescendants()
// - this is actually the example given!
SendMessageToDescendants(WM_SETFONT,
(WPARAM)m_nonCleartypeFont.m_hObject,
MAKELONG(FALSE, 0),
FALSE);
return nResult;
}