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.
Related
I'm still new to rebol and programming in general, and I'm trying to write a program for practice.
In this program, there is a main window, which includes a button with which I want to open a new window, and close the main window at the same time.
Now, I know how to do each function separately, but how do I combine them together?
This is what I tried:
button "Start" [view start-win unview main-win]
What's happening is that start-win opens when I click the button, then immediately all the windows close.
view starts an event loop - so no code executes after that until the window view opened closes.
To start a new window without that happening, use view/new - then to start the event loop when you are ready, do-events
unviewremoves the last added window and does not take any arguments by default. To close a specific window use with refinement unview/only window-name
So in your first case you create a new window and next close it. In the other case you start closing the last created window and next create a new one.
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.
Is the first window guaranteed to be the main window? Or is the order random and inconsistent?
for (String handle : driver.getWindowHandles()) {
driver.switchTo().window(handle);
}
I can't find any information about the order of the window handles, just a way to iterate thorugh them all. I am assuming that the first in the list of window handles is going to be the main window.
According to the current WebDriver API Specification:
6.3 Iterating Over Windows
getWindowHandles
An array containing a window handle for every open
window in this session. This array of returned strings must contain a
handle for every window associated with the browser session and no
others. For each returned window handle the javascript expression
"window.top.closed" (or equivalent) must evaluate to false at the time
the command is being executed.
The ordering of the array elements is not defined, but may be
determined by iterating over each top level browser window and
returning the tabs within that window before iterating over the tabs
of the next top level browser window.
In short, no - there is no guaranteed order.
As alecxe pointed out the handles can be in any order.
I solve the issue of knowing which handle is the main window by saving the handle immediately after I point Selenium to the first page to load (at this point the list of handles contains only one handle, which is the main window), and I save this value for future use. Then when I scan the list of handles later, I compare with the value I saved and know that handles that don't match it are not the initial window.
Doing this is useful in "tear down" or "clean up" code between tests in a test suite if you have some tests that may open other windows. Using the method I describe here, your tear down code can be generic and not worry about whether any specific test is actually opening additional windows.
I need to create a form where AlwaysOnTop = True when the browser is visible. This creates some sort over "overlay". The logic works like this:
The program checks which window is active.
If the active windows is a certain process, my form will initialize the TopMost utility, and be the active window itself.
When the certain process is not the active window anymore, my form will disappear.
How I did it:
My program checks if a browser is the active window, if so: the form gets topmost and the program stops checking what the active window is. (because my topmost form is the active window now).
Now the program needs to check what the window under my form is, the second active window.
If it's not the browser anymore, the form needs to hide, and the program will check what the active window is again.
I already completed the function that checks what the first active window is,
I'm stuck on getting the function that checks what the second active window is.
I'm not sure that there's such as thing as a "Second active window" - its either active or its not.
Why don't your leave you active window checker running after the first step of detecting the browser.
You can detect when the active window is no longer your form and hide your overlay then.
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.