I want to set FileChooser dialog preferred size. For now, it cannot be set and just appears with fixed size always (occupied with almost full screen). I can't find resizing method in FileChooser intance and even control dialog after it appears.
I don't think that this is possible. The documentation of FileChooser states
Provides support for standard platform file dialogs. (...) The configuration of the displayed dialog is controlled by the values of the FileChooser properties set before the corresponding show*Dialog method is called. This configuration includes the dialog's title, the initial directory displayed in the dialog and the extension filter(s) for the listed files.
The popup dialog is provided by your operating system, so it cannot be customized directly. Your only option is using the bit of API that the FileChooser class itself provides. Since JavaFX is a cross platform UI framework, the customization options probably have been limited to the ones that are supported natively by all major platforms.
If you absolutely must customize the file chooser, you can try to embed a Swing JFileChooser in your JavaFX app.
As noted here, the JavaFX FileChooser is provided by the host platform. In particular, "For configuration properties which values haven't been set explicitly, the displayed dialog uses their platform default values." Presumably, this includes size.
On macOS, Java/FX 17 LTS, if you resize the dialog, the new dialog size is saved as a preference; when invoked again, the last used dialog size is restored.
Please feel free to add your user experience on other platforms. This FileChooserDemo can be used for testing.
Related
Is it possible to manage the list of a given widget's actions directly in Designer and/or Creator's UI Editor? Creator 4.14.0, Windows.
By "widget's actions" I mean the ones set with e.g. QWidget::addAction.
Right now I just set up any action lists explicitly in the window's constructor, but it would be nice if I could just manage the list in the GUI. I poked around in the UI editor's various context menus and in the Action Editor pane, but didn't see anything. I couldn't find anything in the Properties pane either.
I am attempting to implement the Daydream keyboard into an app built in Unity and am not able to get this to work. I have added the keyboard prefab as a sibling of the main camera and added two input fields with the onpointerclick function added as instructed. I however get a null reference exception and assume this is due to the daydream keyboard delegate field being blank. The example scene in the SDK shows the daydream delegate example prefab but I am unsure how to implement this for two input fields. Also does the keyboard render in the Unity editor or must it be built and run on a phone?
This is an old question and has probably already been answered, but I figured I'd publicize my answer anyway.
For those reading, if you haven't checked out the Keyboard Demo scene that can be found within the Demos folder of the Google VR Unity package, I would highly recommend doing so. Following this object hierarchy has worked for me in the past.
To answer your first question, it seems that they have included a KeyboardDelegateExample object within the scene's hierarchy, and then used this object as the Keyboard Delegate in the GVRKeyboardManager.
They manage to fake an Input Field by creating a background and overlaying a Text object on top. If this method does not suffice and using an Input Field is crucial in your particular case, then drop your Input Fields into two separate GVRKeyboardCanvas objects.
Clicking on either canvas will activate the GVR Keyboard. You may have to add a small script to manage the transitioning of the input field.
Lastly, no the GVR Keyboard does not render in the Unity Editor, it only appears while running a build. Hopefully this will be addressed in later releases. There are also Keyboard plugins that you may find useful on the Asset Store.
I'm making a JavaFX program for which I would like to use the new Time API. I wanted to use the LocalDatePicker provided in the JFXtras library which would allow users to select multiple localdate objects and would streamline the program's handling of selected objects (as opposed to the similar CalendarPicker in the same library which uses the older date API).
I imported the custom JFXtras controls into JavaFX scene builder, and while the "multiple" selection mode works very well for the JFXtras CalendarPicker control, the same functionality seems broken in the LocalDatePicker control.
Multiple/Range selection does not work in either the preview feature of scene builder, in a compiled FXML/controller file generated in Netbeans, and when simply added to a JavaFX scene, while in all those cases the CalendarPicker control does work. which leads me to believe it is a problem with the control itself and not my implementation. I checked the respective classes in the library and the code handling modeProperty seems identical.
Thing is, the sample program including all controls on the JFXtras page (http://jfxtras.org/resources/java/jfxtras-labs-samples-8.0-r4-SNAPSHOT-shadow.jar) has a multiple selection working for the LocalDatePicker control.
What am I doing wrong?
Sorry if it's an easy fix, I'm pretty new to Java (and JavaFX)
Thanks
Oh yes. This was my fault. Even though there was code to sync the mode value between LocalDatePicker and CalendarPicker, I forgot to set the initial value. In the tests the value is set after the control is visible and then the sync code kicks in. Please try 8.0-r4-SNAPSHOT. Thanks for reporting.
I am working on a document-based OSX application, with master-detail style windows. I understand how to open additional windows, to display additional information, by using -makeWindowControllers and adding extra window controllers, but I can't set the title of the new windows. I have tried using -setTitle and -windowTitleForDocumentDisplayName in both Document.m and in my sub-classed window controller class, but I can't get the window title to change.
How do I change the title of non-main-windows, which have a sub-classed window controller, in an NSDocument based application?
EDIT: I know there are some suggestions on SO about using an IBOutlet to the window to do this, but surely the window controller has a reference to its window anyway, right?
I have an AIR application with a system tray icon. When clicked it shows and activates the app. This is working as expected when the app is hidden (docked), however if I select another application so my app is in the background clicking on the system tray icon does nothing.
Oddly I also have a contextual menu on the system tray icon, which has an option to restore, this calls the same event handler as ScreenMouseEvent.CLICK, yet works.
I expect it's something to do with the contextual menu changing the focus, perhaps it's a bug in how AIR works with the system tray, perhaps it's just something I'm missing. Would be good to know if that's the case.
Thanks in advance
Rob
//instead of just calling
activate();
//call
nativeApplication.activate()
//or even better
nativeApplication.activate(nativeWindow);
Update based on OP's input: if you have multiple windows open for the application, use:
nativeApplication.activate(nativeApplication.openedWindows[0]);
If you are not in the main WindowedApplication class, you can use the static property NativeApplication.nativeApplication to get a reference to the singleton object.
WindowedApplication.activate()
Activates the underlying NativeWindow (even if this application is not the active one).
NativeApplication.activate(window:NativeWindow = null)
Activates this application. If the operating system allows activation, then the specified window is activated and brought to the desktop foreground; that is, in front of the windows of other applications. (If the window parameter is null, then a visible window of this application is activated.)
livedocs is not clear on why this is happening. It says activate() activates the underlying native window - one would expect it to be brought to the front when it is activated, but that's not happening.