When MFC uses the dialog box as a container, the program suspended due to the addition of ds_control style is forgotten.

The current project is a test data management program based on the MFC dialog box. According to the test phase, three batches of controls should be displayed in groups: test parameter setting interface, test answer filling interface, and test result display interface. For the convenience of Interface Management and logic management, use three dialog boxes as containers to contain controls for different interfaces.

 

When the program is about to be delivered, the program runs on a broken machine. After the program is switched to another program or minimized, or after debugging is switched to, switching back will cause the program to be suspended and unresponsive. At first, it was thought that the OSG 3D display module occupied a large amount of resources. As a result, the OSG module has not changed after being commented out.

 

After multiple tests, it is found that switching is okay after the program is started. However, when the focus is on those container dialogs, it will be suspended. The correct method for displaying the dialog box as a container is investigated. The following two sentences are missing:

M_settinglayer.create (idd_dialog_settinglayer, this); m_settinglayer.movewindow (10,100,500,600); // if this sentence is missing, use this dialog box as a control to view m_settinglayer.modifystyle (0, ds_control ); // if this sentence is missing, Tab can be used for navigation on the main interface. M_settinglayer.modifystyleex (0, ws_ex_controlparent); m_settinglayer.showwindow (sw_show );

After these two sentences are added, the program occupies almost no space from 25% of the CPU occupied by i7. OSG is incorrect.

However, the specific two statements may lead to the failure of the switching program, high CPU usage, and no time for research. Please wait for the reason. Just sauce.