i'm playing around with the navigator class and custom views within air for android and the Flex HERO SDK
my problem is that it seems like there is no way how to terminate a view.
i start a view using navigator.pushview(myView).
then, when using the return button, i want to CLOSE that view and return back to the main menu.
therefore i'm listening for the onKeyDown Keyboard.BACK event using event.preventDefault() to prevent the application from running the default "go back" action and the navigator.pushview(myOtherView) to go back to main menu.
BUT the problem is that the myView view still seems to be running in the background.
now i'm looking for a way to terminate that myView and everything that is running within in (atm, if i access the cam, the cam is still active even if the view is not active anymore)
can anyone help?
Assuming the navigator data-provider functions like ArrayCollection you could do something like navigator.removeItemAt( navigator.getItemIndex( myView ) );
And then shutting down the camera, and ultimately removing all handles to the myView, and setting it to null, to have the GC pick it up..
Beware syntax may be different when you wish to remove the item. I never used the navigator..
Related
I need to execute some native code to interact with the macOS menu bar, ideally immediately after it got initialised. IMHO, a good time would be right after the JavaFX application window becomes visible.
From the documentation, I thought that Window.onShown should do exactly that:
Called just after the Window is shown.
But that does not seem to be the case. When putting a breakpoint into the event handler for Window.onShown, the window is not yet visible. Unfortunately at this point, the macOS menu bar is not yet fully initialised, so all my changes to the menu bar would be overwritten later by JavaFX's default menu bar.
For now, I'm just using a delay of 1sec after the WindowEvent.WINDOW_SHOWN is sent, but that does not seem to be a good solution. So does anyone have a better idea on how to reliably determine when the window is actually visible or all initialisations have finished?
If you put a breakpoint in the onShown method the problem might just be that the window was created but you are blocking the visualization because of the debugger.
If this is not the case you could try to create a new Thread that only checks for the visibility of the window using the isShowing method of the class Window.
This should be faster than just waiting for one second after the onShown method was called.
I have an application that's not based on storyboards, but rather xib files. Main.xib contains the main application window. However, it's just a window. There's no NSWindowController. How can one be added?
Ok, figured it out. You simply add a new object to the scene, change its class to whichever NSWindowController subclass you want it to work with, attach the window to its output, then set an output to hold the window controller itself. I recommend on the app delegate.
I took things a step further by also changing the window to not show on launch, and I removed the window from the App Delegate (since it now has a reference to the window controller and thus the window indirectly already). This way I can center the window before actually showing it.
Only caveat to look out for is that you won't get the window-loading overrides since the window is handed to the VC, not loaded by it, so any code you need to run only when the window is set, simply override the window variable and add a didSet section. Works like a charm!
Still, I may try to dig deeper to see if I can update the Window controller to load the window normally so I can get those events as designed.
I have an air application. Clicking the application menu item opens a native window. Just like in other applications, I want that while the native window is open, access to other preferences in the application (like close application etc) should be disabled.
How can I do this?
I don't know of any easy way of doing this. The best I can think of is to listen for the DEACTIVATE event, prevent it, and then manually reactivate the window. Some code:
var args:NativeWindowInitOptions = new NativeWindowInitOptions();
var subWindow:NativeWindow = new NativeWindow(args);
subWindow.activate();
subWindow.addEventListener(Event.DEACTIVATE, onDeactivate);
private function onDeactivate(event:Event):void
{
event.preventDefault();
NativeWindow(event.target).activate();
}
This will ensure that this subWindow always retains focus until it is closed.
There are two differences that I can see between this method and typical application behavior for this type of subwindow.
1) The parent window can be dragged around (for some reason this does not dispatch a DEACTIVATE event)
2) Usually the subwindow should kind of "flicker" and plays an alert sound to indicate that it must be dealt with before further actions can be made (this is the the behavior for other applications on Windows 7 at least; I am not sure about other OS's).
For the dragging problem you should be able to have the parent window listen for the MOVING event and preventDefault() whenever the subwindow is active.
I don't see any good way of replication the behavior of 2. You can have the subwindow notifyUser(NotificationType.INFORMATIONAL) in the DEACTIVATE event but it's not the same thing that other applications do.
I have a desktop-like application which has 2 controllers: 'Desktop' which represents desktop icons and 'Taskbar' which represents the taskbar where you find buttons to minimize/restore windows already opened, like MS Windows is working.
The problem I currently have is the approach to "how should I display the window". Infact after doubleclicking the icon, I should create a window, and this could happen both on Desktop controller or on Taskbar controller (or maybe directly on the viewport, because they can be dragged anywhere). However, when I create a window, a new button should be created on the taskbar to minimize/restore it.
Because of this, I thought about handling window in the taskbar controller, however I don't know how to reach the Taskbar controller from the Desktop controller.
I have 3 ideas in my mind at the moment:
The Desktop controller directly adds the button to the TaskbarView, but in this way I'm feeling like violating MVC pattern. Also I need to specify TaskbarView in Desktop views.
The Desktop controller after icon doubleclick fires a custom event on the Taskbar controller. In this case the taskbar opens the windows and adds the button, this approach is quite linear but I don't know how to reference a controller from another controller (in this case, from Desktop to Taskbar)
The Ext.Application register for itemdblclick event on Desktop controller. When this event is fired, it redirects (or call a custom event) on Taskbar controller. After this everything keeps going like point 2. In this way I centralize the Routing functionality (like rails), however could also happen that Application object becomes really big. Also I'm using it as a "gigant controller" to route everything, but this is not really a big problem, thinking about rails it does something similar.
The application should not be split in 2 controllers (so Desktop and Taskbar should be one) and everything will be fine. I don't think this approach is correct.
So, my questions are:
Which approach should I use: 1,2,3,4 (or specify if there is something different)?
What a window should belongs to: Desktop controller, Taskbar controller, something else?
Thanks for any answer
I have a similar setup to you. Personally I would go with choice 2. There is a couple ways to deal with this. One is to have a parent that contains both the Desktop and task bar as its children and it can manage the communication between the two. You can create custom events which the parent listens for and directs them to the correct children.
So for example the parent creates both the task bar and desktop and it listen for icon click events on the desktop. When a click event on the icon occurs the parent receives the events and then internally determines what need to be done. In this case it knows that it needs to call the task bar and create the button for the opened window on it.
You could also look at using a a Mediator design pattern in JavaScript to register senders and listeners. So you could sent it up that the desktop is a sender of icon click events and the task bar is a listener of these events. The click on the icon will send an event to all the listeners of it set in the mediator. This way you don't need a parent to manage it. But personal I like the parent better.
I want to create a custom NSWindow that acts as a modal dialog. By custom I mean it has normal user controls in the window, with a "OK" and "Cancel" buttons. The dialog will contain read only information, and have a few checkboxes, secure edit fields, etc.
The MainMenu.xib file will have the normal Window visible at launch, plus include the custom NSWindow (which is NOT visible at launch).
I am trying to find example code to launch the window in modal mode (after the app initializes and launches main window), and on "OK" run a process, and on success of that process hide the dialog. Or on failure, keep the dialog up, but show an error sheet on the dialog.
Any help is appreciated, thanks.
You want to look at NSApplication’s -runModalForWindow: and/or -runModalSession: methods. Note that using modal windows is generally a bad idea and if it’s at all possible to avoid doing so, you should; that said, sometimes needs must.
As far as launching a process, waiting for it to finish and so on, you can probably do what you need with NSTask, although you don’t provide sufficient detail to be certain. You’d probably want to observe NSTaskDidTerminateNotification to tell you when the task had finished.
See
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/OperatingSystem/OperatingSystem.html
for more on NSTask and
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinPanel/Concepts/UsingModalWindows.html%23//apple_ref/doc/uid/20000223-CJBEADBA
for more about modal NSWindow usage.
Have a look at NSApplication's -runModalForWindow: method, and "Using Application-Modal Dialogs."