Re: [MacPerl] [ANN] Mac::Utils::ProgressBar

[online@mactech.com (Jeff at MacTech)]

In article <mac-perl.E0zf4LP-000208-00@post.mail.demon.net>,
ajf@afco.demon.co.uk (Alan Fry) wrote:

>In message <online-1411981045500001@86-ppp-its.caltech.edu> Jeff Clites 
>writes:
>
>>In article <mac-perl.E0zeiOh-0001ew-00@post.mail.demon.net>,
>>ajf@afco.demon.co.uk (Alan Fry) wrote:
>>
>>>I have experimented on and off with MacPerl 'status' indicators for some
>>>time and have not found one which is secure. Problems (crashes) can occur
>>>if there if there is extensive drawing going on in other MacPerl windows.
>>
>>I might be misunderstanding what you mean, but the "now draw this here"
>>method shouldn't return until the drawing is done. If the port switched at
>>the wrong time you could get a crash but you would likely see some visual
>>indication (junk being drawn in another window) as well.
>
>My apologies, I did not make myself quite clear.
>
>The script involved calculates values for a somewhat pathological function
>and plots the results offscreen. The process takes four or five minutes.
>(The reason about drawing the picture offscreen is simply so that the final
>window updates without the need for recalculation.)
>
>Since nothing can be seen of the offscreen world during this time, the
>script, at intervals, calls a subroutine which sends AE's to PBar to record
>the current state of progress with the calculations.
>
>On its return from the subroutine, the script calls SetGWorld() (the
>offscreen version of SetPort()) and continues with the calculation and
>plotting. This all works without any problems.

I'm pretty sure that the QD globals are on a per-application basis, so you
shouldn't need to re-call SetGWorld after sending your AE to the PBar
application--your app's current port shouldn't be changeable by another
app. (But of course it shouldn't hurt and is always a pretty good idea,
given that "your app" is actually running as part of the MacPerl app, and
_it_ could be erroneously changing the current port out from under you.)

>I suspect (based on profound ignorance of what goes on under the hood) that
>the subroutine returns, and SetGWorld() gets called, *before* QuickDraw has
>actually finished.

I doubt that this is the case. This could only happen if the drawing were
going on in a separate preemptive thread, which is a big no-no anyway. (I
don't think that the current MacPerl is threaded at all, and even if it
were I'm sure Matthias would have known not to run scripts within
preemptive threads, since it would cause havoc with almost anything
Toolbox-related.) I don't think that any of the Toolbox drawing routines
are asynchronous, meaning that none of these Toolbox calls return until
the drawing is done (and which explains why there is no way to check to
see if the toolbox is "currently" drawing--it isn't). 

One thing which is good practice, in order to guard against port-changing
problems from both ends, is to always save off the current port before
drawing, set the port you want, do your drawing, and restore the
previously-set port. If you do some drawing, call another function which
might draw to the screen, and then do some more, it is good to repeat this
procedure before the second drawing session. By always setting the port
before drawing you ensure that it is correct before you draw (of course),
and by restoring it afterward you ensure that you will not cause problems
for another function which is calling you and not being so careful. It
sounds like you might already be doing this, and probably the ProgressBar
module is setting the port before it draws, but you might want to check.

>I would be happy if anyone would be game to play with this script and some
>Perl status-indicating scripts and see if they can shed any light on the
>matter. (BTW the 19th May 1998 versions of the QuickDraw and QDOffscreen
>library files need to be installed first. I can include these with the
>other files.)

I haven't done much (okay, any) Perl programming using the toolbox
modules, but I can take a look--you can email them if you want, or send a
URL.

>>>Incidentally (in the PS to Eric's leter) what is meant by 'indeterminate
>>>state' and why is that wanted?
>>
>>I think this is the "barber pole" progress bar, for those times when you
>>feel like you should have a progress bar but don't have a way to measure
>>the progress.
>
>Oh -- the barber's pole. I've often wondered where that lived. Is it a CDEF
>like the bar or what? Come to that where is the documentation that says the
>ID for the bar CDEF is 80? Eric Albert cleverly sussed it out. I can't find
>it in IM.

The "built-in" progress bar on the Mac is part of Appearance, and the
barber pole is just a state that you set it to (I believe). It is
documented in the Appearance Manager docs, but I don't have the pre-OS 8.5
docs handy. Without Appearance, you have to use a custom CDEF to to a
progress bar (or draw directly). I don't know if you can set these up via
ResEdit, or if you have to use Resourcerer set up Appearance-saavy dialogs
via resources.
-- 
__________________________________________________________________________

Jeff Clites                Online Editor           http://www.MacTech.com/
online@MacTech.com         MacTech Magazine
__________________________________________________________________________

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch