I'm using Number Pad keyboard and I programmed, when there is no text, when you press "Delete button" to trigger the function .endEditing , but the app crashes with this error:
Push segues can only be used when the source controller is managed by an instance of UINavigationController.
.resignFirstResponder() also crash with this error
I've tried adding a delay timer, but also crash.
changed to .endEditing(false) also crash.
Any suggestions without adding UINavigationController ? I can't afford to use UINavigationController, since my app must use the whole screen and I need all the space on it.
I've added UINavigationController and I hide it... If there are more options, feel free to share it :)
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.
My app displays various countdown timers that the user will view to see when to do various tasks. I'd like this screen to stay on display on the watch while the app is in the foreground. Currently, the screen will auto-turn off and if I stay away from flicking my wrist, the app will even become suspended.
Is this just something I'm going to have to design around, or is there a method I can't find to change this behavior?
There is no method in WatchKit to programmatically keep an app alive/awake. As you've suggested, you'll have to design around this limitation.
The correct way to have a countdown timer on the watch is to add it to the complication.
It supports a timer automatically when you provide a future date
CLKRelativeDateTextProvider(date: wakeupDate, style: .timer, units: .second)
I know how to open windows in Alloy, but I am worried about the effect on performance of opening lots of windows. In Classic titanium, you had to manage this carefully to avoid memory leaks, but i've seen very little on this for Alloy. Is this handled somehow by Alloy behind the scenes - can I just keep opening windows to my heart's content?
So if I have index.js opening category.js, which then opens product.js, but there is a button to open index.js - how do I handle that?
Try this: https://developer.appcelerator.com/question/176491/alloy-close-the-window-clear-the-memory
Simply closing the window does not free up any memory that has
references open from within the menu or any child views/function of
the window. It is common to create a cleanup method and publicly
expose this from the controller. You then make sure that anything you
created or referenced inside this controller has been nulled, removed
or reset - within this function. Add an event listener to the window
inside the controller to handle the close event and then have it call
the clean-up function. Finally removing that event listener as well.
Some things to check for in your clean-up function Event Listener -
use Remove Event Listener once they are nbo longer required For tables
simply use table.setData([]); nothing more complicated than that If
you use setTimeout or setInterval you must always clear(thing) each of
these There are more but these are the highlights.
Something seems to have changed in Qt 5: you can't get a drop or move event if you don't move at least one pixel from the start point where you were when QDrag::exec() was called. Try putting a breakpoint in the dropEvent of the Draggable Icons Sample, then click a boat and release it without moving the mouse. That generates an "ignore" without any drop signal.
(This is on Kubuntu 13.10 with Qt 5.1.)
When teaching how to start a drag operation, the documentation suggests you might use manhattanDistance() to determine if the mouse has moved enough to really qualify as "the user intending to start a drag". But you don't have to use that; you can start up a QDrag on the click itself.
Anyone know of a workaround to have that same kind of choice on the drop side, or is that choice gone completely? :-/
Why I care: I've long had frustrations trying to get a tight control on mouse behavior in GUI apps—Qt included. There seems to be no trustworthy state transition diagram you can draw of the invariants. It's a house of cards you can disprove very easily with simple tests like:
virtual void enterEvent(QEvent * event) {
Q_ASSERT(!_entered);
_entered = true;
}
virtual void leaveEvent(QEvent * event) {
Q_ASSERT(_entered);
_entered = false;
}
This breaks all kinds of ways, and how it breaks depends on the platform. (For the moment I'll talk about Kubuntu 13.10 with Qt 5.1.) If you press the mouse button and drag out of the widget, you'll receive a leaveEvent when you cross the boundary...and then another leaveEvent when the button is released. If you leave the window and activate another app in a window on screen and then click inside the widget to reactivate the Qt app, you'll get two consecutive enterEvents.
Repeat this pattern for every mouse event, and try and get a solid hold on the invariants...good luck! Nailing these down into a bulletproof app that "knows" it's state and doesn't fall apart (especially in the face of wild clicking and alt-Tabbing) is a bit of a lost cause.
This isn't good if your program does allocations and has heavy processing, and doesn't want to do a lot of sweeping under the rug (e.g. "Oh, I was doing some processing in response to being entered... but I just got entered again without a leave. Hm, I guess that happens! Throw the current calculations away and start again...")
In the past what I've done is to handle all my mouse operations (even simple clicking) with drag & drop. Getting the OS drag & drop facility involved in the operation tended to produce a more robust experience. I can only presume this is because the testers actually had to consider things like task switching with alt-Tab, etc. and not cause multiple drop operations or just forget that an operation had been started.
But the "baked in at a level deeper than the framework" aspect actually makes this one-pixel-move requirement impossible to change. I tried to hack around it by setting a timer event, then faking a QMouseEvent to bump the cursor to a new position once the drag was in effect. However, I surmise that the drag and drop is hooked in at the platform level, and doesn't consult the ordinary Qt event queue: src/plugins/platforms/xcb/qxcbdrag.cpp
The issue has--as of 1-May-2014--been acknowledged as a bug by the Qt team:
https://bugreports.qt-project.org/browse/QTBUG-34331
It seems that me bountying it here finally brought it to their attention, though it did not generate any SO answers I could accept to finalize the issue. So I'm writing and accepting my own. Good work, me. (?) Sorry for not having a better answer. :-/
There is another unfortunate side effect of the Qt5 change, pointed out by a "Dmitry Mordvinov":
Same problem here. Additionally app events are not handled till the first mouse event after drag started and this is really nasty bug. For example all app animations are suspended during that moment or application hangs up when you try to drag with touch monitor.
#dvvrd had to work around it, but felt the workaround was too ugly to share. So it seems that if you're affected by the problem, the right thing to do is go weigh in...and add your voice to the issue tracker to perhaps raise the priority of a solution.
(Or even better: patch it and submit the patch. 'tis open source, after all...)
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.