I have a very strange problem. The application is based on Qt C++. There is a TabWidget whose tabs are created dynamically. The tab contains QtMainWindow in ActiveX widget. When multiple apps are started, the selected one works fine. But when another tab is selected, it becomes unresponsive.
When I minimize the Application and then maximize again then the tab starts working fine. I tried with setFocus, activateWindow, showNormal and setActiveWindow but nothing is working.
Can somebody help me in this issue?
The likeliest cause of the app becoming unresponsive is something that stalling the execution on the main thread. With running the project from/ or attaching to Visual Studio debugger (better debugger than the one used by Qt Creator) try to get your app in such unresponsive state. Now look at Main Thread in Threads view (select one), also look at Call Stack view. Where does the execution stall?
The log in Output View is also helping to recreate the context of how to get there. You can see Qt and your own debug output there.
While debugging I found that the App was not syncing because of missing WA_Mapped attribute. My problem was just opposite of the below issue. When I used to maximize after minimize, the App used to become responsive. Finally setting the attribute WA_Mapped at different places (trial n error) fixed the issue.
widgets freezing after minimise window
Thanks for #AlexanderVX response.
Related
Is it possible to write tests for a JavaFX application, which do not fail upon mouse mouvement generated by the human user ?
I am a beginner in JavaFX and TestFX, and it seemed to me that TestFX stops everything as soon as it detects that the mouse has been moved.
In another project, which uses Eclipse RCP and SWTBot, this seemed to work out-of-the-box, as long as the application under test had the focus. Is there any way to get the same behaviour with TestFX, or any other test framework for JavaFX ?
As a workaround, on Linux, it's generally advised and useful to create another X session (using Xephyr for example) and to run tests in this X session by setting the right DISPLAY property.
With that, the event processing is isolated on both DISPLAYs so tests are not "polluted" by parallel human actions on the other DISPLAY and can run with less troubles.
We are currently testing parts of our application that open in popup windows. These windows are subclasses of TitleWindow. The issue we now run into is that the popups seems to be registered multiple times and that tests are sometimes executed on popups that have already been closed (or so it seems).
I thought this had to do with the way we closed and removed our popups, but I can't really spot any problems there. After looking into the FlexMonkey source code, I saw that there is an explicit check for "TitleWindow" in the ADDED_TO_STAGE handler, after which the popup is added as an application window. But the popup never seems to be removed from the "_windows" collection. As a result, when you open the tree view in FlexMonkey, there are several instances of the same popup window class. This probably also explains why our tests sometimes do not seem to run (visually), but execute and verify correctly, as they are ran on a hidden instance of a popup. I would expect the MonkeyAutomationManager to also listen to REMOVED_FROM_STAGE events and remove the popup when it is closed.
Am I missing something here or is this an (known) issue?
My guess is that it isn't an issue, it's simply that your code isn't properly cleaning the object and removing it from the display list. You also need to remember that garbage collection does not run right after you remove something from the stage. It could be possible that your window, even if it has been removed from the stage is in fact still listening and responding to events.
I would like to know the correct way to close an AIR application programmatically.
In my Spark WindowedApplication I have:
this.addEventListener( Event.CLOSING, shutdownApp );
and of course an implementation of the shutdownApp method (which basically tidies up temporary files).
This works fine for the top-right close button of the window. However I also have functionality which needs to shutdown the application. Within the code I have called:
NativeApplication.nativeApplication.exit();
However this doesn't trigger the Event.CLOSING method, and so my temporary files are not cleared up. Should I not be calling nativeApplication.exit ? If so, what should I call instead? I'd rather not have to call my shutdownApp method before the NativeApplication.exit() as this doesn't feel quite so elegant.
Can anyone shed any light on the correct way of doing this?
Thanks,
Phil
I know this question has been answered and accepted, but thought I'd share, I use.
stage.nativeWindow.close();
The documentation looks a bit ambiguous on this and I would have the same interpretation that you did. Did you try the close or exit methods on the WindowedApplication?
Something like this, with FlexGlobals and topLevelApplication:
(FlexGlobals.topLevelApplication as WindowedApplication).close();
or
(FlexGlobals.topLevelApplication as WindowedApplication).exit();
Just give an answer here because I searched for a related question and was not able to find sth.
I wanted to do something similar and close an AIR application when the native close button of the document window (spark.components.Window) is pressed thought that the spark WindowedApplication container (the applications main window) is still active to hold and manage the native menu (at application startup it is also used to display a splash screen. It has to stay open since if it is closed the native menu won't show up or be accessible anymore so its visible property is just set to false).
My main problem was the window closing event. Registering it with ActionScript like
this.addEventListener(Event.Closing, windowClosed);
does not work: No closing event was dispatched.
The only way was to register an event handler directly in the s:Window element at start of the MXML file. I just throw in the closing attribute:
closing="window1_closingHandler(event)"
The event was dispatched then and in window1_closingHandler-function I called
NativeApplication.nativeApplication.exit();
That works for me and shuts down the whole application.
Have a rather bizarre issue with Flex throwing an error when teh application is running in the background. I use Selenium and SeleniumFlexApi to run various tests against my app. If the browser window is in the foreground or any part of it is visible to teh screen, the test pass as expected. However, if the window is in the background and not visible, I am getting the following error in 1 part of my app.
ArgumentError: Error #2025: The supplied DisplayObject must be a child of the caller.
I have a VBOX that creates a number of children and then upon creationComplete(or UpdateComplete, I've tried both) it then needs to remove any of the children that are not visible. Each child has a listener for CreationComplete which checks if the child is visible and if not, adds it to an array which is iterated over when the parent UpdateComplete is fired. I cant seem to find any reason for this behavior and am curious if its an issue with the Flex Component LifeCycle.
The most recent version of the Flash Player (10.1) will automatically "slow down" when minimized. I think it drops to a couple of frames a minute [as opposed to the standard 24 per second for Flex]. I don't know specific number.s This is for performance and 'battery life' reasons.
If there is anything in your app, or in your testing, that requires specific timing or uses a timer, then this will easily break unit tests.
I've heard from other folks that this have other folks that have had issues with this. The best solution I've heard proposed is "Add a flag to turn this off; even if it's only in the debug player." But, there is no solution right now other than "run your tests w/o the app minimized"
I have an AIR app about half way done right now. I was informed by the client today that he does not want a tab to show up in his task bar. I already have this in place for new windows by making them lightweight. I do not know how to make the main window lightweight though. If there is not a way, is there a work around, like not not having a main window and just opening lightweight windows, don't know how that could be done either though? Anyone know how to do this?
Thanks!
Check this doc out. -- Yes, you can do this. In short, you have to hide the initial window - then display your application in a lightweight window.
Also - do note: On a Mac - the behavior is different. By convention, a window is not shown in the 'task bar' when it is displayed. When it is minimized it is in the bar. To hide the application when minimized on a Mac - you have to make the window 'invisible' instead of minimizing it. The doc mentioned above gives further details.
The key part of the doc for your case:
On the Windows operating system,
windows created with the types utility
or lightweight do not appear on the
taskbar. Invisible windows do not
appear on the taskbar, either.
Because the initial window is
necessarily of type, normal, in order
to create an application without any
windows appearing in the taskbar, you
must either close the inital window or
leave it invisible.
To close all
windows in your application without
terminating the application, set the
autoExit property of the
NativeApplication object to false
before closing the last window. To
simply prevent the intial window from
ever becoming visible, add
false to the
element of the
application descriptor file (and do
not set the visible property to true
or call the activate() method of the
window).
In new windows opened by the
application, set the type property of
the NativeWindowInitOption object
passed to the window constructor to
NativeWindowType.UTILITY or
NativeWindowType.LIGHTWEIGHT.