I've coded Main precisely as described in Microsoft Docs - https://learn.microsoft.com/en-us/cpp/mfc/updating-the-text-of-a-status-bar-pane?view=msvc-170 and it processes the function when there's a command message to deal with. It will put anything that I want in a status bar pane. But when a Child of Main is opened, it stops. I've tried making the declaration of CStatusBar public and accessing its functions remotely, to no avail. Menu prompts display, but no status bar pane. I've placed a break in the update procedure which triggers while Main is on the surface but not when Child is in control. What's the problem?
While waiting, I found this, and corrected my mistake.
The only alteration was the instruction to include MainFrm.h in the Child which, in my case, caused a redefinition error. I removed all of the code from Main and placed it in Child. Now I'm getting the effect that I desired.
Related
I am working with Dialog based application.
My Question is that, I want to show Waiting dialog, until some database operation carried out.
i Used Derived class from CWinThread, but problem is that, when this thread close, the background (Main application dialog) remains at deactivated means( it hide behind another window).
i am thinking that, this is happening because of WaitDialog used CWinThread class.
The problem is not unique to a dialog based application. Creating windows of any kind in more than one thread is difficult and not recommended. In your case it sounds like your wait dialog is modal, while its parent dialog is in another thread. That is even worse and can lead to deadlocks between threads.
The reliable solution is to put the wait dialog (and all other GUI) in the main thread, and the lengthy database processing in a secondary thread.
Another alternative would be to use a Modeless Dialogbox which can also optionally show the status and call the DestroyWindow function when the database operation is completed -- you may need to disable some operations of the main window while the Modeless Dialogbox is visible, though.
From the comments on my previous answer, it looks like that alternative is not viable in this situation.
Maybe a better way would be to create a normal modal "wait" dialog box, start the background thread in the dialog's InitDialog, periodically check the status of the thread using a timer and end the dialog when the thread completes?
I have a bunch of control objects (TextBoxes, to be precise) that get injected into my code using the #FXML annotation during the FXML load.
I would like to save the states of these controls, specifically the text values, when the user closes the Scene by clicking the close box on the title bar.
However, when I trap the CloseRequest event in an OnCloseRequest handler I find that the values of the control variables are null (the original injection works, so this is something that happens in between the loading of the FXML and the calling of OnCloseRequest).
Can anyone explain this behavior and/or suggest how I can get the functionality that I want?
TIA
onCloseRequest is
Called when there is an external request to close this Window. ...
(from Javadoc). One of the meanings of "external request" is when you close the window through OS native window close button. The closeRequest event is not triggered through the programmatic stage.close() or stage.hide() calls. So consider to handle onHiding or onHidden events.
Otherwise post your OnCloseRequest handler code.
I'm currently working on a program using MFC. The current third party function starts a thread after an action has been completed using MFC (ie. Checking a checkbox, which starts a MFC thread I believe).
The problem occurs when I check the checkbox, at which point the entire program hangs. I read a few interesting discussions on CProgramming and msdn, it seems that the problem occurs because the new third party thread is calling WaitToSomething() when MFC is updating a control.
Something interesting to note:
When I debug the program, the program hangs (aka. repeatedly calls WaitToRead() ) after I check the checkbox and a new thread is trying to start
When I run the program without debugger, the program is fine UNTIL I switch to another window (ie. Internet browser, Notepad, etc)
My hypothesis:
check to make sure that MFC has finished updating the control before starting a new thread
If anyone has any suggestions or solutions, please leave a comment. Thanks.
Edit:
MFC is not thread-safe at object level (only at class level), so problem occurs when two threads work on the same CButton object.
Q: How do I make it thread safe?
A colleague helped me figure out what the problem was.
The reason why it was hanging is because that the control containing the checkbox is a child dialog, and when it finished updating the message never got passed up to its parent (so when 3rd party thread calls WaitFor(), the MFC thread never completes because a parent dialog thinks its child is still updating the controls).
Fix:
Under 'Properties' in the child dialog's control, set the 'Control' flag to true (and if it has children, set the 'Control Parent' flag to true as well).
Hope this helps.
I just started maintaining a set of embedded Python plugins for a Qt application. I'm also new to both PyQt and Python, so bear with me.
I have an implementation of a QTreeWidget in one dialog where the "expanded" signal is not being caught by the corresponding handler. I have another dialog where it works just fine.
In the problem dialog, I can verify that the connect was successful.
connected = wdg.connect(wdg.treeView_,SIGNAL("expanded(QTreeViewItem*)"), wdg.expanded)
evaluates to True. When I click on the child indicators to expand an item, the [+] signs change to a minus, but nothing else happens. Likewise, when I click on the [-], it toggles back to [+]. I have set the ChildIndicatorPolicy to initially set the indicator to SHOW in both cases.
In the dialog that works OK, when the user clicks on the plus sign, the 'expanded' handler is executed. Only the indicator toggles when it is clicked.
My handler code is simply:
def expanded(self, item):
logging.debug("In expanded handler")
I have a breakpoint at the logging call, but the statement is never reached.
I the failing dialog, I have another signal that's connected immediately before the one above, and it works just fine:
wdg.connect(wdg.treeView_,SIGNAL("currentItemChanged(QTreeWidgetItem*, QTreeWidgetItem*)"), wdg.itemChanged)
Is there anything that could prevent an expanded signal from firing or being caught? Another event perhaps? What should I be looking for? I realize that my nomenclature may be a bit off, and I welcome any correction in that regard as well.
The signal for a QTreeView expansion event is "expanded(QModelIndex)".
Alternatively, consider using the new style signal/slot syntax. I find it much easier than looking up the exact argument type for a particular signal.
wdg.treeView_.expanded.connect(wdg.expanded)
I found the problem. Despite the misleading name, the object is a QTreeWidge. When I replaced the name of the signal from "expanded" to "itemExpanded" and changed the parameter type to a QTreeWidgetItem*, everything worked.
wdg.connect(wdg.treeView_, SIGNAL("itemExpanded(QTreeWidgetItem*)"), wdg.expanded)
In my custom actions, I've used MessageBox.Show() to show a dialog whether needed. For ex: during database installation, I'd like to show a message to user if any error. But the message box is not set as a child of Wix window by default, thus the end-user can leave the message box and touch the Back, Next button ...
Is there any way to set the message box as a child of the main Wix installer window?
Thanks in advance,
There are bad ways and good ways. The bad ways involve FindWindow calls so you can parent appropriately. The good ways involve calls to MsiProcessMessage, Session.Message, or whatever wrapper is available. However if this custom action is being invoked from a DoAction ControlEvent, the latter will not work.