views:

58

answers:

5

Hi.

I'm trying to control a Java application from my C# program. Before the program begins to input data, it checks if there are any pervious data input windows, and tries to close them.

The code for checking if a window exists is:

public static bool WindowExists(string WindowName)
{
    IntPtr hWnd = FindWindow(null, WindowName);
    return (hWnd != IntPtr.Zero);
}

Until now, I simply used this method in a while loop (sending Alt+F4 to the windows), until there was no open input window left.

A while ago the Java application got an update, and this method no longer works. For some reason, WindowExists keeps returning true, even after the data input window is closed. This only happens if the input window existed at least once.

I even tried to add Thread.Sleep() to the loop, to make sure this isn't caused by some latency in the Java app, but it didn't work.

Sometimes simply calling WindowExists crashes the input window.

There's no problem with the code, because it has worked before, and it still works with other programs, so it must be a problem with the update in the Java program.

Is there any alternative/more reliable way to check if a window exists? Changing sending Alt+F4 to "close window event" might also worth a try, but I have no idea how to send this event to another program's window.

I'm a newbie, so please keep the answer simple.

Thanks in advance.

+1  A: 

I would use Spy++ to watch the window handle of the Java app, and see if you can figure out what else is going on - I agree there has to be a way to tell that it is closed.

I assume watching the process list is out of the question...

davisoa
A: 

I would hazard a guess that whilst the Java app is running and consequently, the JVM, the 'handle' to the window has not yet been garbaged collected and as such appears to the underlying pointer mechanism as still being valid.

If it was me writing that stuff (and if I was able to change the Java code) I'd probably add a means of querying the java app to see if its windows are showing. A sockets interface or something.

Rob Lowther
Unfortunately, the Java app is not mine. Is it possible to to bypass this problem, by somehow "counting" the open windows in in the taskbar, and if the window with the correct name disappears, we know that it was closed, no matter what FindWindow says.
Miklós
I'm assuming that you're using the Windows SDK function 'imported' into C# to do the FindWindow call. If you've got that bit of programming worked out, why not use the other SDK function IsWindowVisible, using the HWND you got from find window.
Rob Lowther
A: 

My guess is that either the window hasn't been completely disposed of by the Java code/VM, or it's handling Alt+F4 in some special way (i.e. maybe making itself invisible rather than closing).

Guy
Now that you mention it, before the update, i was able to close the input window with either Alt+F4 or Esc, but now only sending Esc works. Now if I send or press Alt+F4, the window seems to close, but it reopens(unhides?) right away
Miklós
A: 

Creation/deletion of windows is out of your control. If you want to reliably detect the presence of 'someone else' using the same resource a you want, have that other party communicate it explicitly.

The other party may signal it's presence by creating a file, opening a port, whatever, and can release/delete/close it on it's exit.

xtofl
When the input window opens inside the Java app, it gets a separate button in the taskbar, so if i could watch the taskbar somehow, and see if the window with the correct name disappears from there, I would know, that the input window was closed, no matter what FindWindow says.
Miklós
A: 

Try to make additional check using IsWindow API, on hWnd value returned by FindWindow.

Alex Farber
Unfortunately, after I open open an input window for the first time, IsWindowVisible, FindWindow, and IsWindow all switch to true. After that, when I close the input window, only IsWindowVisible returns to false.
Miklós