Re: [ql-users] locking a window?
James Hunkins writes: Unfortunately no, won't be able to get over there for this. But Roy and Jochen will both have updated copies that I hope they will be showing off. I suspect that someone could twist Roy's arm to demo it on the big screen. Im ready to be amazed ;) Per ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
The answer is to follow emacs solution and make the menu a seperate executable program. The problem you are complaining about is in built into the pointer environment. All subwindows have to be within the main window whether you like it or not!. Of course you could reprogram the pointer environment so that this did not happen. - Original Message - From: James Hunkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 01, 2004 11:19 AM Subject: Re: [ql-users] locking a window? I had considered that but things like dropdown menus and error messages should have the original window left open so that you can have a reference. Not to mention, with folders, I would not like a full folder closing every time I wanted to run do a change to it or pick a sub-option. For somethings your suggestion may work but I am afraid not for the desktop that I am working on. Cheers, jim On Oct 1, 2004, at 2:37 AM, John Hall wrote: James Hunkins wrote: 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]. A possible alternative approach would be to close/remove the calling program's window(s) before the sub-program is called and then reinstating it/them when the sub-program exits... John ___ 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
Re: [ql-users] locking a window?
In a message dated 02/10/04 23:41:20 GMT Daylight Time, [EMAIL PROTECTED] writes: In my FastFind program (currently still a sad misnomer) I use the Qmenu File_select utility as an external program to avoid that utility determining the size and layout of my program. It is, afterall, only incidental to it. I think that works well. The file_select utility is included in the package (not Qmenu, though) complete with instructions on how to use it in your own programs. Id encourage others to use it or make their own version, or package other utilities in a similar way, perhaps combined with some of the techniques discussed under this thread. I wanted to use Qmenu to pick a file in a program which had small windows (which I certainly prefer to enormous ones which cover everything up). I also wanted to have Qmenu taking the whole screen because it is much better if possible to have the whole directory displayed rather than having to scroll through it. Since I did not want Qmenu to be a separate job (as for example with emacs) I had to solve the problem of subsidiary windows being inside the main one (and a good idea too!). What I did was to define the main window as variable up to the complete size of whatever screen it was on. I only used that large size when I wanted Qmenu to appear. When the file had been chosen I caused the main window to revert to its usual small size. George ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
- Original Message - From: P Witte Subject: Re: [ql-users] locking a window? Looking very much forward to experiencing QDT in the flesh. Is it likely to be available at a show near me sometime soon? Are you at QL2004? I am hoping Roy will give a demonstration in glorious technicolour on the big screen. Best Wishes, Geoff http://members.lycos.co.uk/geoffwicks/ql2004.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
Unfortunately no, won't be able to get over there for this. But Roy and Jochen will both have updated copies that I hope they will be showing off. I suspect that someone could twist Roy's arm to demo it on the big screen. jim On Oct 3, 2004, at 1:17 AM, gwicks wrote: - Original Message - From: P Witte Subject: Re: [ql-users] locking a window? Looking very much forward to experiencing QDT in the flesh. Is it likely to be available at a show near me sometime soon? Are you at QL2004? I am hoping Roy will give a demonstration in glorious technicolour on the big screen. Best Wishes, Geoff http://members.lycos.co.uk/geoffwicks/ql2004.htm ___ 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?
Hi Wolfgang, On Oct 1, 2004, at 3:50 AM, Wolfgang Lenerz wrote: Just for a futher clarification - do I understand you correctly, Jim, that you want the following: exec a program(program B) from another one (program A), and have that other one(B) always stay on top of the first one (A).? Exactly. Like, for example, use the QPAC2 files menu to launch an application, and make sure that the window thereof is never covered by QPAC2's files menu later on? Yes. But you might take a look at the email I just sent to Jerome here - it gives a couple of good examples where I need this behavior. jim ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
More good stuff.
Holding onto your stuff here and made some notes for myself. Moving
onto my next QDT piece since I am trying to get an update ready for the
upcoming show and every minute right now seems to count. Staying with
the behavior I last described (as per your previous suggestion - works
as you advertised) but what you propose here points me to a way that I
think I can tune it the rest of the way. Want to think about the side
affects first though (got to love the creativity of software users :)
).
Will place with this a bit later.
Cheers,
jim
On Oct 1, 2004, at 5:00 AM, P Witte wrote:
James Hunkins writes:
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.
Well, you asked for it ;)
Here is a more developed version of the tester I posted previously. It
works
slightly differently in that you have to DO the calling program to
re-pick
the called program to the top, but you can fmodify this behaviour using
various tests and fiddling the termination vector.
Requires ptrmen_cde from EasyPtr to be LRESRed (included with my Msprv,
available on my website
http://knoware.mysite.freeserve.com/index.html)
In place of FEP('Files') use your own program, eg id =
FEX(pathFred_exe).
100 OUTL
110 DIM pr%(16): REMark Pointer Record
120 tv% = 1: REMark Termination vector
130 id = FEP(Files)
140 REPeat
150 RDPT tv%
160 PVAL pr%: REMark Read last event
170 IF pr%(5) = 2 OR pr%(7) = 61 THEN
180 REMark On DO or Wake, ..
190 IF JobLives(id) THEN
200REMark pick to top
210PTOP id
212REMark Or PTOP id \ (ie Pick and Wake)
220 ELSE
230REMark Resume normal services
240EXIT
250 END IF
260 END IF
270 END REPeat
280 :
290 DEFine FuNction JobLives(jid)
300 LOCal nj, n
310 IF jid = 0: RETurn 1
320 REPeat nj
330 n = NXJOB(n, 0)
340 IF n = 0 OR n = jid: EXIT nj
350 END REPeat nj
360 RETurn n
370 END DEFine JobLives
380 :
Of course, this is only a sketch. Special conditions may apply (eg Job
0),
and you may want to develop different versions for different cases. My
point
is, you can - by a lot of hard work - usually emulate, to some degree,
the
effect you want to achieve. Far from satisfactory (and certainly not
fool
proof), but its available now! and better than nothing.
Per
___
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?
Anyone have any ideas of how I can lock a window so that it can't be picked to the top under SMSQ/E if the mouse clicks on a visible part of it? It sounds like there might not be an official way to do this but creative ways are always entertaining. QDT often calls other programs which run in separate windows. The calling window is locked to the degree where it is kind of in standby and will not accept any user input. But if you accidentally click on the original window, it currently pops to the top and may accidentally cover the window that is accepting input. Any suggestions will be more than welcome. Jim, When writing Launchpad I faced a similar problem when programs from the Accessories menu were run. In the end I decided it was a bit of a non-starter to lock out Launchpad while the accessories were running, as some people might want to be able to access Launchpad itself (e.g. to change device settings or start another program) while the accessory was running, so I ignored this. To be honest, I don't think it's a wise thing to do anyway - you are in effect killing multitasking or task switching by doing this. Presumably, what you want to do is roughly equivalent to EXEC_W or EW from SuperBASIC, where the calling program is locked out, but with QDT being the equivalent in this case. My only experience of anything vaguely like this was trying to write a Wallpaper (background image) program. The closest I got to solving the problem of an unpickable window was (1) don't use CON channels, just use a SCR for display (or even better, close all channels if the program didn't need to display anything). (2) Have a look at Carlo Delhez's wallpaper program, where IIRC he set up either an unpickable window for image display or a window which was always at the ottom of the pile of jobs. -- Dilwyn Jones ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
James Hunkins writes: Staying with the behavior I last described (as per your previous suggestion - works as you advertised) but what you propose here points me to a way that I think I can tune it the rest of the way. Want to think about the side affects first though .. Well, thats what it is all about - brainstorming. Equally valuable if it produces ideas on how not to do something as the reverse. Looking very much forward to experiencing QDT in the flesh. Is it likely to be available at a show near me sometime soon? Per ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
Bury me at the deepest level [ just on top of the desktop background if any ] would be very nice for QDT. Most modern desktop put their object icons directly onto the desktop and most windows sit on top of them by default. This would allow me to place the icons onto literally the desktop and have an option for a user to pick them all to the top (if he is trying to find one - useful since we don't have a way to hide all windows (or do we - another option?) or put them back down. Cheers, jim On Oct 1, 2004, at 12:10 AM, Jérôme_Grimbert wrote: 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). A long time ago, when background was not available at the system level, one way to do it was to have a full-screen application which always picked another to the top... due to the lack of 'Burry me to the deepest level' system call. Maybe what some need is some additional system calls: - Burry me at the deepest level (opposite of current 'bring me to top') (but to keep things clean and safe, should work only for current job, not for another, as Marcel noted, that would be a bad thing to do.) - Am I at the deepest level ? - Am I partially covered ? (not fully exposed: aka, I/O would block) - Am I at the top level ? (fully exposed) ___ 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?
I had considered that but things like dropdown menus and error messages should have the original window left open so that you can have a reference. Not to mention, with folders, I would not like a full folder closing every time I wanted to run do a change to it or pick a sub-option. For somethings your suggestion may work but I am afraid not for the desktop that I am working on. Cheers, jim On Oct 1, 2004, at 2:37 AM, John Hall wrote: James Hunkins wrote: 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]. A possible alternative approach would be to close/remove the calling program's window(s) before the sub-program is called and then reinstating it/them when the sub-program exits... John ___ 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: I had considered that but things like dropdown menus and error messages should have the original window left open so that you can have a reference. Not to mention, with folders, I would not like a full folder closing every time I wanted to run do a change to it or pick a sub-option. For somethings your suggestion may work but I am afraid not for the desktop that I am working on. Of two things, one or the other: - if you are considering a subwindow like a dropdown menus, then it should, as a secondary, fit inside the primary. May be the primary is too small to allow that, or your secondary might enjoy some sliding bars to fit ? (or any other trick that would reduce the needed space). Secondary that falls outside of primary are not a good idea (it's impossible so far with PTR, and I believe it's a good thing.) If the secondary need more room than the primary, you have a design problem. (nevertheless, being able to move a secondary might be a good idea, so remember to allow such icon and action in your secondaries). - if the sub-window is an independant application, why do you want to lock down the primary at all ? If the primary is visible, then, as a user, I'm expecting to be able to use it. (Even if the sub-application is running). Do not enter the fascist dialog-mode with a user. Rather than denying it access to a visible locked application, hide the application. If the user cannot see it, he cannot use it! Cheers, jim On Oct 1, 2004, at 2:37 AM, John Hall wrote: James Hunkins wrote: 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]. A possible alternative approach would be to close/remove the calling program's window(s) before the sub-program is called and then reinstating it/them when the sub-program exits... John ___ 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
Re: [ql-users] locking a window?
On 1 Oct 2004 at 12:32, Jérôme Grimbert wrote: J - if the sub-window is an independant application, why do you want to lock down the primary at all ? If the primary is visible, then, as a user, I'm expecting to be able to use it. (Even if the sub-application is running). Do not enter the fascist dialog-mode with a user. Rather than denying it access to a visible locked application, hide the application. If the user cannot see it, he cannot use it! Just for a futher clarification - do I understand you correctly, Jim, that you want the following: exec a program(program B) from another one (program A), and have that other one(B) always stay on top of the first one (A).? Like, for example, use the QPAC2 files menu to launch an application, and make sure that the window thereof is never covered by QPAC2's files menu later on? Wolfgang ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
Marcel Kilgus writes: 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? Not a problem. Try 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). In this case it is justified, imho. Windoze seems to be able to attach the windows of two jobs so that picking one always picks the other (eg when clicking send and receive mail in Lookout (no snide comments please guys!) a progress window pops up and over that the connections dialogue (ie two separate programs). If you bury those two windows and then click on the button for the progress window in the task bar, they both pop up, with the connections dialogue on top.) Thats the effect I was trying to achieve (and I presume Jim too). Per ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
Jérôme Grimbert writes: Maybe what some need is some additional system calls: - Burry me at the deepest level (opposite of current 'bring me to top') (but to keep things clean and safe, should work only for current job, not for another, as Marcel noted, that would be a bad thing to do.) - Am I at the deepest level ? - Am I partially covered ? (not fully exposed: aka, I/O would block) - Am I at the top level ? (fully exposed) Our system is rather primitive in this respect. If thered been a zillion SMSQ/E users Im sure this would have been fixed long ago. It is possible to emulate some (or all?) of the features we have been discussing usng existing means, but of course it would be much better to have all this done for us by simple system calls. However, were not likely to get that, as we seem to be a parsimonous lot, and not prepared to pay a penny for the priviledge. - Am I at the deepest level? - could be done by a small toolkit. Scanning the Pile is well documented. - Am I partially covered (or not)? - Can be ascertained now eg using iop.rdpt with termination vector = 48 - Bury me at the deepest level - would be very difficult to do in a general way, I think, and of doubtful value. It would, however, be great to be able to add icons or buttons to the desktop, as Jim suggests. Would it be difficult to give the Background a channel, but still keep it unpickable? One feature Id be very interested in, and the functionality already exists (in Qpac2), is making a window diasppear from the screen without closing its channels or loosing its information. Thats what the button_sleep job does. Per ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
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
[ql-users] locking a window?
Anyone have any ideas of how I can lock a window so that it can't be picked to the top under SMSQ/E if the mouse clicks on a visible part of it? It sounds like there might not be an official way to do this but creative ways are always entertaining. QDT often calls other programs which run in separate windows. The calling window is locked to the degree where it is kind of in standby and will not accept any user input. But if you accidentally click on the original window, it currently pops to the top and may accidentally cover the window that is accepting input. Any suggestions will be more than welcome. Cheers, jim ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
On 28 Sep 2004 at 10:42, James Hunkins wrote: (...) QDT often calls other programs which run in separate windows. The calling window is locked to the degree where it is kind of in standby and will not accept any user input. But if you accidentally click on the original window, it currently pops to the top and may accidentally cover the window that is accepting input. Any suggestions will be more than welcome. I'm not sure this will help: 1- Have a look at the documentation for IOP.PICK - you can mark a window as unlockable. I'm not sure exactly what this implies, I haven't had time to check yet. 2 -is the calling window still needed? wolfgang www.scp-paulet-lenerz.com ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
James Hunkins writes: Anyone have any ideas of how I can lock a window so that it can't be picked to the top under SMSQ/E if the mouse clicks on a visible part of it? It sounds like there might not be an official way to do this but creative ways are always entertaining. QDT often calls other programs which run in separate windows. The calling window is locked to the degree where it is kind of in standby and will not accept any user input. But if you accidentally click on the original window, it currently pops to the top and may accidentally cover the window that is accepting input. Any suggestions will be more than welcome. Provided Ive understood the situation correctly, ie QDT is the calling job that has accidentally been picked to the top, you can: Execute somejob, getting it's ID (eg FEX / EXF or FEP) read pointer, trapping pointer-in-window (vector 32) if somejob's gone then continue normal QDT operations else re-pick somejob to top of pile endif An EasyPtr program to test the concept goes: 100 OUTL 110 id = FEP(calc) 120 REPeat 130 RDPT#0; 32 140 PTOP id 150 END REPeat You'll see it is impossible to pick the window of the calling job until you quit Calc. HTH Per ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
Wolfgang Lenerz writes: I'm not sure this will help: 1- Have a look at the documentation for IOP.PICK - you can mark a window as unlockable. I'm not sure exactly what this implies, I haven't had time to check yet. Unlockable simply means that any output by the unlockable job will be produced on screen, even if you cover its window, ie it really screws up your display! The only use Ive ever found for this feature is to do post mortems on certain programs that produce an error message and then die before you have time to read what it says. Execute such a program using EXEP filename, u Per ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
