Good day!
Have a problem: main window (MyApp for example) works in background (behind all other windows or in tray), not necessary to show it without need. After some period of time some reminding StayOnTop dialog appears (having parent = 0, to be not tied to main window) and asks for some user interactions. After dialog closes I’d like to keep an application window user currently working with active, and user continue do his job not switching to MyApp. However, instead of above behaviour, main MyApp window appears and user forces to switch back to his window (job) – inconvenient.
How to prevent MyApp main window appearing after closing the dialog? Need to install some event filter or access OS API? Problem exists in Mac, Windows, Linux.
You could try to re-implement the main window's showEvent and ignore that event, in case other windows are visible.
void main_window::showEvent( QShowEvent* e )
{
if( /*one or more of its children are visible */ )
{
// nothing to do
}
else
{
QMainWindow::showEvent( e );
}
}
Maybe just try invoking hide method after dialog call? Other possibility - try setting this:
http://doc.qt.io/qt-4.8/qwidget.html#windowFlags-prop to Qt::Popup.
Related
I am trying to make a JavaFX application (running in the background to show up (set visible)) by a specific keystroke and to make the window the active window immediately. Therefore I set the primary stage alwaysOnTop-property true, call stage.toFront() and finally call stage.requestFocus(). Afterwards I request focus for a text field. When the window is made visible I would like to instantly start typing into the text field.
However, when I for example have a Ubuntu-terminal selected and make the window visible and start typing, the application is shown on top of everything, however, the typing goes to the terminal. The application window is not active! Nevertheless, the focused property of the stage is true. Is that a bug or am I missing something? Is it OS related?
Edit: I am willed to give my little hack-around for this problem that I am using at the moment, because the internet is suggesting, that a lot of people are facing this problem: Since I am working on a linux maschine I have access to the wonderful tool wmctrl. It is part of most standard repositories. wmctrl -a WINDOWNAME sets the window with the name WINDOWNAME active. For now, I simply call this tool from my source code when I need the window to be active. Since this is more of a dirty hack than any thing else, I sure want to get rid of it.
Not perfect, but it works:
Platform.runLater(() ->
{
//primaryStage.setAlwaysOnTop(true);
//primaryStage.setAlwaysOnTop(false);
primaryStage.setIconified(true);
primaryStage.setIconified(false);
});
If your node is not getting focused, try wrapping requestFocus() in a Runnable and call Platform.runLater():
final TextField text = new TextField();
Platform.runLater(new Runnable() {
#Override
public void run() {
text.requestFocus();
}
});
Setup: My Flex application is one consisting of several "subapps". Basically, the main application area is an ApplicationControlBar with buttons for each of the subapps. The rest of the area is a canvas where the subapps are displayed. Only one subapp is visible at a time. When switching between subapps, we do a canvas.removeAllChildren(), then canvas.addChild(subAppSwitchedTo). It's essentially a manual implementation of a ViewStack (the pros and cons of which are not the topic of this, so refrain from commenting on this).
Problem: In one of my subapps (let's say subapp "A"), I have a search function where results are displayed in a TitleWindow that gets popped up. Workflow is like enter search criteria, click search button, TitleWindow pops up with results (multiple selection datagrid), choose desired result(s), click OK, popup goes away (PopUpManager.removePopUp), and continue working. This all works fine. The problem is if I switch to a different subapp (say "B" -- where A gets removeAllChildren()'d and B gets added), then switch back to A and search again, when the results TitleWindow pops open, there will be TWO stacked on top of each other. If I continue to navigate away and back to A, every time I search, there will be an additional popup in the "stack" of popups (one for each time A gets addChild()'d).
Has anyone else experienced this? I'm not sure what to do about it and it's causing a serious usability bug in my application. Does this ring any bells to anyone? It's like I somehow need to flush the PopUpManager or something (even though I'm correctly calling removePopUp() to remove the TitleWindow). Please help!
EDIT
Flex SDK = 4.5.1
// Subapp "A"
if (!certificateSearchTitleWindow)
{
certificateSearchTitleWindow = new CertificateSearchTitleWindow;
certificateSearchTitleWindow.addEventListener("searchAccept", searchOKPopupHandler);
certificateSearchTitleWindow.addEventListener("searchCancel", searchClosePopupHandler);
}
PopUpManager.addPopUp(certificateSearchTitleWindow, this, true);
My guess is that the popup is removed from the main display list when you remove its parent (this in the PopUpManager.addPopup() method), but not from its parent display list. Why don't you listen, in your subapps, to the Event.REMOVED event, and then remove your popup ? That would be :
private var pp:CertificateSearchTitleWindow;
private function onCreationComplete():void
{
addEventListener(Event.REMOVED, onRemovede);
}
private function addPopUp():void
{
if (!pp) {
pp = new CertificateSearchTitleWindow();
PopUpManager.addPopUp(pp, this, true);
}
}
private function onRemoved(event:Event):void
{
if (pp) {
PopupManager.removePopUp(pp);
pp = null;
}
}
Thank you to those who gave suggestions. It turned out I was re-registering an eventListener over and over.
I am using a singleton to act as "shared memory" between the subapps. I was setting singleton.addEventListener(someType, listener) in subapp A's creationComplete callback. So everytime I navigated back to A, the creationComplete was running and re-adding this listener. After the search, the listener method (that opened the popup) was being called multiple times, i.e., as many times as the event had been added.
xref: http://forums.adobe.com/message/3941163
The application I'm working on is a HTML AIR application based on the AIR 2.5 SDK.
The application starts two windows: the first is a hidden window that registers it's self on the system tray (it's windows specific); the second is a visible lightweight window displaying showing various bits of information. Since the visible window is lightweight, there is no task bar entry to always the user bring the window to the front if hidden under other application windows.
The requirement is that on clicking the system tray icon the display window will be brought to the front.
My current solution looks something like:
function handleClick(){
var nativeDisplayWindow = findDisplayWindow();
nativeDisplayWindow.alwaysInFront = true;
nativeDisplayWindow.alwaysInFront = false;
}
function findDisplayWindow(){
// looks in air.NativeApplication.nativeApplication.openedWindows for the
// the display window and returns it
}
It works but really doesn't feel right.
I've tried using NativeWindow.orderToFront() & NativeWindow.activate() and various combinations of all the other method.
Is this the correct way to bring a window to the front of all application windows in AIR?
If you try casting your nativeDisplayWindow as a Window you should then be able to do something like:
function handleClick(){
var nativeDisplayWindow:Window = findDisplayWindow() as Window;
nativeDisplayWindow.orderToFront();
}
I don't know if this is what you are looking for or whether I've just repeated what you've explained?
Can a Flax Air Window (NativeWindow) be modal? how?
I think you need to expand on your use case.
If you want it to be modal, do you want to shut down the entire operating system until this window is handled by the user? I doubt that is possible. Do OSes support that in any way? (Other than when crashing).
If you want to prevent your app from being used while this window is up, don't use NativeWindow use a component with the PopUpManager. It has a modal property when creating the popup.
Another possible way would have been to do something like
private function _onActivate(__e:Event):void
{
if ( _settingsWindow )
{
__e.preventDefault();
_settingsWindow.activate()
}
}
and when you open up your settings window, set everything on the "mainapplications" stage to mouseEnabled = false; mouseChildren = false; and listen for the settingswindow close event to reactivate the mouse enabled and set _settingsWindow to null and mainapplications window to activate again (just to make sure)
Is there a way to make a Perl/Tk window's close ('X') button disabled?
I know how to ignore clicking it using the technique described here, but I would much rather have it disabled.
I'm using Perl/Tk on Windows.
Thanks,
splintor
If you are in a Unix environment you are out of luck. The "close" button is managed by the Window Manager of the desktop which is a completely different process that you have no control on.
Even if by a hack you disable the "close" button the user can always bring it back
if the window manager permits this. The enlightenment window manager for example can
enable/disable all window buttons on demand.
The technique you give in the link is doing exactly this. It does not remove
the "close" button. It just gives a hint to the window manager (WM_DELETE_WINDOW).
It is up to the window manager if this hint will be honoured or not.
See also the icccm and NetWM pages.
What you want might be possible on Windows, but my experience with this OS
is limited so perhaps another poster will know this.
I have an app that I wrote, i was wondering about the same thing, and i don't disableit, but i have a call back to a subroutine, that simply does return;
$Mw->protocol('WM_DELETE_WINDOW',sub{return;});
According to the Perl Monks, it looks like the following works on Windows:
#!/usr/bin/perl
use warnings;
use strict;
use Tk;
my $window = new MainWindow;
$window ->title("Close test");
$window ->geometry("400x250");
#prevents window from closing
$window->protocol('WM_DELETE_WINDOW' => sub {
print "Do stuff before exiting\n";
exit;
});
MainLoop;
In the above code, you are intercepting the signal sent when the user presses 'X' and can then write your own subroutine to execute when the button is pressed.
If you want to disable the close icon, set sub to empty (effectively telling it to "do nothing when pressed"): 'WM_DELETE_WINDOW' => sub {}
If you don't manage to really disable the close button (I mean to grey it out or even remove it from the window decoration), it might be the most intuitive thing to iconify your window instead of closing it. This is what I did.
$window->protocol('WM_DELETE_WINDOW', sub { $window->iconify(); } );