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.
Related
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.
From what I see, QApplication::mouseButtons() may return no buttons even when a button is held down. This happens when you have clicked a side of a window for re-sizing. It's coherent with the docs because mouseButtons() reflects the state from the flow of QEvent::mouseButtonPress, etc. However, I need just to know if the button is held down. Does any one know if it's possible through the Qt API?
I think it's not possible. Mouse events outside an application's window are not passed to its event handlers. Dragging mouse borders is one of such events, it's processed by the window system. Another example is clicking on other windows. Usually an application doesn't know what the user does with other windows. You need to install system-wide event listener or use native API features(e.g. GetAsyncKeyState on Windows) to determine that. This behavior is unusual and possibly dangerous. In most cases it's not useful, and it seems that Qt doesn't have this ability.
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 came across this topic today while investigating something very strange. Doing certain things in our Flex app can cause the number of frames rendered to rocket, from 12fps to ~30fps: loaded animations start playing at high speed and the GUI starts to lock up.
Since everything I've read on Flex/Flash hammers home the point "the frame rate is capped at the fps set in the top level app", it seems the only way these extra renders can be happening is due to some events causing them (no programmatic changes to the stage's framerate are done anywhere). Since it only happens when I put my update logic in the ENTER_FRAME handler, I'm trying to figure out what might be happening which to apparently causing Flex to go render-crazy.
Hypothesis: something in my update function is triggering an immediate screen update, this raises another ENTER_FRAME immediately, which means my update loop gets called, which triggers another immediate screen update, ...
We have Flex components used in our GUI, if this is a factor. I don't really know where to go next on this.
Clarifications:
When I say things speed up, there
are two ways this manifests.
Firstly, my ENTER_FRAME handler gets
called far more often.
Secondly, a
loaded Flash SWF with a looping
animation built in suddenly speeds
up to te point it looks silly.
I am not using updateAfterEvent, I only
found this existed when researching
this problem. Apparently, some
events on Sprite subclasses
automatically call this and I wonder
if that's the root cause.
I am not doing any direct messsing about with rendering at all. Background animations play automatically as they have timelines built-in from CS3 authoring, all our update function does is change the position of DisPlayObjects or add/remove them etc
Update:
I added a label to my app to print out stage.frameRate, and discovered at certain times, it suddenly changes from 12 to 1000 (the maximum allowed value). While it was trivial to add a line to my ENTER_FRAME handler to reset it that's hardly a big help.
Also, even doing this, the rendering is all messed up. Certain actions (like raising an Alert popup) make it all spring back into life.
Unfortunately, I am not able to view the source of the Stage class to set a breakpoint on the setter property.
That's very interesting about the Flex loading 'set to 1000fps' thing. What we have are several Flex applications which all provide a common interface. A master app is in charge of loading these modules as required through the SWFLoader class. However, the loading process already takes into account the delayed loading... when the SWF loads we then wait for the APPLICATION_COMPLETE from the SystemManager. Once this is received, shouldn't the applications completion have occurred?
Flex sets the frame rate to 1000 during "phased instantiation" of Flex components, which occurs only during initial load of a flex swf. This allows it to build all components very quickly.
Are you waiting for the Flex app to be fully loaded and constructed? You should be waiting for FlexEvent.CREATION_COMPLETE before working with your Flex content.
If you would like a reference to where this occcurs, look in the Flex LayoutManager class, line 326 (using Flex SDK 3.0.194161), in the setter for the property usePhasedInstantiation.
Update:
APPLICATION_COMPLETE should have you covered for the initial load.
This actually happens any time components are created directly from MXML. So there are a few other cases to look for. Are you using any Repeaters? Do you use any navigation containers that are building their children on demand?
One thing I'm not clear on - are you seeing that the actual screen refreshes are occurring faster than the published framerate? Or is it that your animations are moving faster but the screen refreshes are unchanged? (i.e., it used to move 10 pixels per second, but now it moves faster than that, regardless of how often the screen is drawn.)
An easy way to check this would be to try publishing your content at 1 fps. It should be clear whether the screen is redrawing once per second, but animated elements are being moved more frequently than that, or whether the screen is actually updating more frequently.
If the latter, are you using any updateAfterEvent() methods in your code? This can cause actual screen refreshes to occur faster than the published framerate. It shouldn't affect ENTER_FRAME events though. You should still only get one of those per frame update.
Alternately, are the things you're animating just Sprites and so on, or are you implementing them as Flex components, and trying to redraw them with invalidate() methods and RENDER events and so on?
If you could clarify a few of these points in the question the answer might be clearer. Thanks...
Thanks for the clarifications. If a loaded clip with a animation (I assume you mean a frame animation) is speeding up, then that certainly sounds like something is changing your playback framerate, as opposed to other things that could be going on. With that said it's not a problem I've seen crop up before, but I do think there are some things you could try that ought to narrow down where the problem is:
You might as well try tracing out stage.frameRate during the speed-up. Presumably nothing ought to be changing your framerate, but since that would explain your issues you might as well rule it out.
Try removing as many GUI components as possible and seeing if the problem still occurs, if it's possible to trigger the problem without them.
One sanity check you could try, if it's feasible, is to copy some of the contents of your game into a fresh project and try it there. Sometimes mysterious issues like this happen because some class or SWC is being imported somewhere that everyone forgot about.
You could try driving your code from a different event. For example, as far as I know driving it from Event.EXIT_FRAME or Event.FRAME_CONSTRUCTED ought to look the same, but if it doesn't then that's a hint. Alternately, you could try driving it from something like a keyboard event or MouseEvent.MOUSE_MOVE. Then if updates occur even though you're not firing events, you'll know something else is driving things besides your event loop.
Those are the things I'd try, anyway. Hope you track it down...