If the top program is still over the calling program, then cursor movement over the calling program gives the expected locked cursor icon. If one clicks on the calling program (either mouse button or space/return keys), the calls the calling program but immediately returns the top program to where it belongs and places the cursor within it.
This is pretty good so far as the cursor won't move too far and the primary use of this is when Roy (and others :) ) 'mis-clicks' from the called program and accidentally hides it behind the calling program - all nice and neat and the cursor movement is small enough to not be too bad on the old brain.
The not so good side affect is say the user moves the called program away to a better spot on the screen, so that the calling program is uncovered. Now just moving the cursor over the calling program pops the top program to the top and [now for the bad part], the cursor pops over to top program. Pretty disconcerting (and definitely against the concept followed throughout the pointer environment), not to mention, with a lot of screen real-estate, you might not see where the cursor went. Looking forward to the emails and phone calls for that.
However, loosing a menu is the worse thing of the two and most users will not be moving a called locking program out from the calling program. So will go ahead with this and make sure that it is included in the readme file, just in case.
That is unless Marcel comes through AGAIN (just the second hint in a couple of hours Marcel :) ). I wonder if it would be to obvious if I was to tell him how brilliant he is (again). Hasn't worked before but you never know.
Like I said, not perfect but it does work and should be fine for the vast majority of cases.
By the way, this mechanism is only being used when a particular sub-program is called and the calling window needs to be locked. Examples programs that need windows larger than the caller's window [drop-down menus, File and List selects, etc] and programs that will be directly changing something in the calling program so we would want to lock the calling program out [IconDraw for notebooks which will change the notebook's icon, Add Objects for folders, and notebooks for folders or Icons].
Pretty cool stuff.
Thanks again for the help once again. Proceeding onto adding this through QDT (happy now Roy?).
Cheers all, jim
On Sep 30, 2004, at 9:46 PM, James Hunkins wrote:
Does this mean you are offering to enhance SMSQ/E one more time so that I can lock down a window properly [hint - hint]? I would be more than happy to abandon this approach (sorry Per) for a simple lock down mechanism.
On the other hand, the idea behind the workaround is that it would only pick the window back to the top if the calling window was physically picked (IE: mouse clicked onto). Or at least that would be my intention. I definitely don't want something just happening repeatedly and using up horsepower. Note that this is possible due to the newer pointer call that lets us pick what vector it responds to (I hope).
Cheers, jim
On Sep 30, 2004, at 9:27 AM, Marcel Kilgus wrote:
James Hunkins wrote:Marcel, were you thinking of something specific here?
Just that constantly picking a windows is a "bad thing to do". Perhaps I want to work with another application on top that happens to burry it?
That's also why programmatically bringing another application to the foreground is impossible since Windows 2000 (instead the task bar button starts to flash).
Marcel
_______________________________________________ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
_______________________________________________ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
_______________________________________________ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
