Is this alopecia?

When a DLOG (invariably dd nowadays) closes or moves there is no way I will accept leaving an exposed erased area. I use a variety of methods for preventing or correcting the problem, but sometimes closing or hiding DLOG 1 before opening No 2 seems to be the only answer, which does not strike me as being a “real” answer. Amongst the methods I use are:
An update call to the Finder,
A call to the DLOG to redraw, say, one or more icons,
A call to the DLOG to ‘move’ to its current co-ordinates,
Temporarily resizing the lower DLOG to, say, [0,0,0,0], or moving it off screen,
Temporarily “hiding” the lower DLOG,
Using Akua ‘pause for 1 with seconds timing’.
Temporarily collapsing the lower DLOG.
In some cases one of these works perfectly, but in a different context not at all. To my mind most of this is ad hoc “working around” rather than good scripting. Is there something I haven’t thought of? The semi-erased item is sometimes a creation of mine in the same or another concurrently running applet, sometimes a Finder item, sometimes an item belonging to another app. I have a suspicion (unproven as yet because I have done no work on it) that the problem is exacerbated by, maybe even due to, a DLOG being in a ‘dd interact with user’ loop. Could it be that the CPU usage engendered by the loop leaves too little over for external cosmetics? If this proves to be the case has anyone a suggestion as to what to try putting inside the loop? As I write this the idea comes to mind of trying Akua’s ‘pause for…’, but the speed penalty of that could be unacceptable.
I would appreciate not getting speculative answers from those having a guess. I would very much like to hear from anyone who has successfully dealt with the problem - especially in a way I haven"t mentioned. The ideal perhaps would be a generic solution for all cases. Pie in the sky? or possible?

Thank you, Eelco. I was hoping for interesting ways to control CPU allocation but, never mind - it does no harm to be reminded of basics.
BTW I messed about a bit with adding “pause for…” inside “interact with user” loops. Even a 1 tick pause makes a difference (obviously takes much longer than 1 tick for the execution of the command), but no real joy - some refreshes happen or happen faster but at too great a cost, e.g. losing mouse-clicks. Back to head scratching - which leads neatly into the question…
Does anyone else want to share their pet cure for baldness?

Eelco, what sort of things had you in mind when you wrote “make your
: scripting
: the most demanding app in the system”?
Andreas ,
Following earlier comments, there is no true mechanism in OS9 to assign processing time to scripts, so only a few rough guidelines apply:

  1. Give applets (self-running scripts) and your scripting app
    (script editor, Script Debugger, Smile) lots of memory. 1. Minimalize the number of running apps/extensions 2. Eventually quit the Finder (only when time is REALLY critical,
    as this is mostly not very feasible or practical however) 3. Better: try to avoid calls to the Finder that aren’t necessary.
    Example: (info for file xxx) calls take relatively long
    (and in my case even crash Finder 9.2.)2 compared to
    MT get info among other OSAX’s.
    Other example:
    tell app “Finder” to (get name of file xxxxx) takes longer than
    the 4 line routine:
    set oldDelims to AppleScript’s text item delimiters
    set AppleScript’s text item delimiters to “:”
    set myName to last text item of pathtome
    set AppleScript’s text item delimiters to oldDelims
    – pathname in the form “Mac HD:My docs:My file”
  2. With time REALLY critical, you may limit user feedback such as
    progress indicators, sounds, speech etc.
    However: there is little to gain here - and this kind of feedback
    indeed reduces irritating level. 5. Reduce the number of debug routines (I use a lot of checking routines
    and speaking to read out values and constant to debug my code, it
    takes some disciples to remove all that stuff) 6. Use “timeout / end timeout” (or: “ignoring application responses/end
    ignoring”) when issuing commands to external apps,
    servers, networks. At the expense of: less reliable results → so more
    complex error condition scripting.