When the window closes, the user is asked to save the file that they edited. They should also have an option to cancel quitting the application.
In WPF I can set the CancelEventArgs.Cancel property to true to do this. Is there an equivalent/workaround in Gtk#?
You need to set the DeleteEventArgs.RetVal to true, not false. From the relevant Mono documentation:
To keep a Gtk.Window from closing, set Gtk.DeleteEventHandler's Gtk.DeleteEventArgs.RetVal to true.
Found this python example (link) from a quick google search:
# When the window is requested to be closed, we need to check if they have
# unsaved work. We use this callback to prompt the user to save their work
# before they exit the application. From the "delete-event" signal, we can
# choose to effectively cancel the close based on the value we return.
def on_window_delete_event(self, widget, event, data=None):
if self.check_for_save(): self.on_save_menu_item_activate(None, None)
return False # Propogate event
Hopefully this helps.
Related
I'm using OpenEdge ABL to create a window that will run a secondary window on the touch of a button. However I am trying to get the first/parent window to freeze while the child window is running and resume when the child window closes.
I attempted to use WAIT-FOR WINDOW-CLOSE OF CURRENT-WINDOW on the parent window however this returned the error: Invalid widget handle used in WAIT-FOR statement. WAIT-FOR terminated (4122).
To run the child window I use:
RUN D:\adherenceEdit_12875-Win.w(cUserId,cShiftCode,dtDate).
Are you trying to make the child window modal?
I think you can look into using the TOP-ONLY or ALWAYS-ON-TOP attributes on the window, or make the child a dialog box.
I got around this was by adding:
DO WITH FRAME {&FRAME-NAME}:
Making the sensitivity of the buttons false meant that they would not be pressed while the child window was running.
ASSIGN CURRENT-WINDOW:SENSITIVE = FALSE.
RUN D:\adherenceEdit_12875-Win.w(INPUT cUserId,
INPUT cShiftCode,
INPUT dtDate).
After the child was closed the parent window continues running and resets the buttons sensitivity allowing them to be pressed
ASSIGN CURRENT-WINDOW:SENSITIVE = TRUE.
END.
I'm not sure if this is the most efficient way to do this and #nwahmaet's answer may have provided a more efficient method.
I like to do this by hiding the Main Window while the Popup is opened...
// Replace the C-Win to window's name - Not required to specify the frame
C-Win:VISIBLE = FALSE.
RUN My_Program.w.
C-Win:VISIBLE = TRUE.
I'm trying to write an AppleScript that tells if application has a specific menubar item. I've found this snippet on the internet, and tried to run, but it doesn't produce any effect. I've spliced into it some debug statements to check the control flow, and it seems not to enter the conditional 'if' at all.
No error message, no output, nothing!
on menuItemExists({appName, menuName1, menuItem1})
display notification "1"
tell application "System Events"
display notification "2"
tell application process appName
display notification "3"
if menu item menuItem1 of menu 1 of menu bar item menuName1 of menu bar 1 exists then
display notification "4"
return true
else
return false
end if
end tell
display notification "5"
end tell
end menuItemExists
if menuItemExists({"timeEdition", "Extras", "Start Recording"}) then
display dialog "hoda"
end if
If we assume that the AppleScript is functioning as it should, then this leads to one conclusion: at least one of those menu or menu item GUI objects does not exist, and therefore the script has nothing to return.
If that conditional statement passed—and only if it passed—then notification 4 would be displayed, and the function menuItemExists would return true. If this function returns true—and only if it returns true—then a dialog box would appear displaying the message "hoda".
However, no such dialog appeared, which implies that menuItemExists did not return true. If it did not return true, then it must have returned false. And if it returned false, this means the condition of some menu item’s existence failed, so no notification after number 3 would have been seen.
I believe you were expecting some output even in the event of failure. However, there is no error in the script, and the only statements that return values are all inside a function handler. That returns its value (which we’ve now deduced was the boolean value false) to the parent script that called it; and it’s only the parent script that would return any value—if it had a value to return—to the output window you were expecting to display a result.
Without having the application you’re using on my computer, it’s not possible for me to determine where in that conditional clause the assertion fails. My advice is to test each object individually, from menu bar 1 through to the menu item in question, and I’m confident the culprit will emerge.
The AppleScript code in your OP is only going to return true and trigger the display dialog "hoda" if and only if timeEdition is running and is not actively recording. When it's actively recording the menu shows Stop Recording. If timeEdition is not running, you can add tell application "timeEdition" to activate to the top of the script if you want the handler to result in true and display "hoda" in a dialog box when it's running and not actively recording.
display notification "5" will never trigger because of the use of return with both true and or false triggering prior to it.
I installed timeEdition and tested the AppleScript code in your OP and it does return false in Script Editor if it's not running. If running and not actively recording, it does trigger display dialog "hoda".
So, the AppleScript code in your OP actually works just as coded, although how it's coded is not of any practical use other then some testing, until its recoded for a real world use case scenario.
with following code:
XGrabPointer(d, root, False, ButtonPressMask
, GrabModeAsync, GrabModeAsync, None,
None, CurrentTime);
I just specify with button press event, but when running other applications can't get any other mouse event such as mouse move.
Is it what this function designed to be? or with something I made wrong understanding. like parameter owner_events, I can't understand well.
If owner_events is False, all generated pointer events are reported with respect to grab_window and are reported only if selected by event_mask. If owner_events is True and if a generated pointer event would normally be reported to this client, it is reported as usual. Otherwise, the event is reported with respect to the grab_window and is reported only if selected by event_mask. For either value of owner_events, unreported events are discarded.
with explaination of owner_event, it looks like I need to register two event type: ButtonPressMask|PointerMotionMask and owner_events True? but that doesn't work either.
The key is in the last sentence of the description you posted:
For either value of owner_events, unreported events are discarded.
I.e. it doesn't matter if owner_events is True or False, events that are not handled are discarded. The subtelty of owner_events is to which window the events are delivered: if owner_events == False all pointer events matching the mask are sent to the grabbing window, even if the event is in other windows that belong to you application (Client in X parlance); coordinates are relative to the grabbing window too. If owner_events == True events are reported to any window of your application, but not to other applications.
XGrabPointer really grabs all pointer events, and this is very strong. It is normally only used for transient (temporary) windows like popups, expanding dropdown windows, etc. The reason is to keep track of clicks outside of the window so you can close the transient. I've used in a color selector popup: when the users clicks on the "choose color" button a popup appears, I do a XGrabPointer (..False..), so I get all click events. If a user clicks outside of my popup window I close the window as if the user did not make a selection. Without XGrabPointer I would not know this happened and the popup would remain open until the user clicked in it. The XGrabPointer is immediately removed when the popup closes.
To prevent users from clicking in my main_window when a MessageBox appears I have used:
EnableWindow(main_window,FALSE);
I got a sample MessageBox:
EnableWindow(main_window,FALSE);
MessageBox(NULL,"some text here","About me",MB_ICONASTERISK);
EnableWindow(main_window,TRUE);
The problem is that when I press "OK" on my MessageBox it closes and my main_window is send to back of all other system windows. Why this is happening?
I tried to put:
SetFocus(main_window);
SetActiveWindow(main_window);
after and before : EnableWindow(main_window,TRUE) the result was strange: it worked 50/50. Guess I do it the way it shouldn't be.
Btw.
Is there a better solution to BLOCK mouse click's on specific window than:
EnableWindow(main_window,FALSE);
Displaying modal UI requires that the modal child is enabled and the owner is disabled. When the modal child is finished the procedure has to be reversed. The code you posted looks like a straight forward way to implement this.
Except, it isn't.
The problem is in between the calls to MessageBox and EnableWindow, code that you did not write. MessageBox returns after the modal child (the message box) has been destroyed. Since this is the window with foreground activiation the window manager then tries to find a new window to activate. There is no owning window, so it starts searching from the top of the Z-order. The first window it finds is yours, but it is still disabled. So the window manager skips it and looks for another window, one that is not disabled. By the time the call to EnableWindow is executed it is too late - the window manager has already concluded that another window should be activated.
The correct order would be to enable the owner prior to destroying the modal UI.
This, however, is only necessary if you have a reason to implement modality yourself. The system provides a standard implementation for modal UI. To make use of it pass a handle to the owning window to calls like MessageBox or CreateDialog (*), and the window manager will do all the heavy lifting for you.
(*): The formal parameter to CreateDialog is unfortunately misnamed as hWndParent. Parent-child and owner-owned relationships are very different (see About Windows).
We have a VB6 application that uses a non-visible window (form) for DDE communication.
We have some clients reporting that occasionally they can see this window on their desktop.
I did a scan through the code for any visible = true or show's on the form in question, but nothing.
This about all we do with it:
Load frmDDELink
frmDDELink.stuff = stuff
We don't actually explicitly display (or explicitly not display it either).
What could cause a hidden window to be displayed on a user's desktop such that it is visible?
Try and set the location of the form to off-screen.
frmDDELink.ClientLeft = -100
frmDDELink.ClientTop = -100
A misbehaving app on the client's machine could do that. FindWindow() is a notoriously inaccurate API function. On top of that, all VB6 windows have the same class name. Thunder something, iirc. It might be finding your window instead of the one intended, making the wrong window visible.
I like Black Frog's simple hint to set the location off-screen, and nobugz's possible explanation. I would also suggest handling the Form_Activate event and setting the form invisible again.
Private Sub Form_Activate()
'Log something for debugging purposes?'
Me.Visible = False
End Sub
try to set the border into none, or me.visible = false, and set the property not to display in the task bar.