Wupdate.exe problem

[NewsArchive]

Hi Friedrich,

A mutual client has run into a problem with some code that I use to
run programs. It doesnt' work with Wupdate.exe on his XP machine.

After some digging into this, I have found out that the code I use -
which uses ShellExecuteEx, WaitForSingleObject etc. - does NOT work
with Wupdate.exe if the program is not called with parameters. If it
is called with parameters, then everything is fine. This behaviour is
present on both XP SP2 and Vista Home Premium, both with all the
latest updates applied.

What seems to happen is that if Wupdate is called without parameters,
it waits for the calling process to terminate. When I terminate the
process using the Task Manager, the Wupdate.exe pops up immediately
after the calling process is terminated.

My code works properly with all other programs that I have tried it
with and I (and others) have been using this for about 6 months now
without issues.

http://www.buildautomator.com/stuff/SetupBuilder/RunProgram.zip

This file includes a Clarion 6.3, 9058 application and the compiled
EXE. Run the exe and select a wupdate.exe and check the Wait
checkbox. The program will attemt to run wupdate.exe but stops as
it's waiting for wupdate.exe to terminate. Wupdate.exe OTOH seems to
be waiting for test.exe to terminate before it continues. Now try it
again with the "/C /S" parameters and it will run fine.

I can run any other program with this test.exe, including the Setup
Builder IDE without any issues.

Since I never call the Wupdate.exe with the wait parameter without
using the /S /C parameters also I have never run into this myself.
Just for fun I tried this on a wupdate.exe from SB5 and it produced
the same results.

I tried to run the BuildAutomatorInstall.exe from the Test.exe and let
it wait and there I also get the same results. The install doesn't
show until I terminate Test.exe. When test.exe disappears from the
task list in Task Manager the install appears immediately.

On my quest to execute installs, I'm realizing that installs build
with earlier 4.0, 5.5 or 6.x (6.6 2040 in the htm reported on a file
that does work) do NOT show this behaviour. New installs that are
compiled in the latest build DO show this behaviour. I have tried to
run several installs that I have and were not created with SB and none
of them shows this behaviour when run with wait turned on. It seems
that this behaviour started in the installs sometime during 6.7-6.8
and they now also behave like wupdate.exe

I dont' make much sense of it, but it seems that you cannot run exes
created in Setup Builder from a different process and use
WaitforSingleObject() to wait for it.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

I am at home right now and can't test your application. I have created a
small ShellExecute demo:

http://www.lindersoft.com/projects/ShellExecute.zip

SellExecute.exe uses he ShellExecuteEx API to start test.exe. It does not
pass any parameter to the test.exe compiled with SB68.

On my Vista-64 machine here it "waits" for the SB68 application.

Does the above test application also cause problems on your machine?

Friedrich

[NewsArchive]

Hi Friedrich,

>On my Vista-64 machine here it "waits" for the SB68 application.
>
>Does the above test application also cause problems on your machine?

No, but these are not Clarion exes, are they?

If I run the ShellExecute.exe from _my_ Test.exe it works fine and my
Test.exe waits for your ShellExecute.exe to finish. If I run your
Test.exe from my Test.exe they are both locked.

All the code is in the app I uploaded. It really doesn't make sense
to me why it would fail on those SB exes only and nothing else...

I've tested it on XP SP2 (Home) and Vista Home Premium both with all
updates. If I have time later tonight I may try to duplicate this in
a VC++ application and see what happens there. Note that I'm using
Clarion 6.3 9058, but my client was using an older build (not sure
which one).

The basic code that I'm using looks like this:

SHi.fMask = IT_SEE_MASK_NOCLOSEPROCESS
SHi.hwnd = 0{Prop:Handle}
SHi.lpVerb = Address(Verb)
SHi.lpFile = Address(cCmdLine)
SHi.lpParameters = Address(cParam)
SHi.lpDirectory = Address(P)
SHi.nShow = IT_SW_SHOWNORMAL
SHi.lpIDList = 0
SHi.lpClass = 0
SHi.hkeyClass = 0
SHi.dwHotKey = 0
SHi.DUMMYUNIONNAME = 0
SHi.cbSize = Size(SHi)
If Not SELF.ShellExecEx(SHi)
hProc = 0
Else
hProc = Shi.hProcess
End
If hProc
If pWait
RetVal = IT_WaitForSingleObject(hProc,-1)
If IT_GetExitCodeProcess(hProc, lRetCode)
RetValue = lRetCode
Else
RetValue = RetVal
End
RetVal = IT_CloseHandle(hProc)
End
End

Now, this is interesting. If I add a message() in there:

If pWait
Message('pWait')
RetVal = IT_WaitForSingleObject(hProc,-1)

Then it works! The message pops up for about a second, then the SB
test.exe window shows up.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

> If hProc
> If pWait
> RetVal = IT_WaitForSingleObject(hProc,-1)

This has got to be one of the most silliest things I have ever
encountered<bg>

After a lot of thoughts and gallons of coffee and more thoughts I came
up with this instead:

If hProc
If pWait
Accept
Sleep(750)
Break
End
RetVal = IT_WaitForSingleObject(hProc,-1)

This works. But on XP it works without the Sleep. On Vista it needs
to wait for longer so I had to put in the Sleep() for that.

From this it seems that if the calling process starts waiting before
the window of the called process is drawn or something, it causes this
deadlock. Since I can't duplicate this with anything except
wupdate.exe or recent SB installs, it's very difficult to try to
pinpoint what is causing this. I have read back and forth pages after
pages of example code in VC, VB and Delphi on ShellExecuteEx and
WaitForSingleObject and I cannot see anything wrong or out of place
with my code that could possibly be causing this.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

>pinpoint what is causing this. I have read back and forth pages after
>pages of example code in VC, VB and Delphi on ShellExecuteEx and
>WaitForSingleObject and I cannot see anything wrong or out of place
>with my code that could possibly be causing this.

I've went through my code with a fine toothed comb and compared every
structure and every prototype to my MSDN. Everything should work
perfectly. Still doesn't. Your Shellexecute.exe runs my wupdate.exe
fine, but my test.exe does not. My guess is that your exe was made
with VC, where as mine is made with Clarion.

While this is not causing me any problems per se. this could be a
problem for people who want to create actions in the Build Automator
to do batch installs of for example third party tools to recreate a
development environment. They would run into that only earlier SB
installs would run and new ones would lock up.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> On my quest to execute installs, I'm realizing that installs build
> with earlier 4.0, 5.5 or 6.x (6.6 2040 in the htm reported on a file
> that does work) do NOT show this behaviour. New installs that are
> compiled in the latest build DO show this behaviour.

I have just installed SetupBuilder 6.0 Gold (Build 1718, dated December 18,
2006) and it also shows this behavior. See attached testme.exe. It display
a "test" message box and then "hangs".

This only happens when ShellExecuteEx() and Wait is used from Clarion
applications. VC++, etc. applications do not have this behavior.

So in fact, this "problem" is there for at least 18 months now. I'll
install SetupBuilder 5 now...

Friedrich

[NewsArchive]

Hi Arnór,

I wrote:
> So in fact, this "problem" is there for at least 18 months now. I'll
> install SetupBuilder 5 now...

Same "problem" in SetupBuilder 5 (see attached SB5 installer).

Friedrich

[NewsArchive]

I have debugged the code compiled by SetupBuilder and see where Clarion
(ShellExecuteEx/Wait) causes a "deadlock". The deadlock is in the dialog
initialization function. I'll keep you posted.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Arnór,

Okay, I found out what causes this. Because the SetForegroundWindow()
Windows API has been intentionally crippled by Microsoft, we have to use an
alternative called "ForceForegroundWindow" (most VC++ developers make use of
this function). Installations compiled with SetupBuilder 5 and 6 use that
function to bring the installation wizard into the foreground.

Unfortunately, this causes problems when a Clarion application uses the
ShellExecuteEx and WaitForSingleObject Windows APIs to start an SetupBuilder
application to wait for its termination.

So the only possible solution would be a new \CLARION command line switch.
If you use ShellExecuteEx and WaitForSingleObject from your Clarion
application to start a SetupBuilder installer and wait for it, then the
\CLARION switch would disable the (AttachThreadInput) API that causes this
"deadlock".

Would this be okay for you?

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Arnór,

I have attached a quick and dirty "ShellExecuteEx and Wait" source code demo
for Clarion. IMO, this is the correct way to handle it in Clarion and to
keep the system "alive".

What do you think?

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>I have attached a quick and dirty "ShellExecuteEx and Wait" source code demo
>for Clarion. IMO, this is the correct way to handle it in Clarion and to
>keep the system "alive".
>
>What do you think?

Well.... I don't know what the heck is wrong. When I compile the
.prj I get at 376 byte exe<g> There is definitely something wrong
with something...

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> Well.... I don't know what the heck is wrong. When I compile the
> .prj I get at 376 byte exe<g> There is definitely something wrong
> with something...

I downloaded the zip from this NG, unzipped it, compiled it and the result
is a 641 KB executable.

So it's something with your system <g>

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Arnór,

I have uploaded the source code and binary to:
http://www.lindersoft.com/projects/ClarionShellExec.zip

Friedrich

[NewsArchive]

Hi Arnór,

And here is an Clarion 6 .app (see attached).

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>Well.... I don't know what the heck is wrong. When I compile the
>.prj I get at 376 byte exe<g> There is definitely something wrong
>with something...

Ok, lesson learned: Do NOT mess with the FileSystem stuff in the
registry when tired, sleepy, reading newsgroups, following skype
cw-chat and reading several webpages at the same time<vbg>

Works fine now:)

I tested it on my vista machine which seemed to need extra time to
deal with this and it works fine - bit slow, but it works.

I'm sure you have tried this, but I have used SetWindowPos() to place
windows on top, but I certainly haven't tested it accross all the
different OSs etc.

If ITML_SetWindowPos(0 {Prop:Handle}, |
HWND_TOP,|
0,0,0,0, |
SWP_NOSIZE + SWP_NOMOVE + SWP_NOACTIVATE)

I have used this with controls and windows in Clarion with good
results.

Since I'm using this in generic code I will need to add a hidden
window to the method so I can set a timer on it and let it loop.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> Ok, lesson learned: Do NOT mess with the FileSystem stuff in the
> registry when tired, sleepy, reading newsgroups, following skype
> cw-chat and reading several webpages at the same time<vbg>
>
> Works fine now:)

:)

> I tested it on my vista machine which seemed to need extra time to
> deal with this and it works fine - bit slow, but it works.

Perhaps you can play with the timer a bit. It's set to 50 now.

> I'm sure you have tried this, but I have used SetWindowPos() to place
> windows on top, but I certainly haven't tested it accross all the
> different OSs etc.
>
> If ITML_SetWindowPos(0 {Prop:Handle}, |
> HWND_TOP,|
> 0,0,0,0, |
> SWP_NOSIZE + SWP_NOMOVE + SWP_NOACTIVATE)
>
> I have used this with controls and windows in Clarion with good
> results.

Unfortunately, this did not work for us. It took more than 4 months to find
the correct combinations of "ForceForegroundWindow" functions for
SetupBuilder and all kinds of operating systems.

Please note, this "hang" issue with the SetupBuilder installer is *NOT* <g>
a SetupBuilder bug!!!!

The problem with your ShellExecuteEx+Wait code is that the Clarion
application does not process any Windows messages while it is "waiting" for
the other application. All messages in Clarion are processes in the
ACCEPT() loop. The call to WaitForSingleObject stops message handling
immediately and the Clarion application (*NOT* the SetupBuilder
installer!!!) "hangs" or seems to hang.

Not a bug in SetupBuilder and it's also not a bug in Clarion. It's how
Clarion applications work in this case <g>

See your own test.exe application you sent. Create a copy of it and start
the second copy with the wait option enabled. Then move the second copy
around and you'll see what I mean (see attached screenshot). Your Clarion
application stopped processing messages <g>.

This does not happen with my ShellExecuteEx solution.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>Perhaps you can play with the timer a bit. It's set to 50 now.

There is a big problem with this approach. The application, while
waiting, is still active, which would break everything. It must not
be possible to activate the waiting program. After I run the program
from your code, I can go _back_ to the program! So essentially this
is no different than calling the program without waiting.

Calling WaitForSingleObject(,0) just checks the state of the called
program but does not wait for it and there lies the problem. The
question is if I could let it loop ONCE and then I hit it with
WaitForSingleObject(,-1) to make it wait and stop the timer. That way
there would just be a window of a single timer event.

I'll play with this to see what I can come up with.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> So essentially this is no different than calling the program without
> waiting.

The major difference is that you get the return value from that application
if you wait. If you do not wait, no return value ;-)

I am sure you'll find a solution to this. But IMO, using the timer is the
only possible way to handle this in Clarion. Of course, sub-classing would
open other doors.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>I'll play with this to see what I can come up with.

IF WaitForSingleObject(sei.hProcess, 1000) = 0
ELSE
Window{PROP:Timer} = 0
WaitForSingleObject(sei.hProcess, -1)
END
I# = GetExitCodeProcess(hProc, lRetCode)
I# = CloseHandle(sei.hProcess);
MESSAGE('Return Code: ' & lRetCode)

Works on both XP and Vista in the test project. Now I need to figure
out how this holds up in real life...

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

>See your own test.exe application you sent. Create a copy of it and start
>the second copy with the wait option enabled. Then move the second copy
>around and you'll see what I mean (see attached screenshot). Your Clarion
>application stopped processing messages <g>.

That's what it must do when it's waiting or the waiting is rather
pointless if it continues to process<bg>

>This does not happen with my ShellExecuteEx solution.

No, because it doesn't solve the problem. It _doesn't wait_ for the
called program. You can alt-tab back to the calling program
immediately

Run your ShellExecuteEx.exe
Select a program to run and click run
Then alt-tab back to your program and click Run again

You now have TWO instances of what ever program you selected to run.
Your solution is NOT waiting for the program at all. It would work
exactly the same if you remove all the code except the call to
ShellExecuteEx.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

> That's what it must do when it's waiting or the waiting is rather
> pointless if it continues to process<bg>

I disagree <g>. So you don't need Paint events to "repaint" your
application <g>.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>> That's what it must do when it's waiting or the waiting is rather
>> pointless if it continues to process<bg>
>
>I disagree <g>. So you don't need Paint events to "repaint" your
>application <g>.

The whole concept of the waiting enforced on an application is that
it's completely dead. It doesn't process events, it doesn't process
messages, it doesn't do ANYTHING. For example the Build Automator
CANNOT do ANYTHING while a running process is executing if it is set
to wait for it because the next action may be relying on data from the
process it is waiting for. It's stopped absolutely dead in it's
track. It MUST be. There is nothing accessible, no user
interactivity, no nothing. This is what WaitForSingleObject does.
Yes, it can be used to run concurrently and only grab the exit code,
but then it's not waiting. This is what Run() in Clarion does, when
it waits. This is what people use WaitForSingleObject for.

Now I _could_ impelement a concurrent checking in the Build Automator
and may at some point to make things more interactive, but not right
now. That said, that is not a good generic solution for example for
my classes as it presents a lot of issues with what to do on the
calling process while it's waiting.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Arnór,

>>I disagree <g>. So you don't need Paint events to "repaint" your
>>application <g>.
>
> The whole concept of the waiting enforced on an application is that
> it's completely dead. It doesn't process events, it doesn't process
> messages, it doesn't do ANYTHING. For example the Build Automator
> CANNOT do ANYTHING while a running process is executing if it is set
> to wait for it because the next action may be relying on data from the
> process it is waiting for. It's stopped absolutely dead in it's
> track. It MUST be. There is nothing accessible, no user
> interactivity, no nothing. This is what WaitForSingleObject does.
> Yes, it can be used to run concurrently and only grab the exit code,
> but then it's not waiting. This is what Run() in Clarion does, when
> it waits. This is what people use WaitForSingleObject for.
>
> Now I _could_ impelement a concurrent checking in the Build Automator
> and may at some point to make things more interactive, but not right
> now. That said, that is not a good generic solution for example for
> my classes as it presents a lot of issues with what to do on the
> calling process while it's waiting.

Yes and no <g>. If you use WaitForSingleObject in other languages, then the
parent is not accessible. For example, if you use SetupBuilder to create an
application and call from this application (via ShellExecuteEx and Wait)
another application, then the parent application is not accessible but still
receives "standard" Windows events. This is not the case if you are using
WaitForSingleObject in Clarion, so you have to find a way to 1) still
process Windows messages and 2) make sure the calling application is not
accessible. Not an easy job :) I am more than happy that I don't have to
do it.

Hope this makes sense.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

By the way, IMO, sub-classing can be the key here.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>WaitForSingleObject in Clarion, so you have to find a way to 1) still
>process Windows messages and 2) make sure the calling application is not
>accessible. Not an easy job :) I am more than happy that I don't have to
>do it.
>
>Hope this makes sense.

Yep. The question though is why this is an issue with Clarion and
also why this seems to be only an issue with SB compiles. I have been
using this code for quite a while, more and less how it is and have
not run into anything that it failed on except SB compiles.

That prompts the question, out of curiousity, why you do need this
code in SB compiles? What problems does it cause if the SB compile
doesn't have it? What I'm talking about is the ForceForegroundWindow
which I have only found in Delphi code so far<g>

I think you are right that subclassing might be the ticket here to
keep the message pump going in Clarion while the OS does it's thing.
Trick would be to make sure the blasted thing - either one - doesn't
run away from you!<bg>

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Arnór,

>>Hope this makes sense.
>
> Yep. The question though is why this is an issue with Clarion and
> also why this seems to be only an issue with SB compiles. I have been
> using this code for quite a while, more and less how it is and have
> not run into anything that it failed on except SB compiles.

Well, because your Clarion application cannot handle the AttachThreadInput
stuff from the installer.

But you have issues in your own application <g> Or don't see the "Repaint"
issue (see screenshots of your own application in my previous post)? Same
story. Your Clarion application stopped receiving messages (means it also
fails <g>).

If you add a MESSAGE() then the Clarion application handles the
AttachThreadInput stuff and continues.

I have again attached one screenshot to demonstrate what I mean. Your
parent application starts a client application (and waits for it) and stopps
message handling. So "paint" events are not processed and when moving the
client arount you suddenly see three (or more) "Test window" dialogs. Or a
white background.

Do you see what I mean?

> That prompts the question, out of curiousity, why you do need this
> code in SB compiles? What problems does it cause if the SB compile
> doesn't have it? What I'm talking about is the ForceForegroundWindow
> which I have only found in Delphi code so far<g>

The problem is not the ForceForegroundWindow or whatever code. Your Clarion
application stopps processing Windows messages and THAT is the problem ;-)
You can run into all kind of problems if you continue to do it how you do it
right now. AttachThreadInput is only one of a few hundred APIs that can
cause trouble here.

> I think you are right that subclassing might be the ticket here to
> keep the message pump going in Clarion while the OS does it's thing.
> Trick would be to make sure the blasted thing - either one - doesn't
> run away from you!<bg>

<bg> :)

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Arnór,

I have attached a slightly modified Clarion .app. It will disable the
"Browse..." and "Run..." buttons while the other application is running.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>I have again attached one screenshot to demonstrate what I mean. Your
>parent application starts a client application (and waits for it) and stopps
>message handling. So "paint" events are not processed and when moving the
>client arount you suddenly see three (or more) "Test window" dialogs. Or a
>white background.

Right now, screen painting of the calling application is not an issue
for me.

>The problem is not the ForceForegroundWindow or whatever code. Your Clarion
>application stopps processing Windows messages and THAT is the problem ;-)
>You can run into all kind of problems if you continue to do it how you do it
>right now. AttachThreadInput is only one of a few hundred APIs that can
>cause trouble here.

I'm aware of that, but the fix has to be carefully crafted so I'm not
rushing into this.

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

>The problem is not the ForceForegroundWindow or whatever code. Your Clarion
>application stopps processing Windows messages and THAT is the problem ;-)
>You can run into all kind of problems if you continue to do it how you do it
>right now. AttachThreadInput is only one of a few hundred APIs that can
>cause trouble here.

Fixed:)

I simply changed the window in the clarion code to be modal, which
makes it lock up the background processes in the app while it waits,
but keeps the modal window running to process whatever may be
requested of the running application. Works absolutely perfectly:)
Now there is a little window that pops up that says something like
"External program running, please wait..." and it sits there waiting
patiently for the running process to terminate:

W
WINDOW,AT(,,204,25),FONT('Tahoma',8,,),CENTER,ALRT (EscKey),ALRT(AltF4),GRAY,DOUBLE,MODAL
STRING('External program running, please wait...'),AT(7,7,195,10),USE(?String1),FONT(,,,FON T:bold)
END

....
If hProc
If pWait
Open(W)
W{Prop:Timer} = 50
Accept
Case Event()
Of EVENT:Timer
If IT_WaitForSingleObject(hProc, 0) = 0
If IT_GetExitCodeProcess(hProc, lRetCode)
RetValue = lRetCode
Else
RetValue = RetVal
End
RetVal = IT_CloseHandle(hProc)
W{Prop:Hide} = False
Close(W)

I've tested this on both Vista and XP and it just works:) I think
this accomplishes what needs to be accomplished with the absolutely
minimum amount of work;) Finally, after 13 years, I found a use for
the MODAL attribute!<bg>

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php

[NewsArchive]

Arnór,

> Fixed:)
>
> I simply changed the window in the clarion code to be modal, which
> makes it lock up the background processes in the app while it waits,
> but keeps the modal window running to process whatever may be
> requested of the running application. Works absolutely perfectly:)
> Now there is a little window that pops up that says something like
> "External program running, please wait..." and it sits there waiting
> patiently for the running process to terminate:
<SNIP>

Now that is a cool solution :)

> Finally, after 13 years, I found a use for the MODAL attribute!<bg>

<BG> Very well done!!!!

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

>> Finally, after 13 years, I found a use for the MODAL attribute!<bg>
>
><BG> Very well done!!!!

I think this takes care of this completely:) From the docs:

"An application-modal window is a non-MDI window opened as the top
window of an MDI execution thread. An application-modal window
restricts the user from moving to another execution thread in the same
application, but does not restrict them from changing to another
Windows program."

I alerted the Esc and Alt-F4 keys on the window so it can't be closed
accidentally. So far it looks very good:)

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php