Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PP9 Unload Failure

2 views
Skip to first unread message

John W

unread,
Jan 3, 2001, 9:47:52 PM1/3/01
to
I'm having a problem with the PP9.439 executables I've created. Upon
completion, the scripts unload PP9. Everything works fine until two
executables, which are event driven, fire off at the same time. In that
case, only one instance of PP9 is unloaded leaving the first instance
running as noted in the Task Manager. Eventually this causes a cascade of
PP9 errors & the program calling the .exe's crashes. Is there a way for the
current script to determine if a previous instance of PP9 is still running &
then wait until it is finished before firing off a new instance?

It looks as if GetProcessID could be used to monitor CorelScript .exe's, but
what could be used to monitor PP9 itself? GetAppHandle? I'd really
appreciate any assistance. OS's used, Windows2000, ME, & 98SE- same result
for all.

Thanx-

JohnW


Alex Vakulenko

unread,
Jan 15, 2001, 11:07:36 AM1/15/01
to
Hi John,

> It looks as if GetProcessID could be used to monitor CorelScript .exe's, but
> what could be used to monitor PP9 itself? GetAppHandle? I'd really
> appreciate any assistance. OS's used, Windows2000, ME, & 98SE- same result
> for all.
You can use Windows API functions to find the application (FindWindow). You should do it like this:
 
DECLARE FUNCTION FindWindow LIB "user32" \\
    (BYVAL Class$,BYVAL Name&) AS LONG ALIAS "FindWindowA"

hWnd&=FindWindow("PhotoPaint",0)
IF hWnd=0 THEN
    Message "Photo-Paint is not running"
ELSE
    Message "Photo-Paint is running"
END IF
I hope this helps...
 
--
Alex

John W

unread,
Jan 16, 2001, 6:22:24 PM1/16/01
to
Thanks again Alex,

I'm checking http://www.vbapi.com/ to see if I can find a process kill
function that will unload PhotoPaint if it stalls/errors out or if it is
still running after the .FileExit & ENDWITHOBJECT commands have been issued
& before the STOP command. It's bizarre. I've resolved issues on Windows2000
systems, but on ME we're still having probs. One time, a script exe works
fine, the next time it stalls.

I suspect that ME has some file locking issues with some of the OS commands
(COPY & KILL are all I use)- I'm going to insert some WAIT FOR commands to
see if this resolves anything.

I'm trying to understand how your code below solicits the OS to determine if
PP9 is running- see ?'s below. I'm still learning the basics, so bare with
me.

DECLARE FUNCTION FindWindow LIB "user32" \\
(BYVAL Class$,BYVAL Name&) AS LONG ALIAS "FindWindowA"

I assume these lines read in the process name into string variable Class, &
the process ID into long variable Name. Then what? They go into FindWindowA.
What's ALIAS do? This is not documented in CS help or in API. How does one
translate hWnd&=FindWindow("PhotoPaint",0) into English?

Here's how I'd like it to work- if the value of the function = 0 then PP9 is
not running (then STOP), otherwise unload PhotoPaint (with API equivalent
for unload). The other thing I'm trying to do is get this thing to kill any
onscreen error messages & exit PhotoPaint if any errors do pop up. I'm using
the ON ERROR RESUME NEXT because ON ERROR GOTO LogErrors allows error code
dialog boxes to pop up. But even with that, the system fails to detect an
error, the script executable stalls, & it doesn't RESUME NEXT.

It's frustrating at best. Thanx ahead of time for any insights you might
have. - JohnW

"Alex Vakulenko" <al...@vakcer.com> wrote in message news:3a6320c6@cnews...

John W

unread,
Jan 17, 2001, 6:50:16 PM1/17/01
to
You are the man Alex,

I really appreciate your help. I may have isolated the problem with my
script executables on ME. From watching the system monitor for allocated
memory, it appears that upon exit PhotoPaint does not free up memory to the
point where it was before it started. Instead the allocated memory figure
seems to go back to the previous level plus 3% or so. Not so with Win2000-
scripts finish & blam we're back to where we were before starting. I'm not
sure if this is due to ME or the shell app. calling my scripts. I'm going to
run them manually to see if I get the same results.

This morning I added a bunch of WAIT FOR lines (totaling about 3
seconds/script) around all OS commands in these 41 scripts, hoping this
would overcome any ME weaknesses relating to file
locking/access/permissions.

Relating to the kill PhotoPaint process using Windows API functions, what
happens if my scripts stall before getting to the API line to terminate
PhotoPaint and/or any error messages it may have produced? I'm thinking I
could put the TerminateProcess under the Return: label as you describe in
the error handling routine below, but if this script stalls, how does it
know it has stalled? Not all errors are detectable, are they?

Finally, how would I go about using Windows API functions to resolve the
allocated memory problem described above? On exit I want PhotoPaint to free
up all resources it has used with no remnants left behind. Would using VBA
be more reliable than CS executables? According to your website, it sound
like it would definitely be more efficient, but are all the layer blending
modes available in VBA- like screen & multiply, hard light, etc.?

-JohnW

"Alex Vakulenko" <al...@vakcer.com> wrote in message news:3a661b1e@cnews...
> Hi John,


>
> > I'm trying to understand how your code below solicits the OS to
determine
> if
> > PP9 is running- see ?'s below. I'm still learning the basics, so bare
with
> > me.
> >
> > DECLARE FUNCTION FindWindow LIB "user32" \\
> > (BYVAL Class$,BYVAL Name&) AS LONG ALIAS "FindWindowA"
> >
> > I assume these lines read in the process name into string variable
Class,
> &
> > the process ID into long variable Name. Then what? They go into
> FindWindowA.
> > What's ALIAS do? This is not documented in CS help or in API. How does
one
> > translate hWnd&=FindWindow("PhotoPaint",0) into English?
>

> This is a declaration of Windows API function that finds a window on
system
> given the window class and name. In my example, I look for a window using
> the class name only ("PhotoPaint") and do not use its name (title), that's
> why the second parameter is declared as Long and 0 is used, otherwise you
> need to declare it as string and pass the actual window title. But it's
not
> necessary here.
>
> This function will find even hidden windows. Usually if the application is
> stuck somewhere, it just hides its window but doesn't destroy it. So,
using
> FindWindow is quite reliable way of finding if the application is still
> running. However you need to know the application's main window class name
> to use it. All recent versions of photopaint use the same window class
> name - "PhotoPaint". CorelDRAW uses slightly different class names, such
as
> "CorelDRAW 9.0".


>
> > Here's how I'd like it to work- if the value of the function = 0 then
PP9
> is
> > not running (then STOP), otherwise unload PhotoPaint (with API
equivalent
> > for unload). The other thing I'm trying to do is get this thing to kill
> any
> > onscreen error messages & exit PhotoPaint if any errors do pop up. I'm
> using
> > the ON ERROR RESUME NEXT because ON ERROR GOTO LogErrors allows error
code
> > dialog boxes to pop up. But even with that, the system fails to detect
an
> > error, the script executable stalls, & it doesn't RESUME NEXT.
>

> You need to exit from error handling code using RESUME command like this:
>
> ON ERROR GOTO Handler
> a=1/0 ' Error here: division by zero
> ' ... some other code
>
> Return:
> ' ... some more code here
> STOP
>
> Handler:
> Message "Error"
> RESUME AT Return
>
> Any error that occurs in the error handler will cause the error message.
In
> other word, errors cannot be trapped in the error handler itself.
>
> I'm attaching a script that extensively uses Windows API to find
Photo-Paint
> process and then kill it. This script works the same way as Task Manager
in
> Windows NT/2000, so use it carefully and at your own risk. Killing an
> application will not let it save any of its data...
>
> The script is somewhat complex (technically), so ask if you have any
> questions.
>
> I'm not also sure if this script will work under Win9x because of the
nature
> of API functions it calls.
>
> --
> Alex
>
>
>
>


0 new messages