Re: [ql-users] locking a window?
James Hunkins wrote: A very interesting method. So far (after my normal fiddling with C68) this now works if I right click on the window that should stay hidden - I see it flash to the top but the window it has called flashes back on top. And what happens if you move the top application to the side, thus completely exposing the picker and then try to bury the top application under a QD or whatever? Marcel ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
James Hunkins writes: And the winner is (almost, maybe?), Per! Prizes may be sent to my usual address ;) A very interesting method. So far (after my normal fiddling with C68) this now works if I right click on the window that should stay hidden - I see it flash to the top but the window it has called flashes back on top. Left mouse click on the bottom window or picking it through some other mean (probably a don't care case but if someone starts CTR C through windows...) it doesn't yet call the top window back. Probably just the way I am setting up the rdptr piece - investigation is on the way. It sounds to me as if you you are using iop.rptr with the the wrong termination vector. Setting bit #5 will do the trick. Per ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
It turns out that this (so far) only seems to work if the top application is not completely buried by someone else and is directly on top of the calling application. This might be an issue even if my original idea of having the calling application not pickable was used. Marcel, were you thinking of something specific here? Per, I will be playing around with the bits I send to the call as you suggest in a separate email. Simply ran out of steam earlier this morning and still had 'real work' to do :) Cheers, jim On Sep 30, 2004, at 7:11 AM, Marcel Kilgus wrote: James Hunkins wrote: A very interesting method. So far (after my normal fiddling with C68) this now works if I right click on the window that should stay hidden - I see it flash to the top but the window it has called flashes back on top. And what happens if you move the top application to the side, thus completely exposing the picker and then try to bury the top application under a QD or whatever? Marcel ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
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
Re: [ql-users] locking a window?
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
Re: [ql-users] locking a window?
Working now with one not so great but probably acceptable (better than loosing a menu somewhere and being locked out). 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
