I'm trying to migrate a program from java 8 to java 9.
In my program I found the following code.
//Run JavaFX Application Thread/Toolkit
PlatformImpl.startup(() -> {
});
It tries to start the JavaFX Toolkit
Unfortunately, the PlatformImpl.startup is no longer supported in java 9.
Which substitute is there for it?
How can I start the JavaFX Toolkit?
Thank you
The startup() method is one of the methods that was promoted from the non-public class PlatformImpl to the public API Platform class in the Java 9 release. It is now fully documented in the API documentation.
Thus the equivalent call in Java 9 is
Platform.startup(() -> { });
Note that the use cases for this method are fairly rare, and the API docs go to some lengths to emphasize this:
In general it is not necessary to explicitly call this method, since it is invoked as a consequence of how most JavaFX applications are built.
...
As noted, it is normally the case that the JavaFX Application Thread is started automatically. It is important that this method only be called when the JavaFX runtime has not yet been initialized. Situations where the JavaFX runtime is started automatically include:
For standard JavaFX applications that extend Application, and use either the Java launcher or one of the launch methods in the Application class to launch the application, the FX runtime is initialized automatically by the launcher before the Application class is loaded.
For Swing applications that use JFXPanel to display FX content, the FX runtime is initialized when the first JFXPanel instance is constructed.
For SWT application that use FXCanvas to display FX content, the FX runtime is initialized when the first FXCanvas instance is constructed.
When an application does not follow any of these common approaches, then it becomes the responsibility of the developer to manually start the JavaFX runtime by calling this startup method.
Calling this method when the JavaFX runtime is already running will result in an IllegalStateException being thrown - it is only valid to request that the JavaFX runtime be started once.
So, while you are in the process of making the changes you need to update your application to be Java 9 compatible, you might want to carefully consider if you need to call startup() at all; maybe there is a more standard and robust approach to starting your JavaFX application anyway.
Related
I got error when execute code. I think it's not related to code. something is missing.
java.lang.IllegalStateException: Problem in some module which uses Window System: Window System API is required to be called from AWT thread only, see http://core.netbeans.org/proposals/threading/
You have flagged your post with JavaFX, so I assume you are talking about a JavaFX application. Every GUI update in the JavaFX-world is done on the JavaFX application thread. Your exception however indicates that you are using some AWT code in your program which has a different requirement. It must be run on AWT thread. So, the first thing you have to do is find out what this code is and then you have to make sure to call it on the right thread. You can use Platform.runLater() to put something on the JavaFX thread and SwingUtilities.invokeLater() to put something on the AWT thread.
I find a way to catch an event/message which notify the "application loaded" event, to be able to close a splashscreen. Maybe Poco implements it directly but i haven't found any clue in the Application class documentation or code.
Have you tried to use the application member function bool initialized()?
I'm using the Mitk framework, and i will have to modify some code there ; the used CommonTk framework can manage a callback dedicated for splashscreen closing. Thus, there is no event published by Poco to allow this feature.
i using POCO Thread for splash screen (where i can catch / handle status of thread). My application is programmed in WinAPI (Win32, VS C++ 2008 EE), so i using WinAPI timmers; the main message pump is also in separated thread...
Here is my WinApi32 example full code & VS90 project: WLEZLEY_SPLASH_POCO_EXAMPLE.ZIP
PS: It works since version 1.4.5 of POCO, but also works with POCO v1.7.2 (actual version is included). You can try study my code and you try it yourself.
I’m moving from Swing to JavaFX2.0. I have an internal service with various JFrame windows to display/alter internal parameters. I have a menu with buttons. Each button kicks off one of the JFrame windows as such:
new ASvr().setVisible(true);
Works fine. Now going to JavaFX2.0: Each “window” is an independent FXML application. The independent FXML applications run as standalone applications when the service is remote using RPC to communicate with the service. This is the internal version where the “windows” are part of the same JVM.
The Menu starts with application.launch(). There can only be one launch() in the JVM so I can’t use launch() for the independent FXML applications. After much trial and error (mostly error) what I’ve come up with is:
new ASvr().start(new Stage());
Works fine, I think. Since I’m new to JavaFX I could be missing something which will ruin this solution. Calling start() myself, not from a launch(), may have nasty side effects. I can’t use a new ProcessBuilder and put each application inside a new JVM since I need direct access to references within the internal service.
My questions: Is there a preferred way to have several independent (need to run as standalone without alteration) FXML application scenes running within a JVM? Do you see any potential problems with what I did?
I would not recommend calling start(...) yourself. The launch(...) method does a lot of complex housekeeping, such as starting the FX toolkit and the FX Application Thread, instantiating the application class, and then invoking start(...) on the FX Application thread.
You should basically think of start(...) as the equivalent of the main(...) method for a JavaFX application, and the Application subclass as the "main-class", not the JFrame subclass. (Indeed, in Java 8, if your class is a subclass of Application it can be launched directly by the JVM without even having a main(...) method.)
Once you have created your single start(...) method (again, just think of it as the replacement for your single main(...) entry point from a "regular" Java application), then you can show the contents of an FXML file with the idiom
Stage stage = new Stage();
stage.setScene(new Scene(FXMLLoader.load(fxmlResource));
stage.show();
(Of course, there are variations on this, especially if you need access to the controller, but you get the idea.)
You could if you wanted create subclasses of Stage, in the old swing style of creating JFrame subclasses, and let the constructor of the Stage subclass load its FXML and set its own scene. Then you could use essentially the same idiom as you used in Swing:
new MyStageSubclass().show();
Notice again how the analogue of a JFrame subclass is a Stage subclass, not an Application subclass.
I am writing a Qt application that calls QProcess::startDetached("wscript.exe script.vbs") to show the delete confirmation dialog in Windows.
this is the script:
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace("-")
Set objFolderItem = objFolder.ParseName("-")
objFolderItem.InvokeVerb("Delete")
the arguments for Namespace and ParseName are from the arguments passed to the script.
This may be inefficient because it opens an external application first before running the script. I was wondering if i can run VBScripts in a Qt application.
If not, what alternatives can i do?
My VBScript is very weak, so I'm not 100% sure I understand what you are trying to do. My assumption is that you are trying to delete a folder, but want to give the user the normal confirmation box and animation while the action is occurring. If that is not correct, please let me know and I will remove this answer.
A few ideas:
You could call the Windows API directory within your C++ code to do this. I believe the correct call would be to use IFileOperation (Vista and later) or SHFileOperation (pre-Vista)
Qt already has message box dialogs. Although you might not get the exact same functionality as the native shell, you could use this (QMessageBox::warning) and then delete the folder using QDir. This would also be cross-platform portable.
If you stick with the VBScript, I doubt you would see any performance issues unless this is being called many, many times in a loop or something. You know, the old "premature optimization is the root of all evil" thing.
You should read up on the IActiveScript COM interface. You can create an instance of an interpreter that implements IActiveScript to provide a runtime for evaluating scripts. VBScript and JScript can both be used for this and a number of other third-party scripting languages also provide IActiveScript support.
The overview for working with this is you create a language runtime (an instance of VBScript for instance) then add some custom objects to it. Typically if you are embedding an interpreter into your application then exposing an Application object is a good place to start. This can be just an IDispatch interface or something more concrete with an IDL generated typelibrary and all the trimmings. Once you have added the necessary named items into the runtime you load one or more scripts. Any public functions or subroutines declared in the scripts now get exposed via the IDispatch interface of the live runtime once you switch its state to active or running. To actually run the script program, I invoke the Main function for my stuff - you could choose some other scheme as applicable to your environment.
The nice thing about ActiveScripting, is to change language you just change the runtime CLSID. So if people prefer Perl they can use PerlScript or PythonScript etc. Your Application object remains the same hence you don't have to write additional code to support the new languages. The only requirement is that everything is COM.
we are developing an Adobe AIR app using Flex4. We are facing lot of bugs that didn't show up when we run the application inside Flash Builder (both debug mode and run mode), but when we install the app and run it, the app shows a different behaviour. Any idea ? what does it change between running the installed application in the builder and outside ?
Thanks a lot
Ok i've founded the problem using MonsterDebugger in the application running stand alone. The problem was the File.browseForDirectory(). I'm creating the File object, registering the event listener and then calling File.browseForDirectory() and that generate an exception. I switched the order, First creating a new file, then calling File.browseForDirectory() and at last register an event handler and works great.
My guess is that inside the debugger version and inside Flash Builder it takes just few more millisec and the File object is ready when i register the eventlistener but in the stand alone application AS3 code for event listener registration is executed before the File object initialization.