I'm using glade and pygtk and I have a window with a treeview with a button that opens a dialog that creates a new entry for the treeview. I want to update the treeview in the main window when the dialog is destroyed but I can't see a simple way to do this.
--Edit--
Found the answer, I just needed to connect the windows destroy signal
(dialog).window.connect('destroy', self.foo)
The correct approach is to handle the response of the dialog in the main window:
def on_menu_item_activated(self, widget, data=None):
dialog = FunkyDialog()
response = dialog.run()
if response == gtk.RESPONSE_OK:
// update treeview
Perhaps a better way of doing this would be to use the Observer design pattern. When the user presses Ok, you save your data. This notifies the treeview that a change has been made, which causes it to reload.
Related
This is probably behavior by design, but I'll ask anyway -
I call a form from another project dll in my main project. It is NOT Modal (ShowDialog) or TopMost, and I set a variable for the form once it's created ("frm = New ..."), so that I can check when it's already been created (user clicks a toolbar button to create it initially.)
The form displays, fires events etc. all perfectly.
However, if I MINIMIZE the form and then call frm.Show through code to bring it back, nothing happens. The form remains minimized.
frm.Show has no affect and doesn't seem to fire any other events.
The only way to bring it back is to click on the taskbar icon for the MAIN form, which then displays the MAIN form AND the minimized forms (as icons), and then click on the icon for the minimized form.
I've tried various events (.Activate, .Show, .ShowDialog, .Focus) NOTHING will bring the other form out of its minimized state other than physically clicking on the Taskbar MAIN app icon and then selecting it.
Also, the main application is not MDI...
???
Thanks.
normally this should do it as suggested by #jimi
[TheForm].WindowState = FormWindowState.Normal
But sometimes this does not works for some dark reason, so you could use some other methods
form.Show();
form.BringToFront();
if (form.WindowState == FormWindowState.Minimized)
{
ShowWindowAsync(form.Handle, 9); // 9 = SW_RESTORE
}
I am sure there is one of these that will fix your problem
In my application I perform an operation which causes an internal Android app to pop up AlertDialog over my application.
Is it possible to somehow dismiss this Dialog programmatically? Unfortunately I can't find the access to this Dialog object.
I've tried overriding onCreateDialog() method in my Activity, but as my Activity is not an originator of Dialog window, this method is not being called when it pops up.
I was also thinking about getting list of all objects that appear on the screen, but I assume there's no such method?
To my understanding you are doing something that is requiring some user interaction, like bluetooth pairing, in which case this Dialog is brought up by the system... possibly (System Dialog) which is not controlled by you. To solve this...
One thing you can try is:
Intent closeDialog = new Intent(Intent.ACTION_CLOSE_SYSTEM_DIALOGS);
sendBroadcast(closeDialog);
public static final String ACTION_CLOSE_SYSTEM_DIALOGS
Added in API level 1 Broadcast Action: This is broadcast when a user
action should request a temporary system dialog to dismiss. Some
examples of temporary system dialogs are the notification window-shade
and the recent tasks dialog.
Constant Value: "android.intent.action.CLOSE_SYSTEM_DIALOGS"
If i want to the parent dialog get the data of the child dialog when a button（typically a OK button） of the child dialog's button is clicked. how to realize?
My app is like this type: initialize i start an dialog, when hit the new button, it create a new dialog for configure a database connection. when input the necessary info. i can click the OK button of the child dialog, the child dialog will not live, then i need use the father dialog to save the info input in the child dialog.
How to realize it?
The C++ wxDialog object remains alive even after the dialog on screen is closed. So typically you store the data in this object fields (either using validators or by manually overriding TransferDataFromWindow()) and then retrieve it from this object as needed in the code that showed the dialog.
I have a form in a vb.net windows form application called PolicyRefreshStatus.vb that has a ProgressBar control on it. From the main form called EditPolicy.vb I need to show PolicyRefreshStatus.vb over top of EditPolicy.vb - but the way things are wired I'm controlling the the ProgressBar and it's steps from logic inside EditPolicy.vb.
If I display the PolicyRefreshStatus.vb bar using the .show() method things work fine. The problem is if the user clicks back on the main form then PolicyRefreshStatus.vb losses focus. If I show PolicyRefreshStatus.vb as a modal form using .ShowDialog() then execution halts in EditPolicy.vb after the .ShowDialog() statement.
so for example in the code:
mPolicyRefreshStatus = New PolicyRefreshStatus
mPolicyRefreshStatus.pbMax = mPolicy.ClaimsUpdateMax
mPolicyRefreshStatus.ShowDialog()
mPolicy.UpdateFromFIS()
The line mPolicy.UpdateFromFIS() never executes because it's waiting for the PolicyRefreshStatus form to close.
How can I show PolicyRefreshStatus in a modal form but let execution continue in EditPolicy.vb?
You've got a couple of related options.
This first is to pass the unit of work to the progress bar in the form of a delegate or a class implementing an Interface. Something like this (not checked for correctness, just a rough example):
mPolicyRefreshStatus = New PolicyRefreshStatus
mPolicyRefreshStatus.pbMax = mPolicy.ClaimsUpdateMax
mPolicyRefreshStatus.UnitOfWork = AddressOf(mPolicy.UpdateFromFIS())
mPolicyRefreshStatus.ShowDialog()
Then within the progress form you can call back to the routine that actually does the work.
Another approach is to define events on your ProgressForm and then the owning/launching object can handle those events to do the work in. With this option you can create a fairly detailed set of events to be able to handle incremental work or cancels, but the concept is the same, youu are calling back from the progress form into launcher to perform the actual business logic.
You cannot show the form modally and let your routine continue. You must show the form Non-modally and then do your other stuff, closing the form when you've finished. Maybe a loop until the task has finished?
Using Show() with a parent form parameter will give you better usability. More like a tool window.
My mdi VB.Net application performs a long operation on some data. Ideally I should use a separate thread to prevent the dreaded “Not Responding” message.
My problem is if I use a separate thread users then have the ability to click on other controls in the application which can directly affect the operation my background thread is working on, creating an error.
Is there any way to prevent all the mdi windows, toolbars and other controls from receiving mouse clicks and keyboard input during my background thread’s operation?
Or is there a way to clear the message que before performing a Application.DoEvents?
Thanks
I would say that the best choice when you don't want a user to click on a control is to set Enabled to False for that control.
CLARIFICATION: Setting Enabled to False for a parent control will also disable any children. So, setting Enabled to False on the main window and and MDI windows, will do the trick.
There are a couple of ways of disabling the controls but I'm not sure it's what you want.
If you have a main window which is completely disabled while a background thread is processing then why go through the overhead of processing on the background? The advantage of processing on the background is to allow the user to still work with the application while you process data.
I think a better approach would be to take Dustin's route and selectively disable certain controls that can affect the background operation. Or make your background operation independent of the UI while it's processing.
If you tell us a little bit more about how your Main Window and Background thread interact we may be able to give you a better solution.
Hide all forms and only show the one main form. Then disable the Toolbar/Menu if you have either. Then have a status bar with a progress bar and when it gets done, unhide the form the user was working on.
When you are using a statusbar or a progress bar while your background thread is processing some longduring task, disabling your form will also disable your progress/status bar from updating. So what you should do in this case is disable every other control exept from the one that needs te be kept active (e.g. like a progressbar).
List<Control> lstControls = GetAllControls(this.Controls);
foreach (Control ctrl in lstControls)
{
if (ctrl.GetType().Name.ToLower().Contains("progressbar") {
ctrl.Enabled = true;
}
else
{
ctrl.Enabled = false;
}
}
Use a thread and display a modal dialog that shows the user the progress of your task and gives the user the option to cancel it.
The modal dialog will automatically prevent input (the parent may have to be the mdi window itself.)
(Please do not use hacks like hiding or disabling controls or windows. And please, please, please! do not use DoEvents.)