🚀 go-pugleaf

In article <9746@cup.portal.com> Sullivan@cup.portal.com writes:
>>>>
>>>>I would like to see the contents of one of my windows scroll continouously
>>>>as I slide a prop gadget up and down, rather than just get one change
>>>>when I finish let go of the select button.  Preferences and Manx's SDB
>>>
>>>Sounds like your gadgets are changing the screen (as well they should) but
>>>since Intuition now has a lock on the front bitmap (to animate the gadget) 
>>>nothing else in the window can update.
>>
>>  more untruths about Intuition and gadgets deleted....
>>
>>Intuition does not keep any lock on the window (or any of it's parts)
>>for long periods of time like that.  The problem is that you aren't
>>getting the messages when you expect them.  You must not have your
>>window or gadget set up properly.
>>
>When in doubt experiment.  Intuition does indeed keep locks on windows
>for long periods of time like that.  (Although it doesn't in the case
>of a slider bar.  That one I hadn't experimented with.)  The drag and
>size gadgets both lock the entire window which they are in (an admittedly
>reasonable course of action. Although one could unlock periodically for
>a moment and sleep, to allow other processes to update their windows.  
>Right clicking also locks the front window if pull down menus have been
>defined (also for obvious reasons.)

For moving and resizing of windows, as well as pulling down menus,
Intuition locks the layers of ALL the windows within a given screen.
It must do this to stop other rendering from happening.  But as you
mentioned not for sliding gadgets.

Had the original poster gone straight to the screen's bit map to do the
gadget simulation (rendering and such), they would have bypassed all the
layers protection, and possibly trashed other windows (or menus) displays.

The kinds of things you suggested as possible solutions to the problem
can be used, but should only be used as a last resort.  The people who
designed the Amiga were very far sighted and have built the OS around
multitasking.  We should do the best we can to write software that
works in concert with the facilities they have provided.

>Maybe I'll get around to writing a program that doesn't steal the entire
>machine one of these days.  Not that I don't like the O/S, I just don't
>have a whole lot of use for it in my own programs.

This explains your insight into ways to circumvent the problem.  I guess
your original suggestions were not wrong, just inappropriate for the
the problem at hand.  They were helpful in solving the problem, so this
is good.

                                                Kevin
-- 
UUCP:  kevin@amdahl.uts.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin
DDD:   408-737-5481
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086

[  Any thoughts or opinions which may or may not have been expressed  ]
[  herein are my own.  They are not necessarily those of my employer. ]