I have a Carbon LSUIElement application, which runs in the background (possibly with an icon in the menubar, depending on a pref) and occasionally needs to show a dialog to the user - sometimes in response to a user event, but sometimes in response to a background task failing or similar.
(I'm using Qt 4.5, so the application is Carbon based; With Qt 4.6 things will be Cocoa based, but it sounds as if the problem may exist there too).
The problem is that when I open a window, and show it, it doesn't get brought to the front. I assume this is an artefect of being an LSUIElement app. Qt uses SelectWindow in Carbon, and [makeKeyAndOrderFront] in Cocoa, to bring a window (and the app) to the front.
To work around the problem, I tried going direct to the window server: (the first few steps are to get the WindowID, this will be simpler with Qt-Cocoa, since I can use NSWindow:nativeWindow)
WindowRef ref = HIViewGetWindow((HIViewRef) aWidget->winId());
CGSWindow wid = GetNativeWindowFromWindowRef(ref);
CGSConnection cid =_CGSDefaultConnection();
CGSOrderWindow(cid, wid, 1 /* above everything */, 0 /* NULL */);
This works, sort of - the window comes to the front, but it's not highlighted or keyboard focused. Are there additional steps to fix those issues, or is there a simpler solution to the whole problem?
Use SetFrontProcessWithOptions to bring your window in front of other apps.
Try:
[NSApp activateIgnoringOtherApps: YES]
Related
I want to open all component-dialogs in a new windows or tabs. Is that possible and if yes, how can I do this?
I was thinking of modifying the edit handler of the component. How and where would I do this?
TL;DR:
Depending on what you want to do, it might not make sense, but, you could start here:
info.magnolia.ui.contentapp.detail.action.EditItemActionDefinition
info.magnolia.ui.dialog.formdialog.FormDialogPresenterImpl
maybe even https://www.magnolia-cms.com/blogs/boris-kraft/detail~&headless-or-full-bodied-cms--magnolia-provides-all-the-solutions~.html
Longer answer:
It depends on what you are trying to do - we can get to any state in Magnolia by re-using location fragments like this one: #app:contacts:detail;/ldavinci:edit
That tells me we are in edit mode on a particular path (from root of some workspace) in the detail subapp of the contacts app. What that means in this case is, we've opened a dialog in a tab.
Likewise: #app:contacts:browser;/ldavinci:treeview: represents another state.
So we can programmatically move to new locations if we know the parts of those location fragments. But these are locations (app,subapp,path) within Magnolia, not within a web browser.
A browser tab is not the same thing as a Magnolia tab; the latter represents a tab within a Magnolia form, and hasn't anything to do with a web browser - so it would not open.
Even if we did hijack that action, what you'll get in this case is the whole Magnolia rig, not just the dialog, standalone, in a new browser tab or window, which is not what I suspect you are interested in. If you are interested in the dialog, by itself, independent of the rest of the Magnolia UI, you might have to start looking at
info.magnolia.ui.dialog.formdialog.FormDialogPresenterImpl
146 public DialogView start(..
which calls
165 private void buildView(..
and sets up overlays, etc.
(sepcifically through 167 formPresenter.presentView(..)
...
so then if we look in here:
info.magnolia.ui.dialog.formdialog.FormPresenterImpl:
123 buildForm((FormView) this.formView, formDefinition, item, parent, activeLocale);
which eventually calls this guy
198 private void buildReducedForm(..
and it adds it to existing FormViewReduced (info.magnolia.ui.vaadin.form.FormViewReduced) with a certain modality.
FVR is implemented by
info.magnolia.ui.vaadin.form.Form
which is what should actually display the form.
and the form gets displayed on a
info.magnolia.ui.vaadin.tabsheet.MagnoliaTabSheet
So in info.magnolia.ui.vaadin.gwt.client.tabsheet.widget.MagnoliaTabSheetViewImpl:
...etc. and further on down the rabbit hole, and what would this stuff mean outside the context of Magnolia anyway?
I guess you could also look here:
info.magnolia.ui.contentapp.detail.action.EditItemActionDefinition
You can edit these data over our REST API anyway, so maybe you're trying to move the dialogs out of Magnolia to accomplish something along that line?
I have a problem.
My app is a tab bar controller and its first view controller is a split view controller.
This seems to be not ok for Apple because documents say a split voew controller must be the root, so perhaps that is the reason of my problems.
The problem is that sometimes, willHideViewController from UISplitViewControllerDelegate is not called, so, for this reason, the upper/left button sometimes is not created, which is anoying.
I realised, to reproduce this error, try several times this:
-Landscape mode.
-Select a tab different to split view controller tap.
-Move the iPad to portrait in that tab.
-Go to the split view controller tab, and sometimes, willHideViewController is not called so you will not see the upper button. However if I rotate my iPad to landscape and after that to portrait, it's fixed.
I tried to force manually several rotations to work around this problem, but no luck.
I still have to try any split view controller clone class from github or similar.
Do you have idea what's going on or any work around?
Here I show you two examples working properly.
Thanks a lot for your help.
Where do you set the splitViewControllers delegate? Perhaps you can set the delegate when you load the tab. It sounds like you set it only when you have rotated once?
Otherwise, see this example
Here they have the TableViewController be the delegate of the splitviewcontroller. Perhaps you could do the same with the TabBarController?
I've concluded that this can't be done in any way that I consider 'sufficiently' legitimate. It's possible to get frustratingly close, but the issue of having the willShow..., willHide disseminated to the split view controllers under each tab remains.
The solution that seems most likely to work is,
https://github.com/grgcombs/IntelligentSplitViewController/blob/master/IntelligentSplitViewController.m
Though this code is undoubtedly clever, it's a bit too 'side door' for me. I suspect (but don't know) that just invoking the delegate methods is not sufficient. Surely the UISplitViewController itself needs to change it's internal state as well as calling the delegate methods? This method 'just' invokes the delegate methods when there's an orientation change.
So... I've decided on a more legitimate solution, which is to use the new method introduced in iOS 5.
- (BOOL) splitViewController:(UISplitViewController *)svc
shouldHideViewController:(UIViewController *)vc
inOrientation:(UIInterfaceOrientation)orientation
{
return NO;
}
So, the master menu is never hidden, and therefore the problem of managing the popover doesn't arise.
Of course, this is still not totally 'legit' as it still includes UISplitViewControllers that are not at the top level (the UITabViewController is at the top level, and the split views are on each tab)
Good luck with whichever solution you choose.
I'll update this reply when I've confirmed Apple will approve an app using this solution.
I'm working to a BB application, using standard UI controls (Edits, Buttons, etc) - you can navigate through these controls using the trackball.
In a certain point I must open a BrowserField with an URL.
When I leave the BrowserField (and come back to the "standard UI controls" part, the pointer of BrowserField is still present on the screen, and the trackball cannot be used. From that point, I cannot use the application anymore.
I'm creating the OS 6 browser using following code:
final BrowserFieldConfig browserConfig = new BrowserFieldConfig();
browserConfig.setProperty(BrowserFieldConfig.JAVASCRIPT_ENABLED, Boolean.TRUE);
browserConfig.setProperty(BrowserFieldConfig.ENABLE_COOKIES,Boolean.TRUE);
browserConfig.setProperty(BrowserFieldConfig.ALLOW_CS_XHR, Boolean.TRUE);
browserConfig.setProperty(BrowserFieldConfig.NAVIGATION_MODE,
BrowserFieldConfig.NAVIGATION_MODE_POINTER);
on exit, I don't have a specific code. I've tried with BrowserFieldConfig and NAVIGATION_MODE, to set back the default navigation mode, but it doesn't have any effect.
browserConfig = mWeb.getConfig();
browserConfig.setProperty(BrowserFieldConfig.NAVIGATION_MODE,
BrowserFieldConfig.NAVIGATION_MODE_NODE);
[OS 6.0, BrowserField]
Tested with 9700, 9800 emulators, and to a 9900 real device.
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?
I have a flex 3 application that creates an Image from a canvas which the user draws on. I use the ImageSnapshot class to create the image
var imageSnap:ImageSnapshot=ImageSnapshot.captureImage(myCanvas);
var imageByteArray:ByteArray=imageSnap.data as ByteArray;
I want the user to be able to print or save the image. I can use the following code to print the image but flex does not provide good control over printing across multiple pages
var printJob:FlexPrintJob=new FlexPrintJob();
printJob.start();
printJob.addObject(myCanvas, FlexPrintJobScaleType.SHOW_ALL);
I would like to display the image in a browser window so that the user could print it using the built in browser functionality or right click on the image and save it. Can this be done without requesting server side code to do it?
I know that flash player 10 and flex 4 allow you to save files locally but for now I am stuck with player 9 and flex 3
You can still use the new features of FileReference (the save() and load() methods) in Flex 3 as long as the application is running in Flash Player 10. But if you are definitely stuck with Flash Player 9 then you will need to push the image up to the server first. If you are looking for a good way to push that data up to the server, please reference my solution in this question:
Flex: Render an unrealized UIComponent to BitmapData?
I don't believe you can do this, as it would violate the sandbox. For example, if this worked, it means you could put arbitrary code (analogous to an image) on the user's machine without their consent or knowledge.
I'm not sure if this will work, but try this:
Show a link to the image (file://path/to/image/img.ext) and set window.htmlLoader.navigateInSystemBrowser = true;