When I click a input button.
It show another window.
My code like this.
Click and show other window. (the window names windowB)
OpenMEMO <- remDr$findElement(using='id', value='form1:searchListTable')
OpenMEMO$clickElement()
After doing something, I want to close windowB.
But I don't know how can I do.
I try to use
#retrieve the current window handle
currWindow <- remDr$getCurrentWindowHandle()
#retrieve the list of window handles used in the session (I have 2 windows)
windows <- remDr$getWindowHandles()
#change focus to another window (windows[[2]] is windowB)
remDr$switchToWindow(windows[[2]])
#close the current window
remDr$closeWindow()
I run remDr$closeWindow().
But it closed the original window. (Actually, I want to close windowB)
Maybe I misunderstood the usage of the code.
Please give me some suggestions.
Thanks.
Because it's intranet, I cannot provide a website link.
Related
Looking Glass debugger of Gnome Shell provides Windows tab that lists all opened windows. Instance of such windows can be referenced from Evaluator tab after clicking, for example: [object instance proxy GType:MetaWindowX11 ...]
How can be process id of process of the selected window obtained in Evaluator tab?
There is get_client_pid() method defined in Mutter project, however it can't be called directly.
I'm just from asking something very similar on the Gnome Shell IRC, this is what I found out from the very helpful folks there:
I you open Looking Glass and click the Insert button in the upper right corner (eg. after selecting a window from the Window list), you'll get something like r(x) = ... in the evaluator (with x being a sequential number). You can then call any method on the object like so:
r(1).get_window_type()
Hope this helps!
Kind regards,
In Looking Glass:
Click on tab "Windows".
Select the desired window.
Scroll down, looking for "get_pid()".
Scroll to tab, click on "Insert" button.
Click on tab "Evaluator".
In bottom text field enter last output "r(x)" followed by ".get_pid(), for example "r(0).get_pid()", press Enter/Return.
Note the output, which is the process ID.
I'm developing a GUI in Linux (Ubuntu 16.04 - WM: Gnome) using GTK+3 and the graphic library cairo.
After clicked on a push button (Plot), using the instruction of cairo I draw a red square on a new top window where I put a GtkDrawingArea.
In this window I also put a push button (Cancel) that clicked, hide the window. In this way, if I re-push "Plot", the red square reappear.
The issue is the "x" icon present in the top bar of the window.
If (no me) a user push this x, the window disapper and if he re-push the "Plot" an error is reported.
The question is: it is possible avoid this possible cause of error?
(remove this "x" from the top bar of the window or in some way disable its functionality).
I tryed to find alone a solution and the possibility found are:
1 - Remove from the window the property of "decorated".
The top bar disapper (so also the x) but is not possible move the window on the screen
2 - Using the function gtk_window_set_deletable(window, FALSE) (used before to show the window), but the x is always there and pushing it the window is destroyed.
If you think that can be useful, I can report the code.
I'm waiting your suggestion.
Edit:
Now we know what you want to achieve: display a separate window but avoid destroying it so you can display it again. You already have in the "Cancel" button of your secondary window the logic to hide it.
The cleanest solution is to just do the same: when the user tries to close the secondary window, hide it instead. This way the user is not frustrated of seeing something that apparently doesn't work as expected. Hidden or closed, it's different for you but it's the same for the user.
So you just need to connect to the delete-event of that secondary window, and hide it. There's even no need to create a specific callback for that, GTK+ provides it for you: you just need to connect the delete-event to gtk_widget_hide_on_delete. To display the window again, just call gtk_widget_show_all on it.
Original answer:
I realize the plot
"realize" is a term that has a defined meaning in GTK+. Don't use it out of context, and try to use an alternate term if you're not talking about widget realization.
What I would like is to remove this "x" from the top bar of the window
or in some way disable its functionality.
Do you understand this is ultra annoying for a user and defeats a unified user experience? Would you like to use applications that do random different things?
Anyway, one way of disabling the closing button is to connect to the delete-event and return TRUE there to stop the propagation of the event. The button will still be there but do nothing, so you will have to kill the app to exit it.
To make the button disappear, gtk_window_set_deletable will ask the Window Manager to do that, but we'd need some code to know what's wrong with your attempt.
I am storing values of extjs desktop window in a database.
Case:
When user minimized a window and logs out,
the window should stay minimized when he logs in again.
Now on logon the before minimized window pops up
The values are all there! But I cant find the property to set...
I tried hidden:true, but no effect.
I was looking for a property to set when creating the window for extjs-desktop. But a superior function is invoking creation, takes window as response and does "win.show()". At this point i am checking the "minimized" value delivered by AJAX.
I have this problem:
In a C# WPF application:
I open a new Window (showOnTaskBar=true, noresize, centered);
From this opened window I open another one that is above the other opened window. The new window is without blue top bar and
showOnTaskbar=false, showDialog();
Everything is ok but if I change the focus, I mean, for example, I open Firefox or another program and then I want to go back to my
opened windows I saw just the first opened window (from step 1) the
other modal window comes up only with ALT+TAB.
So, is there a way to keep both windows always displayed ?
Code to open the second window (from the first normally opened window in step 1):
Form2 form2 = new Form2();
formA2.ShowInTaskbar = false;
form2.ShowDialog();
Thank you,
Adrian
If as I think you have said you are opening the second window from the first, I'm pretty sure you want to try setting the owner of the dialog like this:
form2.Owner = Window.GetWindow(this);
See WPF: How do I set the Owner Window of a Dialog shown by a UserControl?
Hope this helps,
Jay
I like how MsgBox stops all further processing until it's clicked but I don't like how it pops that little msgbox in the middle of the screen. Is there a way to do something like a msgbox but keep it on my Form (which is always in view) so I can go ahead and click a button on the form instead of having to bring the little msgbox window on top of windows that may be covering it.
I use the msgbox to inform me that a certain situation has happened, which I manually fix and when I'm done I click the MsgBox to continue processing. It'd be nice to have this button right on the form.
which I then have bring to the front if there is a window covering it
That shouldn't happen, but can happen if you display the message box from a thread in your program. The window has the desktop as the parent and has no Z-order relationship with the windows in your user interface. And yes, can easily disappear behind the window of another app, including your own.
There's a MessageBoxOptions option that isn't exposed in Winforms, MB_TOPMOST, which ensures the window is top-most. You'd use it like this:
MessageBox.Show("text", "caption", MessageBoxButtons.OK,
MessageBoxIcon.Information, MessageBoxDefaultButton.Button1,
(MessageBoxOptions)0x40000); // use MB_TOPMOST
But by far the best thing to do is to display the message box on your UI thread. Use Control.Invoke() to do so. That way the other windows of your app are disabled, no way for the user to not notice the box.
Still one problem with this, the user won't expect the box to show up since it is shown asynchronously from anything she does. Which means the box can easily get dismissed by accident when the user just happened to press the Enter or Space key. Or clicked at just the wrong spot. Nothing much you can do about that.
Centering the box in your main window is technically possible, but fugly to do. Check this answer.
Do you mean that the form shall exchange its contents with a message plus an OK button?
This would be similar to the way a text mode interface typically works.
You can make it happen by adding a disabled panel or UserControl with message and button topmost on the form and enable it when you wish to alert the user. However, I am puzzled how to implement the blocking behavior similar to MessageBox.Show() and Dialog.Show().