I'm writing an application that communicates and initializes instruments (via COM ports) during the initialization phase of a Dialog (using MFC, on Windows 10).
The instrument initialization is presently taking between 4 seconds and 10 seconds. So the GUI won't appear until the initialization is finished.
I want to know how to perform the drawing of the GUI, then call the instrument initialization function.
Here's a code fragment:
BOOL MyDialog::OnInitDialog()
{
//...
// code to initialize dialog widgets
//...
Initialize_Intruments();
return false;
}
From the Microsoft Documentation of the CDialog::OnInitDialog method:
Remarks
Windows sends the WM_INITDIALOG message to the dialog box during the Create, CreateIndirect, or DoModal calls, which occur immediately before the dialog box is displayed. {emphasis mine}
I want to perform functionality, after the dialog box is displayed, during initialization of the dialog.
How to do this using C++, MFC, Visual Studio (2017) and Windows 10?
Notes:
The application is a single dialog that runs test procedures.
A splash screen is another technique under consideration.
Related
Starting out with GUI programming with C++. So, following some tutorials, I 'wrote' the following code to display a dialogue box. To be honest, the Visual Studio 2015 Wizard did most of the job, but here is the code file. It correctly displays the dialogue box pointed by the identifier, but I really cannot figure out how it works. To begin with, what is the entry point, of the code? There is not even a function, so what exactly executes when I build and run it?
#include<afxwin.h>
#include"resource.h"
class CExampleDlg :public CDialog
{
public:
CExampleDlg():CDialog(IDD_EXAMPLE_DLG){}
~CExampleDlg(){}
};
class CExample:public CWinApp
{public:
BOOL InitInstance()
{
CExampleDlg myDlg;
m_pMainWnd = &myDlg;
myDlg.DoModal();
return TRUE;
}
};
CExample MyApp;
Unlike normal c/c++ application where the entry point is main and you have full control over the flow of execution. MFC applications are event driven. The code you write is executed based on the events that occur due to user interaction with the application like, clicking on the button, entering text in the text box etc. When there is no interaction the application sits idle.
1) The best place to is OnInitDialog to place your initialization code. You can initialize all the member variables in OnInitDialog. (Remember winMain is the entry point for windows application. But in MFC this is embedded deep down in the boilerplate code.)
2) Add message handlers to handle the user actions to execute your core logic later. For e.g.: If you have a button on the dialog then you need to add the message handler function for the button which will get invoked when the user clicks on that button. This can be done easily using the class wizard (https://msdn.microsoft.com/en-us/library/ee748520.aspx).
I am using VS2010 for my MFC SDI application.
In MainFrame Class in OnCreate(LPCREATESTRUCT lpCreateStruct) function I am opening one dialog box and on IDCANCLE replay from the Dialog box I want to close my application.
I am using following code for the same in onCreate Function.
CTermsConditionDlg objTNCDlg;
if(!objTNCDlg.DoModal() == IDCANCLE){
return -1;
}
Now my Question is after return Statement the application is Showing message box as shown in Image.
I want to disable this message box and close my application.
Can any one help how can I do That.
Thank You in Advance.
Why do you place this dialog so late into you initialization?
The problem is the SDI framework that relay on some initial things that are expected to run always. In this case it is always expected that the mainframe can be created. See code in CSingleDocTemplate::OpenDocumentFile
Just place this code into InitInistance before LoadFrame or ProcessShellCommand is called. In this case you can easily terminate without disturbing problems.
Another Idea is to allow the creation of the window, but simply using a PostMessage(WM_CLOSE); In this case the initialization is done, everything is created and the application terminates again.
Right now I'm working on a real time software, but I got myself implementing forms - using C++Builder 2007 - for confirmation messages (you know, those dialog box with OK and Cancel or only OK if it's an error), and I read that there's a DialogBox class on Windows MFC. The problem is the calling interrupts the thread until some input is done on the dialog, which I can't afford because another things might be happening on the application.
I've read about Modeless Dialog Box, but I'm not sure it's what I need or how to implement. Is there a default assynchronous dialog box on Windows MFC and if there is, how do I call it?
You don't need threads for this, you need modeless dialog boxes... they end up being windows on the same dispatch thread.
I have a large C++/MFC application that can start in two modes: 1) regular GUI mode and 2) special mode when it was started with command line parameters in which case the GUI part of the program is not shown but instead I add an icon to the notification (system) tray.
To ensure that the main window is not shown for mode 2 I process the WM_WINDOWPOSCHANGING as follows:
void OnWindowPosChanging(WINDOWPOS* lpwndpos)
{
CDialog::OnWindowPosChanging(lpwndpos);
// TODO: Add your message handler code here
//Prevent main window from showing
lpwndpos->flags &= ~SWP_SHOWWINDOW;
}
The issue happens if after processing this message the logic determines an error in a command line and wants to show the main window. But I can't seem to show the main window after processing the WM_WINDOWPOSCHANGING message like I showed above.
PS. The project is C++ MFC written for Visual Studio 2008.
I have a strange error and spend hours in the debugger without finding a solution.
(But it helped me to fixed another error that you should never call EndDialog from a WM_KICKIDLE task).
My problem is that i have a main window and a modeless dialog window wich raises a modal subdialog window. When the subdialog window is closed. The modeless dialog window turns itself into a modal window. My code really does leave the modal loop. And if i close the now modal window it behaves like an invisble modal window is active, meaning no interaction is possible anymore.
When i only run a modal dialog on top of the main window it is closed fine.
BTW: The main window is not the one available view CWinApp::m_pMainWnd but a new create FrameWindow. I hide the p_MainWnd and use it as an invisible message only window. From some comments and my debugging session i found that the pMainWnd has some special meaning but i could figure what exactly it has to do with modal windows (there is an undocumented "CWinApp::DoEnableModeless" for example).
EDIT: I'm posting a WM_CLOSE to the dialog and then use EndDialog(0) from the OnClose() handler to exit the modal state. I also tried to use EndDialog(0) directly. There is no difference between this two methods.
When MFC creates a modal dialog, it makes it modal by disabling the windows above it. The code that reenables those windows occurs when the dialog ends normally with a call to EndDialog. If anything prevents that code from running, the other windows will be locked out.
Modeless dialogs are a different beast, and there's a note specifically in the EndDialog documentation warning you to use DestroyWindow instead.
Maybe this is justifiable but I have a question:
why are you using hidden window? Was it created as message only window (passing HWND_MESSAGE as a parent handle and Message as a class) or you just call it message only?
OK, a little more info about MFC and dialogs.
MFC does not use Windows modal dialog. It always creates modeless dialog; either Create or DoModal call in turn ::CreateDlgIndirect windows API.
Modeless dialof rely on the main window message dispatch, while modal calls RunModalLoop that is similar to MFC window message pupmp (not a message loop).
It runs in the main thread of execussion without freezing because it allows for idle processing (calls OnIdle).
How do you dismiss the modeless dialog? As Mark pointed you should use DestroyWindow.
As for m_pMainWnd, MFC framework uses it extensively to determine may things that control main window behavior. By changing it you may have created the behavior you experience.
Did you set the value to a newly created frame you treat as a main window?
What kind of MFC application is it? SDI or MDI?
Would it be possible to create test app to duplicate this behavior and post it somewhere for download?
By the way, you do not have to be concern about DoEnableModeless, since it does not do anything but calls hook (COleFrameHook type) that is spasly used, unless you are trying to implement some functionality using OLE or ActiveX or you are trying to marry MFC and .NET Windows Forms.
In conclusion if your (or third party code uses this hook, I would suggest checking the code in the COleFrameHook class.