In a Java application (JRE 1.7.0_21) on Windows XP, I call a native method:
public native String getImage(...);
...which is in a Visual C++ 10.0 dll. This displays a modal dialog box. Before displaying the dialog box I am properly setting the dialog box's parent handle to be java application window on top of which this dialog box will popup.
Problem is my application crashes as soon as the call to DoModal() in this function. If I leave the handle to parent window to be null then the dialog box coming fine with no crash. Only when setting handle to parent window to java application its crashing.
Please let me know if I am missing something in dll part/jni.
You normally can't use "MFC extension DLL" in a non MFC executable.
Read Extension DLLs, especially:
The client executable must be an MFC application compiled with _AFXDLL
defined.
and
Only MFC executables (either applications or regular DLLs) that are
built with the shared version of MFC can use an extension DLL.
Set up a new project, choosing "Regular DLL" for the MFC DLL type.
Related
I'm actually working on an screenshot saver on Windows, and i'd like to call to a method on the java application when I press a combination of keys to save the screen.
How can I call a method when the java application is not the "active" window? whether the main window is minimized or is running on background.
You're looking for a Hook in your keyboard for Windows. Note that hooking is highly relevant to the OS and your application may not be portable between different versions/editions of the OS. Still, you can do this using JNA as shown here: JNA Keyboard Hook in Windows or using a third party library like jnativehook.
In the control panel under Java, there is an Advanced option to Show console... With this enabled, an additional window launches when my app launches. The window is titled Java Console - MyApp Name.
Is there a way to launch this console window programmatically? Rather than require the user to enable this feature, I would like to make the window available on request from the application.
Is the console a feature of Java WebStart? I do not see an API call for the console in the webstart API. If I look elsewhere, I just see many references to the System console object which has nothing to do with the console window.
No, there is no such default 'application console' attached to JWS apps.
I have a Mac Java app bundle that has problems opening an OpenGL window from a SWT dialog in a single process. It just doesn't work.
To solve this problem I would like to open a SWT dialog in one instance of the Java app and then have it launch another instance of itself with a parameter saying "this time open the OpenGL window". The part I don't know how to do is finding out what "itself" is on a Mac.
How can I do that?
You might be able to adapt this Swing based Launcher that uses
exec() to run programs in a separate JVM. If you need to include your own dynamic libraries, you might be able to use one of the relative path symbols described in man dyld under the heading Dynamic Library Loading.
I have a SWT app that opens a OpenGL window (using the LWJGL library) after a button is pressed. It is supposed to close it's main SWT window and open a new one with an OpenGL context. Works fine on Windows. On Mac, I get this error:
2010-03-05 02:28:25.315 java[1315:a07] [Java CocoaComponent compatibility mode]: Enabled
2010-03-05 02:28:25.316 java[1315:a07] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.100000
2010-03-05 02:28:25.317 java[1315:a07] Apple AWT Startup Exception : _createMenuRef called with existing principal MenuRef already associated with menu
2010-03-05 02:28:25.318 java[1315:a07] Apple AWT Restarting Native Event Thread
The SWT window closes and then the app hangs, with no windows open.
It looks like the SWT app doesn't shut down cleanly and leaves it's menu entries associated with it, which prevents the LWJGL window from opening. Mac OS X only wants one application menu. SWT doesn't free it's own menu and LWJGL wants to add another.
Facts:
A button in the SWT dialog is supposed to close the dialog and open a LWJGL window (org.lwjgl.opengl.Display).
The button sets a static variable in the app to tell it what to do next after the SWT window is closed, so the LWJGL window is NOT being opened from a SWT callback directly.
The button then closes the SWT window. I don't know the correct way of doing this but tried various combinations of shell.close, shell.dispose, display.close and display.dispose, none of them worked. They all close the window but the error occurs every time.
Does anyone know what could be done to make this work?
UPDATE: This simply does not work and it seems that Apple will not fix it, ever. The only way around it is to launch a new app instance and pass it a parameter that tells it to open the second window.
UPDATE 2: In this particular case, I solved the problem by using the SWT dialog for the Windows version of the app and for the Mac version, I wrote a native Cocoa dialog which invokes the JVM and runs the LWJGL app when needed. That works pretty well.
It would appear to me that the problem is not SWT creating a new window or LWJGL actually doing so. I believe the problem lies in the fact that under Mac, the application menu must be registered to the process, and for some reason or another, there is a conflict of interest between the two.
You might have some better luck juggling things around a little:
What happens when you create a LWJGL window first, then create a SWT shell?
What happens when you initialize LWJGL statically before creating a SWT shell, then proceed to create the shell and create an LWJGL window?
Incidentally, to close a SWT window, all you need to do is dispose of the Shell:
shell.dispose();
I have an applet that displays a dialog box on click of a button. When the dialog box is first displayed, it is shown using the native look-and-feel of the OS. When the dialog box is displayed a second time (same page, browser, OS, etc.), it is shown using what I think is the Swing look-and-feel. To my knowledege, I do not explicity set the look-and-feel of my applet. Should I be doing so to avoid this inconsistent behavior?
Please elaborate what you mean by "display". A different screen on the same computer? A different computer? Is the same version of Java installed? Is the exact same version of the OS installed?
The user can influence the L&F with environment variables. These docs may help.
Also, for the native Windows XP L&F, you need a special DLL.