I want to be able to call windows api shutdownBlockReasonCreate from my Java code. I know it's a complicated process involving JNI call to a custom c++ code that generates a dll. But I was able to get there eventually. However I have a problem with obtaining a HWND from my shell window (I use SWT) as it's one of the key parameters to shutdownBlockReasonCreate and shutdownBlockReasonDestroy functions. Without it I couldn't get these functions to work.
A particular implementation online https://github.com/seraphy/JavaGracefulShutdownForWin7 seems to provide the capabilities required and a demo in how this can be done. Unfortunately this was done with JFrame (using JAWT.lib) whereas my application window was written in Eclipse SWT / JFace. I'm not sure if Eclipse has anything equivalent.
I tried many different approaches such as using FindWindow function and ::FindWindowEx, as well as passing in Shell.handle to the native methods. None of them worked for me as neither of them returns meaningful HWND value but '0'.
Since I'm not using JFrame, I cannot get HWND from JFrame like "seraphy" did. And certainly there's no way we can convert SWT Shell to a JFrame so I can reuse some of its code.
I also don't think JNA would help much in here either given my Google research over the last couple of days. I can see it was able to obtain a handle to a console window (How to return HWND in JAVA) but are we able to call shutdownBlockReasonCreate methods directly from JNA? Nothing online I found so far seemed to suggest that. In which case we still have to use JNI instead.
I'm very new to c++ so I'm a little bit struggled in getting this to work. Anyone who can shed some light or point me to the right direction would be very much appreciated!
Related
Previously in my game engine written in java, I have used lwjgl 2.9.3. I ran into an issue. I wanted lwjgl to run on another graphics card. So I researched and soon figured out, that it would be impossible using lwjgl 2.9.3. So I read about seeing if lwjgl's developers were going to add the option of choosing which graphics card you get to run on. I figured out that lwjgl 3 did have support for this. So I switched over to lwjgl 3. I got everything working and started to work on why I switched. I soon figured out that there is no documentation for changing which graphics card you use. So after hours of testing I figured out that you need to create a WGLARB context. I know you can just use the method: wglCreateContextAttribsARB(long hdc, long sharedContext, Byte/IntBuffer attribList). But it is unclear how to use this method. I am not sure if you use the windows DC Pointer or something else. I know you do not have to put anything in for the 'long sharedContext' so I put 'MemoruUtil.NULL'. So here are my questions:
How do you create a WGLARB context, or more specificly what do you specifically pass in, like do you put in an empty Int/Byte Buffer or do you put data into the buffer before you pass it in as a parameter. I do not know.
From there how do you use: WGLNVGPUAffinity.getInstance().wglCreateAffinityDCNV(gpuList); GPU list is either a PointBuffer or ByteBuffer how do I get this data to pass in in the first place?
Sorry about the long post, but I am very frustrated about the lack of documentation, Thank you in advance!
LWJGL 3 (through GLFW) handles OpenGL context creation. Which means you don't get to handle it. GLFW will create the context, though it does give you some options as to exactly how. But GLFW is cross-platform, so it doesn't give you Windows & NVIDIA-specific options.
However, that doesn't mean you don't get some control. LWJGL 3 also gives you access to the platform-specific APIs (GLX, WGL, etc), as well as extensions to them. So you can use WGL.wglGetCurrentContext to get the context, then use the WGLNVGPUAffinity functions to create affinity contexts. That extension provides all of the various tools for enumerating GPUs and creating new OpenGL contexts that target a specific GPU.
The extension specification is even nice enough to provide sample code for enumerating GPUs. Of course, it's NVIDIA only, but that clearly isn't a problem for you.
My goal is to write a Visual Studio plugin (a VSPackage) for my Java application. I was wondering if it was possible to view some JPanels inside a System.Windows.Forms instance, or rather as an Microsoft.VisualStudio.Editor.
I was thinking an applet but I'm pretty much stuck there...
Is streaming a Swing component as JPEG and displaying it in a Form an applicable idea?
EDIT:
I would really appreciate answers that are more then a "yes"/"no"/"why would you do this?". I made my mind about working this way, so I ask for:
A detailed solution for achieving my goal, OR,
Good insights/ideas of what my approach should be, OR,
A thorough explanation for why it is impossible to achieve.
( ) Way of the warrior
Load the JVM from your extension (use jvm.dll).
Implement your own Applet Container. Something like this AppletViewer.
Put the Applet Container inside your native form. This is hard, there are ways to get the Applet Container HWND (In Java Swing how do you get a Win32 window handle (hwnd) reference to a window?), but I am not sure a simple SetParent can do the trick.
Load your Applet.
( ) Way of the master
Use NPAPI/NPRuntime, like the browsers do.
Load the npjp2.dll Java Plug-In.
Load your applet.
(X) The solution adopted was:
Run the VS Plugin part written in Java (like an Applet) with JVM in another process (the standard for Java).
Get the HWND using FindWindow (Win32 API).
Use SetParent (Win32 API) and MoveWindow (Win32 API), to dock the window and resize it.
I could name it the "the easiest way", but running Java in another process will give you more stability, so this is the "way that works". My only fear about using a window from another process, was the thread that process Windows messages in Java could interfere in Visual Studio. But from what I see, there is nothing to fear.
:-)
I'm embarking on a project where I need to use the java.awt.Robot class to interact with a program on the Windows OS.
Is there I can query the system for say, a running instance of "notepad" and have it return me the window dimensions? I'm just using "notepad" as an example. I can't discuss the actual program I'm trying to interact with.
I hope the question isn't too vague. If task manager is able to keep a running list of what is happening, then shouldn't I be able to also find my specific program?
Edit: Based on the answer I have received so far, I have examined the calling win32 api method from java that has been suggested. But I am still vague on how to get the win32 to solve my problem. That thread is asking on how to use dll's.
My problem, as far as I know, is just getting a running instance of "notepad" and then using the win32 api's GetWindowRect method to return me a dimension that I can then use with Robot to tell me where to go. Unfortunately I have no idea on how to do this, I am still fairly new when it comes to Java. Any help would be appreciated.
It depends on what you are trying to do.
If you want to get window dimensions, you should recognize that win32 api can provide that information.
And, if win32 api is providing that information, how do you call win32 api functions from java? is the question you should be asking.
Is there any way to get the title and coordinates of the active window on the desktop? Window can belong to any process, not necessarily to the one that I'm developing. I'd like to do it on java, probably with the calls of some native API.
Someone correct me if i am wrong but you wont be able to use a native API with java if it isnt part of java already, meaning you wont be able to find a pure Java solution.
You can use JNI(Java Native Interface) to create a 'link' using C/C++ and that would allow you to use native API from Java.
EDIT: JNA(Java Native Access) is another possible solution i believe.
You could also use C# or VB.net which i believe that already have support for windows API.
The functions you are looking for might be
GetForegroundWindow to get the window itself.
GetWindowRect to get coordinates.
( note that these links are for C++, C#/VB might have access to those in some way )
For you to use Java you will have to ,as i said, somehow 'link' the native API with java because Java alone can't.
This question about getting window title might have answers that explain Java's limits for this type of things better.
Get current active window's title in Java
I have a java program that launches a program on start up. This can be any executable. Problem is that the java app is applying several inputs to any running app when it's focused ( the app performs keyboard input/output)
Someone told me it's not possible to make such call directly from Java to see which program is focused. So I can't make a check whether the desired application is focused or not.
like
if(processName == launchedExeName) // Do code
Are there any tools or libraries which I can implement in my java project?
thanks,
Sidar
You won't be able to do that directly from java without some native calls. Some library may already do that for you, but I'm not aware of any. So you'll have to write it yourself - also that's obviously completely OS dependent.
For windows it's relatively simple (and afaik there's some JNI wrapper for the win32 api so you don't have to do that yourself, maybe look around a bit), I actually had to write something similar some time ago, so here's the basic version (without error checking for simplicity):
HWND hForeground = GetForegroundWindow();
DWORD pid;
GetWindowThreadProcessId(hForeground, &pid);
HANDLE hProc = OpenProcess(PROCESS_QUERY_INFORMATION, TRUE, pid);
We now have the handle to the process and you can do whatever you want with it. If you want the path of the process, this would go something like:
DWORD size = MAX_PATH;
TCHAR pathName[MAX_PATH];
QueryFullProcessImageName(hProc, /*win32 path format*/ 0, pathName, &size);
Trivial really (it gets a good bit more complicated though if you want to receive events whenever the foreground changes), just the error handling blows the code up as usual.
As I said I remember reading about some Win32 wrappers in Java, so you may not have to write the JNI/JNA stuff yourself. And no idea about *nix here.