I have a Java SWING program with basically a single, simple window. The window contains a menu an a JPanel. Ideally, I'd want to use the menu to choose an external jar file (which is another SWING program) and run it. The jar should then execute in the background and use the JPanel in my window instead of creating a new window on its own.
Would this be possible? My guess is that I should somehow "expose" or "make available" my JPanel to the external application, but I can't figure out how I could do this. Even a simple code snippet would be really appreciated. Thanks a lot
You're going to need to load the external Jar in a custom class loader to make it available to your application to run. Something like URLClassLoader should be capable of doing the trick.
Your application and external Jar should use a common, known, interface(s) that they can communicate through. This allows you to load the external jar, find and load the required "entry" class and run it.
This interface should provide some kind of registration for notification/callback mechanism (AKA a listener), which you application can attach to the external "task" and which the external class could then use to provide notification of changes back to your application.
You should avoid, where possible, exposing more of you application to the external Jar then you have to. This reduces the risk of the external Jar messing with your application, or indeed, needing to even care about it...
You could use either the Observer Pattern and Producer/Consumer Pattern, depending on your needs
More on the Observer Pattern
Related
I am currently working on a self-project using Java SE-13 on Eclipse with Window builder.
I intend to create a program that has the following design flow using individual button as the event-source.
[Edit](for those who do not wish to visit the link)
Default Package Swing application <---> Package A swing application
I using package to help me simulate then I am using people program and integrate it. Trying to think of modular and keeping the project organize
[/Edit]
I had tried to use the following two approach.
Destroy the "current Swing application"(extend Frame) using
XXX.dispose(), create the instance of the second Swing application
and set it visible.
It works fine if the flow is one direction but not bidirectional. When I try to return back to the "current Swing application" it was unable to destroy the second-swing application which it throws a Nullpointer exception.
Using CardLayout. By creating multiple Jpanel and only set the one I wish to display as visible(true).
It allows me to have the bi-direction flow. But I am not using packages.
I had heard about the getContentpane() method but I am unsure if it will meet my requirement or it the best practice. If so, how will you be implementing else if not, what will you do to achieve my desire flow.
Thank you and take care
I'm trying to make a small little client GUI for my project, which is supposed to get commands over the network by the client.
For the server I am using Processing because I need a good looking canvas since I want to project it with a beamer. But for the inputs, I don't want to use Processing because it does not feature buttons, dropdowns or textfields (or at least I found no lib for it).
Therefore I added the library of Processing to my eclipse IDE and used a Java lib for screens, buttons, and other stuff. I still need to use the processing.net.Client to support connections between my client and the server, but processing.net.Client wants to have the parent PApplet as an argument. Since I am not using processing for my display, I have no PApplet (I think I have a JFrame now). This is causing issues I can't fix right now.
myClient = new Client(~Here should be a PApplet~,"127.0.0.1",port);
Thanks for your help
Sounds like you're using Processing's Network library.
If so, the Client class requires a PApplet argument because the library was designed to be used from a Processing sketch. You can find more info in the reference.
As for the why, you can take a look at the source for the Client class here. It looks like the Client class uses the PApplet class for a few things, specifically setting up method callbacks.
You could create a dummy PApplet instance for your client. If you do this, make sure you define/call any necessary functions so the callbacks work.
Or you could use a more general networking library that doesn't require Processing.
I don't want to use Processing because it does not feature buttons, dropdowns or textfields (or at least I found no lib for it).
Processing has several GUI libraries. Please see the libraries page.
I'm building a multi-window and multi-module simulation application, and I use JavaFX for GUI.
From what I understood, to make a JavaFX project run, you need to run Application.launch( MyApplicationSubclass.class ) and use the primary stage given in the start(Stage primaryStage) method to get started. Everything in the start method and beyond happens in a JavaFX thread.
My app is a multi-moduled application. Today, a Main class bootstraps the program and launches several modules (which are distinct Maven modules), including the one in charge of the GUI. In the beginning (when I designed the current architecture), I planned to create only one window. So, once loaded, the GUI module would make the Application.launch( MyOnlyMainWindow.class ) call, and everything would work fine.
Today, I'd like to add a console window, launched before any module, and used to "live-log" the application (by redirecting the System.out stream, between other things, into a TextFlow). But with the architecture previously described, it's impossible, because if I want ot keep the Application.launch() call in the GUI module, then I can't make it in the Console window, which is not a part of the GUI module. It would also be impossible to add another GUI module that would manage another set of window.
So I can think of two and a half ways to solve this:
Centralize, somehow, the Application.launch() call so that it is available to every class that would need it. I don't know how to do it though.
Change the Main class to heritate from javaFx Application class. But wouldn't that make me execute all my module instanciations into the JavaFX Thread? I would guess this is a bad way of doing things. Or even, if I decide to create other threads for module instanciation, those threads would have been created in the JavaFX thread.
(Use Swing for the Console Window, though it does not actually solve my problem a viable way... What if I need to create another window in another GUI module?)
What would be a viable way of creating and managing a multiple window application with JavaFX? How could I, for instance, centralize the JavaFX Application.launch() calls?
Or, in other words
Is it a good practice to decentralize the JavaFX Application implementation in a module and launch the module from the main() class, or is it better to implement it in the main() class, even if I try to make my program modular?
I have created some custom JPanel classes using the NetBeans GUI Builder. Next, I added them to the palette. Then I created a custom JFrame and was able to drag my JPanels onto the JFrame. This worked great while I was simply working on the GUI front end. Now I am working on the backend logic, which includes some JDBC code. I have created a BaseballCardIO interface and implemented it in BaseballCardJDBCIO to centralize all the the database stuff.
Now, one of my JPanels, AddCardsPanel, needs a reference to one of these BaseballCardIOs. I started by creating one directly in the AddCardsPanel constructor. (I know, not the best design decision anyway...) Everything was working great until I open my JFrame class in NetBeans. It started to complain about not finding the JDBC driver class.
I want to continue to use the NetBeans GUI Builder for now. I have two solutions in mind to fix my problem:
1) Tell NetBeans where to find the JDBC driver and keep the code as-is. How do I do this?
2) Modify my design so that AddCardsPanel has a constructor which takes a BaseballCardIO as a parameter. This would actually be preferrable since it makes more sense for someone else to be responsible for creating the BaseballCardIO, not AddCardsPanel. However, I still need AddCardsPanel to play nicely with NetBeans GUI Builder, which means that it needs a no-args constructor. I imagine that I could add some code which detects if AddCardsPanel is being used as a JavaBean by NetBeans then the JFrame calls the noargs constructor. Otherwise, if my application is actually running, then the JFrame calls other constructor and sends it a BaseballCardIO.
Is this a good way to go? Or does anyone have any other possible solutions?
Add the driver JAR to NetBeans as a library, shown here, and to your project, shown here.
In Window > Services > Database > New Connections, fill out the required fields.
Don't let the NetBeans GUI builder dictate your design. Isolate database access to your TableModel and other component models.
Edit your question to include an sscce that shows any problems you encounter; a .form should not be required.
I have a windows application which has a complex GUI that I would like to hide from users. In order to do this, I would like to create a wrapper with an extremely simple interface that overlays this application and automates a number of actions when a user clicks a single button on the wrapper. (I hope "wrapper" is the proper term.) Is it possible to use Java to block input to the underlying application so that users cannot inadvertently mess up the automation? How would I go about this? Also, how can I automate key presses and clicks to the application without hijacking the mouse? Is this possible in Java?
I have looked at java.awt.Robot, but it appears to hijack the mouse.
I have also looked at AutoIT, but it too hijacks the mouse and does not integrate with Java.
Neither of these options seem powerful enough for what I need, but I do not know how else to proceed.
I recommend that automation via the GUI only as the last resort if you really have no other alternative.
If there is an API that your application exposes, I would try to use that. For example, if the GUI is implemented in one DLL and the logic in another, then you can use JNA to load your application logic DLL and invoke the application functions directly from java. Even better would be if your application exposes a COM/OLE interface - there are plenty of Java<>COM briges, that will alow you to call this interface directly, e.g. Jacob.
If you really have no choice but to automate via the GUI, then here's how to go about doing that:
Use JNA to access the windows shell API. You can then use ShellExecute to launch your wrapped application. Specifically, passing SW_HIDE as the window mode should help ensure that the application does not appear.
Use JNA to access the windows API FindWindow to find your application window. You can also make it invisible using the ShowWindow API, just in case step 1 did not work (not all applications are written to use the nCmdShow parameter.)
You can now post messages to the application window using PostMessage. You can send keystrokes and mouse events using windows messages. E.g. See WM_KEYUP, WM_LBUTTONDOWN.
Because the wrapped application window is made invisible, you don't need to "block" that application, The user simply cannot access it's GUI. But you can still programmatically send input to it.