link@ucunix.san.uc.edu (Virginia Link) (06/14/91)
To: Peter Cherna So are you saying that when I make a call to WindowToFront, all other windows will be considered in the back, even if they are not graphically. Is there any way to bring a window, like a clock window to the front, but not have intuition consider it as having happened. vl
link@ucunix.san.uc.edu (Virginia Link) (06/16/91)
To: Peter Cherna At this time our program puts a clock window up every second if it is not in front already. We do this with WindowToFront(). I think what is happening is when we make that call, all windows on the screen are considered not to be in front. So when I click on the front/back gadget of a window that appears graphically in front, it does not get pushed to the back. If I click a second time, it will still stay in the front since our clock program has put itself back in front again. If I click twice quickly on the window, it goes to the back, since our clock did not get a chance to be put to the front yet. Is there a way to prevent this from happening. Is there a varibale that stores the front window for each screen that I can change back to the window value after I call window to front for the clock window. For example, if window x is in front, could I store window x, call windowtofront for my clock window, say window c, then replace the variable that is keeping track of the front window back with x from c ? By the way, why is calling UpFrontLayer not legal on this screen ? vl
peter@cbmvax.commodore.com (Peter Cherna) (06/18/91)
In article <1991Jun16.164922.15206@ucunix.san.uc.edu> link@ucunix.san.uc.edu (Virginia Link) writes: >Is there a varibale that stores the front window for each screen >that I can change back to the window value after I call window >to front for the clock window. No. The window list in the Screen structure determines the window ordering, and it's read-only. The best thing is to use shift-click on the depth gadget, which forces a window to the back. I would like to add a fix to Intuition that would make non-frontmost fully-exposed windows go to the back, instead of to the front, when you click on their depth gadget. >By the way, why is calling UpFrontLayer not legal on this screen ? Layers is an underlying engine for window-like operations. Intuition owns the screen, and brings each layers operation out in a Window...() form. You must use the Window...() form (WindowToFront(), in this case) to keep Intuition in the loop. It owns the screen, and needs to know what transpires there. >vl Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"
hawk@pnet01.cts.com (John Anderson) (06/19/91)
>>Is there a varibale that stores the front window for each screen >>that I can change back to the window value after I call window >>to front for the clock window. > >No. The window list in the Screen structure determines the window >ordering, and it's read-only. The best thing is to use shift-click >on the depth gadget, which forces a window to the back. I would >like to add a fix to Intuition that would make non-frontmost >fully-exposed windows go to the back, instead of to the front, >when you click on their depth gadget. I made a clock program under KS2.0 that brings itself to the front every 30 seconds. However, if you happen to click and drag the mouse button on workbench just as the clock window brings itself to the front, the mouse freezes. The same thing happens any time you press left mouse button then right mouse button to send a screen to the back. Is this a bug or feature :-)
peter@cbmvax.commodore.com (Peter Cherna) (06/20/91)
In article <1991Jun19.001605.3317@crash.cts.com> hawk@pnet01.cts.com (John Anderson) writes: > I made a clock program under KS2.0 that brings itself to the front >every 30 seconds. However, if you happen to click and drag the mouse button >on workbench just as the clock window brings itself to the front, the mouse >freezes. There is no fully safe way for an application to freeze a shared screen, such as the Workbench screen, while still getting input through Intuition. A deadlock can result. However, Workbench must do this to allow dragging of icons. The technique to use is to set-up a watchdog task that looks for a deadlock and breaks the freeze. So for Workbench, that means if you're dragging icons and some other major event (eg. a new window or a depth-change) comes along, the system deadlocks for about a second, and then Workbench recovers. > The same thing happens any time you press left mouse button then >right mouse button to send a screen to the back. Is this a bug or feature :-) Under early releases of 2.0, Workbench drag selection began as soon as you clicked down in a Workbench window. Under 2.04, you must first move the mouse a small distance before drag-selection begins. That will cure your problem. Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"
Alex_Topic@tvbbs.UUCP (Alex Topic) (06/21/91)
This might not be apart of intuition, but it has something to do with the
OS! I was wondering when is CBM going to add VIRTUAL MEMORY or MEMORY
PROTECTION to the OS? I know they may not bother cause of UNIX haveing all
that already, but it would be nice to see that in Wb2.0! This would be good
for CBM, cuz then when they sell the machines they can list all the
highlights of the OS!
Me and Some friends plan on doing something if CBM doesn`t! Oh
well doesn`t MEMORY PROTECTION slow down the system? I heard that it does,
not sure if that is true..hmm
Oh well just wondering about afew things... later
A.t.