I have a function in gtkmm in the main window which opens a message box on the Help->About selection. The function is as follow:-
bool Main_window::on_about_selected(GdkEventButton *f_event)
{
Gtk::MessageDialog dialog(*this, "Msg Box example");
// left the rest
dialog.run();
}
this pointer passes the Main_window since it calls the function.
How should i pass this argument when i want to call a message box dialog from another file other than the Main_window?
How do i set parent of this message dialog to be the window on which i want this to be called?
how do i get the top level window?
That Gtk::Window is the transient-for (or parent) window, which associates the dialog window with a previously-open window.
If you want the dialog to have your main window as it's parent, you'll need to create some way to get that pointer to the main window. In an application, it's usually OK to just store it in a global variable. If it's not that simple for you, you'll need to invent your own system.
Calling Gtk::Widget::get_toplevel() on a child widget that you know about might help, but I suspect that it's not that simple. In particular, you'd have to be sure to only call it when you know that the child widget is really in a Gtk::Window.
Related
What are the alternatives of dialog windows in Cocoa? I need to create a custom dialog (modal) where the user will be able to enter some info and when he/she presses OK, my app will close this dialog and process input.
So essentially, I need something like a drop-down window in Xcode when you add a new file (command + N):
[not enough reputation to post a screenshot]
All I have discovered so far are a few old listings and topics where people say it's called a sheet. But the methods suggested seem deprecated, like
beginSheet: myCustomSheet
modalForWindow: window
modalDelegate: self
didEndSelector: #selector(didEndSheet:returnCode:contextInfo:)
contextInfo: nil
Are there any other ways?
For example, I can create a separate window with its own xib file, is there some kind of setting to make it a "panel" or "sheet"? I'm a bit confused by the terms.
What you want is a "sheet". A sheet is one window which is attached to another and blocks most inputs to the window that it's attached to.
A panel is just a specific kind of window. NSPanel is a subclass of NSWindow. It has some different behaviors and possible styles. You can use a panel as a sheet, but you don't have to and it doesn't make much difference.
Note that a sheet is window-modal, not application modal. That is, it prevents the user from doing other stuff with the window to which it is attached, but doesn't prevent the user from doing stuff in the app's menus or its other windows. Implicit in this is that sheets operate asynchronously. You begin a sheet and then execution continues without the sheet's work having been completed. You should then generally allow flow of execution to return to the main event loop. When the sheet completes, it will call some code that you have specified.
If you need synchronous behavior, use an app-modal dialog instead.
The modern API for presenting a sheet is -[NSWindow beginSheet:completionHandler:]. You send that message to the "normal" window (e.g. document window). The first parameter is the window which is to be the sheet. The completion handler is the code to be run when the sheet completes.
The controls within your sheet would typically target their actions to the window controller for the sheet (just as with any other window). Within the action methods, you would call -[NSWindow endSheet:] or -endSheet:returnCode: on the parent window to complete the sheet and determine the result code which is passed to the completion handler. You can obtain the parent window using the sheetParent property.
I had a question about Dialogs in VB.NET. I am working on a point of sale program, and at one point during a sale, I have a few windows that pop up. For example, a user will go into a sale that is window A. In window A, they have the option of entering products, etc., and if they choose a 'repair' product, it opens window B, allowing them to choose options. In window B, there is a button that pops up window C that allows them to attach products TO the repair. My issue is with window B opening window C.
Because I open window B as a Dialog (in order to check if DialogResult.OK is true), any window I open with B is non-touchable, as B is a Dialog and requires attention before going to any other windows/forms.
My question is - is there any way to still use a dialog, but allow for manipulating other open forms while the dialog is up, and if not, what would be the best way to check if the user selected OK, or cancelled out of the window?
The only solution I can think of right now would be to open window C as a dialogue as well (it's actually a UserControl, and I'm still trying to find where in the code it's actually getting openned/called), or to create a variable that is passed in to the form, and then passed back out when it's closed, that basically sets a flag to either continue or cancel...
Any advice/ideas??
If I were to explain this using code, this answer would be very long, so instead I'm going to give you a high level overview.
.Show() vs .ShowDialog()
The link below will take you off to Microsofts website to explain the technical differences between these two. However in laymans terms, .ShowDialog() will create the form where it is the only window allowed to have focus in the application. Forms that are called in this instance are hierarchical, in that if you open them in order of 1,2,4,3 then they must be closed in the 3,4,2,1 order. Forms that are opened with just .Show() can be focused at any time.
How to: Display Modal and Modeless Windows Forms
Form.FormBorderStyle property
This property controls how the OS will display the window. The different options under this selection changes the way the window behaves. Depending on the options that are chosen you can make a window that only has a close button on it, or it may not even have a title bar at all. Setting this option to None will take away all controls of the form and only leave you with the Me.ClientArea to work with. When you want a completely custom GUI, this is how you do it but you have to implement your own controls for everything, closing the form, size handles, the ability to move the form on the screen, etc...
Form.FormBorderStyle Property
Passing data between forms
When someone asks how to pass data back and forth between forms, they are usually talking about modeless forms that were created using .Show(). The most common thing I see on SO is to use the tag property of an object (a form is an object that has this property too) to pass data back and forth. While I won't say this is a bad practice, I will recommend creating public properties on your forms. These can be set from a separate form and you can perform additional actions when setting the values (be careful though, this way of doing things isn't thread safe). If you are using a Modeless form as though it were a Modal form, then you can simply override the .Dispose property to return a value or you can create a method named DialogResult that will return the value you need. The caveat to using a DialogResult or similar method is that if the form has been disposed then you can't access the value you wanted to return.
You can use myNewForm.Show(Me) for the Window you want to be shown as a dialog. This will show myNewForm as a child of the current form, but lets you interact with the current form.
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"
I have an application which displays a window containing widgets every minute. If I destroy this window by closing it in the window manager (linux), the destroy signal is sent. Then the next minute rolls around, at which time self.window.show_all() is executed and the window pops up empty.
So I did some investigating. I executed print self.window.get_children() just before the show_all command, which returned an empty list. So I executed self.vbox.reparent(self.window) and I get this response:
calendar.py:237: GtkWarning: IA__gtk_widget_reparent: assertion `widget->parent != NULL' failed
self.vbox.reparent(self.window)
These two responses seem to contradict one another. On the one hand, the empty list returned by print self.window.get_children() seems to imply that the window does not have any children. On the other, the output returned by self.vbox.reparent(self.window) seems to imply that self.vbox still has a parent, which would be self.window (as defined previously)
I've tried using a popup window: self.window = gtk.Window(gtk.WINDOW_POPUP) instead, but I would like to be able to close the window through the window manager, so that I don't have to add an additional button just to close (hide) the window. The popup window doesn't seem to provide this functionality in my window manager (awesome).
So if you want to redisplay a top level window with its children after it is destroyed, how can this be done?
Have you tried making another copy of
the window class and showing that one
instead? Note: This will reset anything that was set in the window. i.e. if a person did something to make label1 say 'Hi!' instead of 'Hello!', it is going to be reset again to 'Hello!', since you are recreating the window.
You can also set Gtk.Window.hide_on_delete as the handler for the delete-event signal; then closing the window will hide it instead of destroying it.
It may be very simple, but I cannot find it:
I have three windows in three separate NIBs in my application. One is opened when a new document is opened, the other two can be opened from the program's window menu.
The problem is: two windows (in them the one that is opened at the beginning) accepts the normal keystroke as for example command-s for save, and the other one does not and gives a warning sound instead. I cannot figure out the difference between the two windows or their controllers. I know it will have to do with the responder chain, but I am left clueless.
Any ideas?
Check to make sure that the window's delegate is set to the window controller, and that the window controller implements -saveDocument: (or whatever action the Save item is connected to).
Windows don't respond to key combinations. Menu items do. In response to being pressed (whether using the mouse, using a key combination, or using Accessibility), the menu item sends its action message down the responder chain.
You get a beep when nothing in the responder chain responds to the action message.
Assuming that this is an NSDocument-based application and you've started Apple's doc-based-app template, the menu item's action is saveDocument:, and the NSDocument object is the object that responds to that message. When your document windows are active, their documents are in the responder chain, so the menu item that sends that action message is enabled. When your third window is active, the document is not in the responder chain; nothing else responds to that message, so the menu item is disabled.
This problem isn't specific to Save—it affects all action messages that should go through to the document object. One important other example is Print: The user will probably mean to print the document, not the third window.
You've probably made this third window a kind of window that exists as a peer to the other windows. Besides this responder-chain problem you're having, the user will also probably not realize that they have left the document; they expect to still be able to do document things. Consider making it a utility panel instead.
If you really do have a good reason to make this window whatever kind of window it is, you'll need to keep the last-active document object in the responder chain when this third window becomes main, while at the same time handling the case where the window becomes main because a document window (possibly the last one) has closed.
Well, it turns out that I implemented the third window in a way where I created it with its controller using initWithNibFile, ran a procedure in the controller and then sent it a [window close] command because I did not want it to appear on the screen yet. That somehow took it out of the document-associated window, no idea why. No I migrated that specific called procedure into the document controller itself, treat the window like the second window and voila, it works again.