0

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!

dale
  • 439
  • 3
  • 11
  • 28
  • 1
    You said neither of them returns meaningful HWND value, do you have tried use [GetLasterror](https://learn.microsoft.com/en-us/windows/win32/debug/retrieving-the-last-error-code) to find the cause? you can also use [spy++](https://learn.microsoft.com/en-us/visualstudio/debugger/introducing-spy-increment?view=vs-2019) to get the hwnd of Eclipse SWT app and see if it works. – Strive Sun Jan 02 '20 at 06:13
  • Thanks Strive Sun. It turns out FindWindow actually worked after I did some further tuning. However FindWindow only works by identifying window through the window title such as "App v1". Any changes made to it later such as "App v2" will break the process. Is there a more permanent way of handling it using Eclipse SWT at API level - like "seraphy" did with JFrame? I also had a quick look at spy++, it provides a GUI view of window processes and threads. But not necessarily integrating it with existing framework. – dale Jan 03 '20 at 03:29
  • It is a better way to start from the `process`. Refer: [Get Main Wnd Handle of application](https://stackoverflow.com/questions/6202547/win32-get-main-wnd-handle-of-application) – Strive Sun Jan 03 '20 at 07:13
  • hi dale, does my comment helpful to you? – Strive Sun Jan 06 '20 at 02:12
  • Thank you @StriveSun-MSFT for taking time to respond to my question. Your recommendation certainly help me thinking in a different direction. I did however later found a workaround to this issue I had. Which is getting the title from my Java application and pass it down to JNI native code as "handle" so any change made to my application title, say "App v2" will not break my JNI native calls downstream. I'm not sure if I should consider this an answer to my own question as it still feels like a bit of workaround unless anyone has better ideas. Cheers Dale – dale Jan 07 '20 at 04:11
  • You can write down your own answer. If you think this solution can solve the current problems well. – Strive Sun Jan 07 '20 at 10:04

0 Answers0