SetFocus issue (was: ShellExecuteEx SetFocus problem)

[Sinna]

Hi all,

I started a new chapter in the SetFocus issue as I found out it really
had nothing to do with the ShellExecuteEx API itself.

(Sorry for the long post but it's quite difficult to situate the issue here)

First some explanation of what I want to achieve:
I want to mimic the Windows Explorer by allowing the user to launch the
associated executable for a given file (for editing). I also want to
monitor if the user has made some changes to the file to keep it in sync
with the server.
To launch the associated executable, I use the ShellExecuteEx API (as
mentioned in the ShellExecuteEx SetFocus problem thread). In that way I
don't have to look up the associated executable myself. (Why re-invent
the wheel?).
To monitor changes in the opened/edited file, I monitor for the closing
of the launched application using the MsgWaitForMultipleObjects API.

Now the problem:
Due to the fact that VB is single-threaded, In some cases I experience
timing issues causing my application to appear stalling. To circumvent
this, I launch a worker thread (read: separate ActiveX EXE) that deals
with the MsgWaitForMultipleObjects API. This has a nasty side-effect as
the application launched does not pop up but seems to be minimized in
the task bar. The launched application receives the focus (blinking a
few times), but it doesn't pop up.
As long as I don't use the separate ActiveX EXE, everything works as
expected.

What I assume is that, since the ActiveX EXE has no GUI, the OS doesn't
know where to put the launched application in front of.
Calling the AppActive statement doesn't work out.

Strange enough, when using the ShellExecuteEx API, it works as expected
in 95% of the cases, but fails in the other 5% causing major grief by
the end user. If I look up the associated executable myself (digging
into the registry) and launches the application using the built-in Shell
function, it fails in 95% of the case, succeeding in the other 5%.


Any suggestions how to deal with this nasty side effect?
Please feel free to ask some sources, but it's quite difficult to post
them as they are quite large.

Thanks in advance,
Sinna

[Robert Morley]

It's probably not the solution you're looking for, but what about launching
the associated executable in the main program, then calling your worker
thread to wait for the object? Or is that what you're already doing?

Either way, the fact that it fails intermittently makes me suspect a timing
problem. If no other solution presents itself, you could try adding a small
delay between launching and monitoring the file and see if that helps. A
full second should be loads of time by computer standards, but it's unlikely
that a user would make meaningful changes in such a short time.



Rob

Post by Sinna
Hi all,
I started a new chapter in the SetFocus issue as I found out it really had
nothing to do with the ShellExecuteEx API itself.
(Sorry for the long post but it's quite difficult to situate the issue here)
I want to mimic the Windows Explorer by allowing the user to launch the
associated executable for a given file (for editing). I also want to
monitor if the user has made some changes to the file to keep it in sync
with the server.
To launch the associated executable, I use the ShellExecuteEx API (as
mentioned in the ShellExecuteEx SetFocus problem thread). In that way I
don't have to look up the associated executable myself. (Why re-invent the
wheel?).
To monitor changes in the opened/edited file, I monitor for the closing of
the launched application using the MsgWaitForMultipleObjects API.
Due to the fact that VB is single-threaded, In some cases I experience
timing issues causing my application to appear stalling. To circumvent
this, I launch a worker thread (read: separate ActiveX EXE) that deals
with the MsgWaitForMultipleObjects API. This has a nasty side-effect as
the application launched does not pop up but seems to be minimized in the
task bar. The launched application receives the focus (blinking a few
times), but it doesn't pop up.
As long as I don't use the separate ActiveX EXE, everything works as
expected.
What I assume is that, since the ActiveX EXE has no GUI, the OS doesn't
know where to put the launched application in front of.
Calling the AppActive statement doesn't work out.
Strange enough, when using the ShellExecuteEx API, it works as expected in
95% of the cases, but fails in the other 5% causing major grief by the end
user. If I look up the associated executable myself (digging into the
registry) and launches the application using the built-in Shell function,
it fails in 95% of the case, succeeding in the other 5%.
Any suggestions how to deal with this nasty side effect?
Please feel free to ask some sources, but it's quite difficult to post
them as they are quite large.
Thanks in advance,
Sinna

[Sinna]

Post by Robert Morley
It's probably not the solution you're looking for, but what about launching
the associated executable in the main program, then calling your worker
thread to wait for the object? Or is that what you're already doing?
Either way, the fact that it fails intermittently makes me suspect a timing
problem. If no other solution presents itself, you could try adding a small
delay between launching and monitoring the file and see if that helps. A
full second should be loads of time by computer standards, but it's unlikely
that a user would make meaningful changes in such a short time.
Rob

Hi Rob,

Thanks for your suggestion as it opens some opportunities here.
In fact you're proposing the combination of both worlds: launch the
application and monitor in the same thread (as I did before resulting in
timing issues), and launch and monitor in another thread (as I do now
resulting in the SetFocus issue).
I'll work it out and hopes it will solve both issues (timing and
SetFocus) as I'm running out of time (deadline to reach).

Sinna

[Sinna]

Post by Robert Morley
It's probably not the solution you're looking for, but what about launching
the associated executable in the main program, then calling your worker
thread to wait for the object? Or is that what you're already doing?
Either way, the fact that it fails intermittently makes me suspect a timing
problem. If no other solution presents itself, you could try adding a small
delay between launching and monitoring the file and see if that helps. A
full second should be loads of time by computer standards, but it's unlikely
that a user would make meaningful changes in such a short time.
Rob

However you think it is not the solution I was looking for, it really
is! I've implemented it the way you suggested and... IT WORKS !! (Finally!)

Thank you very much for this lighting idea!


Sinna

[Robert Morley]

Glad I could be of help!


Rob

Post by Robert Morley
It's probably not the solution you're looking for, but what about
launching the associated executable in the main program, then calling
your worker thread to wait for the object? Or is that what you're
already doing?
Either way, the fact that it fails intermittently makes me suspect a
timing problem. If no other solution presents itself, you could try
adding a small delay between launching and monitoring the file and see if
that helps. A full second should be loads of time by computer standards,
but it's unlikely that a user would make meaningful changes in such a
short time.
Rob

However you think it is not the solution I was looking for, it really is!
I've implemented it the way you suggested and... IT WORKS !! (Finally!)
Thank you very much for this lighting idea!
Sinna

[Ralph]

Post by Sinna

Post by Robert Morley
It's probably not the solution you're looking for, but what about launching
the associated executable in the main program, then calling your worker
thread to wait for the object? Or is that what you're already doing?
Either way, the fact that it fails intermittently makes me suspect a timing
problem. If no other solution presents itself, you could try adding a small
delay between launching and monitoring the file and see if that helps.

A

Post by Sinna

Post by Robert Morley
full second should be loads of time by computer standards, but it's unlikely
that a user would make meaningful changes in such a short time.
Rob

However you think it is not the solution I was looking for, it really
is! I've implemented it the way you suggested and... IT WORKS !! (Finally!)
Thank you very much for this lighting idea!
Sinna

A bit late ...

You may wish to further simplify the application by using the API Calls
FindFirstChangedNotification, FindNextChangeNotification, &etc.

These calls effectively queue changes, thus removing the issue of timing.

-ralph

[Sinna]

Post by Robert Morley

Post by Sinna

Post by Robert Morley
It's probably not the solution you're looking for, but what about

launching

Post by Sinna

Post by Robert Morley
the associated executable in the main program, then calling your worker
thread to wait for the object? Or is that what you're already doing?
Either way, the fact that it fails intermittently makes me suspect a

timing

Post by Sinna

Post by Robert Morley
problem. If no other solution presents itself, you could try adding a

small

Post by Sinna

Post by Robert Morley
delay between launching and monitoring the file and see if that helps.

A

Post by Sinna

Post by Robert Morley
full second should be loads of time by computer standards, but it's

unlikely

Post by Sinna

Post by Robert Morley
that a user would make meaningful changes in such a short time.
Rob

However you think it is not the solution I was looking for, it really
is! I've implemented it the way you suggested and... IT WORKS !!

(Finally!)

Post by Sinna
Thank you very much for this lighting idea!
Sinna

A bit late ...
You may wish to further simplify the application by using the API Calls
FindFirstChangedNotification, FindNextChangeNotification, &etc.
These calls effectively queue changes, thus removing the issue of timing.
-ralph

Sorry I drop in quite late here but I was a week out of office.
I know the existence of FindFirstChangedNotification and
FindNextChangeNotification but I wonder if it applicable for my
particular case as I have to monitor the closing of the launched
application, not of the file it opened.

If you could provide some more information or a link to an article or
so, I'd be pleased.

Sinna

[Ralph]

<snipped>

Post by Sinna
Sorry I drop in quite late here but I was a week out of office.
I know the existence of FindFirstChangedNotification and
FindNextChangeNotification but I wonder if it applicable for my
particular case as I have to monitor the closing of the launched
application, not of the file it opened.
If you could provide some more information or a link to an article or
so, I'd be pleased.
Sinna

"To monitor changes in the opened/edited file, I monitor for the closing
of the launched application using the MsgWaitForMultipleObjects API."

I misconstrued the above to mean you were only tracking the app to track
file changes.

-ralph

[Sinna]

Post by Ralph
<snipped>

Post by Sinna
Sorry I drop in quite late here but I was a week out of office.
I know the existence of FindFirstChangedNotification and
FindNextChangeNotification but I wonder if it applicable for my
particular case as I have to monitor the closing of the launched
application, not of the file it opened.
If you could provide some more information or a link to an article or
so, I'd be pleased.
Sinna

"To monitor changes in the opened/edited file, I monitor for the closing
of the launched application using the MsgWaitForMultipleObjects API."
I misconstrued the above to mean you were only tracking the app to track
file changes.
-ralph

That's what it has to do indeed, but only after closing the application
I want to check if the user has changed the file because it doesn't make
sense to synchronize while still editing.

Thanks anyway.

Sinna