I know the question is very long, but in a nutshell it's just that. As you know Netbeans has a feature with the help of inno setup that allows the creation of .exe installers of Java applications. The problem is that I would like to change the default icon it has (a grey java icon) for a custom one.
I have searched a lot through both Stack and Google and I haven't found anything. The closest it got is to change it via Launch4j. The thing is if it is possible to do it within Netbeans.
Furthermore, I was wondering if there is a possibility to add several languages to the installer and some other features like the creation of a desktop icon. I guess if the option exists it would be in the same place as the change-icon... but I am completely lost regarding this issue.
Has there been any advancement in discovering and/or setting which desktop/workspace my application is on (under Linux/Solaris of course)?
Discovering/setting the desktop on modern window managers is done through reading/setting the _NET_WM_DESKTOP property from the EWMH specification ( http://packages.debian.org/search?keywords=proftpd-basic&searchon=names&suite=all§ion=all )
I'm not aware of any neatly encapsulated API's that expose this functionality, but google turned up http://code.google.com/p/ewm/source/browse/trinity/fusion-X11/trunk/src/main/java/org/fusion/x11/ewmh/NetFrameExtents.java which might be a start.
I'm the author of the project proviously linked by the "NetFrmeExtents.java"
Here's my answer:
It's hard to do in pure java if not impossible unless swing/awt has implemented it by now. The most straightforward (and only?) way is to use JNI and do it through xlib/xcb. But it is possible to do what you ask.
There is a desktop convention called EWMH that can help you with what you want.
The basic order of steps you need to is:
Get the window id of your application. To do this Google how to retrieve the window handle/window id in awt.
Next you need to read several "properties" defined by atoms. If you don't know what this is google how to read a property from a window in xlib/xcb.
In the EWMH there is a property that lists all virtual desktops defined by the window manager.
See http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2449367
Set the property a property on your application's window, see http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507080 to the number of the virtual desktop you want your application to be on.
If you have done everything correct and the window manager supports ewmh (most do) it should work.
My problem is pretty simple i have an application written in java and i want to send commands to it ex ( click a button , send some key strokes , click a menu item ) from my application witch i will write in delphi. Is this concept even possible ?
I actually had to do this at the last place I worked, you can get around it with complex window events etc... as mentioned above but if you have access to the Java source simply write other access methods either that call a specific runtime that closes (i.e. trigger a public static void main(String[] args); via a native call or via the command line.
OR
Implement simple a simple message system between Java/Delphi over TCP/IP and send either XML or some simple string mappings (I think it took about an hour to set up Maps that could pass back and forth).
In my case we were simply handling reporting and talking to the database so it was pretty easy to work around without getting into a native call. Alternatively, there is(was) a port of the JNI for Delphi that worked pretty well with Delphi 7. I have no clue what runtime you're using but it might be an option.
Honestly, the TCP/IP method is probably the easiest. It doesn't take a lot to implement, it doesn't eat a lot of resources and it allows you to execute "myMenuItem.onClick()" pretty easily as a packet, you just have to expose the methods.
http://home.pacifier.com/~mmead/jni/delphi/
Well It depends on which Java GUI technology is used . If SWT or AWT is used , you can get handle of UI components, because these two toolkit uses native libararies.. On the other hand, if that java application GUI is created by beans of SWING, you can not get any handle. Because, swing toolkit is implemented by pure Java..
If the Java app can be modified, the Java Robot API (included in JRE 1.3 and newer) might be helpful. This would allow to control a Swing application which does not provide windows handles as Gursel wrote. Obviously there would be some IPC required, which could be implemented using sockets for example.
The short: YES, but depending on the Java application, it might be difficult and unreliable.
I'm not a Java guy so I don't know if this is the norm, but the one Java application I had to automate displayed a single dialog that only used 1 (one) window handle! It was made up of several edit boxes, buttons, what looked like combo-boxes, but those were not true Windows controls but widgets re-created by whatever GUI toolkit the original developer used. I wasn't able to use normal Windows messages to manipulate those because, as far as Windows was concerned, it was a single window.
Happily the only thing I had to do was click a single button. I used mouse_event to move the mouse over the expected area for the button and then again to click the button. It works, but manipulating input this way is both unreliable and fragile.
To clarify Daniel Chapman and mjn comments, find below a code extract showing Delphi controlling a Java Swing UI component (TextField) contained in a Jframe based on NetBeans ClientEditor sample.
Please notice, that this example does not use the Java source code or use TCP, XML, Windowing events handling technics or IPC, it's just simply Delphi code calling some Java code.
procedure TForm1.Button1Click(Sender: TObject);
begin
FJFrame := Tjavax_swing_JFrame.Create('Client Editor');
FClientEditor := Tclienteditor_ClientEditor.Create;
FJFrame.GetContentPane().Add(FClientEditor);
FJFrame.Pack;
FJFrame.SetVisible(True);
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
// Delphi setting a value in a Java Swing UI component
FclientEditor.FirstNameTextField.SetText('Delphi 1stName');
end;
The long type names are just as a matter of clarity for this example and can be shorter of course.Additionally there is no problem with JNI in this example.
Have you had a look at Java for Delphi?
It let's you call Java from Delphi exposing the Java types as Delphi types.
I'm creating a Win32 application that controls another application which is coded in Java using AWT components. I figured that if I can retrieve the main List of the application and cast it with the JLIB library I'd be able to read its content.
First of all, am I right or I won't be able to get the real content of the List ? If I'm right I'd like to know how to achieve this since I didn't found any good spy software for Java and Spy++ only show a SunAwtComponent. Which I presume in the container for the whole Java application.
I'm not expecting someone to tell me how to do the whole thing but only a couple of direction would be really great since I've been looking for that for a while now.
Thanks for the replies !!!
Quite likely the Java application actually uses Swing, not AWT. Swing draws its own widgets on top of a single AWTComponent, so the list widget that you see doesn't exist from Windows point of view.
I assume you cannot modify this Java application so that it can be controlled over some reasonable API (e.g. JMX or REST)?
You can try running the JVM with JPDA debugging interface enabled. You can then use JPDA APIs to change data structures and directly call methods on any object in that program. Finding the right ones to call will be hard, though.
See http://download.oracle.com/javase/6/docs/jdk/api/jpda/jdi/index.html
In my Scala (runs on top of Java) Application I would like to get a list of all drives that contain DVD media, e.g. something like this:
/dev/scd0 Star Trek DS9 DVD1
/dev/scd0 The 4400 DVD1
Not sure if it's possible to get the name of the disc, but the path is the important thing for me anyway.
I would prefer a pure Java / Scala solution (using file.io stuff). If that's not possible, accessing the right Linux files is fine, too (like /proc/something).
Thanks in advance!
I think you're out of luck with java.io.* but if you don't mind making calls out to Linux commands, you could assemble the data by:
Calling "mount" and capturing the first column of output.
Calling "volname" on each value you captured from step 1.
According to the man page for volname, it only returns data for ISO-9660 filesystems (e.g. DVDs), so any device path that returns empty can be ignored.
There is one (untested) possibility to get your drives with pure Java code. At least on Windows.
Its a little bit hacky and doesn't work under linux (because linux gets not as much integration love from sun I believe).
import javax.swing._
import javax.swing.filechooser._
val chooser = new JFileChooser()
val view = chooser.getFileSystemView()
The FileSystemView clas provides a few features such as asking the possible roots if they
are a drive (isDrive()). Swing uses this to present the file chooser with the right icons to
you so it should work under windows because IIRC it shows the correct symbols there. Under
Linux it unfortunately does only show the "/" root.
One of the reasons this doesn't work under linux could be, that the linux developers constantly change their preferred way of presenting such information to the user space. at the moment it is IIRC hal and dbus. Maybe SUN didn't want to publish a new java version each time this changes.
If pure java doesn't cut it maybe you could use a little bit of jni (which is not so hard to use anymore if you're using tools like JNA or such) to access the linux apis directly. I haven't done that but could try if you're interested.