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
