On 8 Dec 2003 at 16:36, [EMAIL PROTECTED] wrote:
> Umpf, and how do you test for that? What happens if the user unsuspends the
> job
> whilst the screen is still too small?
> The unsuspend routine could surely check the screen dimensions and refuse to
> unsuspend the job if the screen is too small...
And the user wouldn't be happy.
(...)> > I have made it configurable in QWord (similar to Launchpad) as to whether
> it
> > can alter the screens resolution and colour depth,
Ah, great, then!
(...)
> Job 0, the "mother of all SBasics" isn't killed off. I don't think it can be
> killed at all.
> The easiest way around your problem is to set up a hotkey
> eg ert hot_wake ('b','sbasic'). This will call up a new sbasic, with the
> standard windows,
> whenever there is none there yet..
> Hmm - very odd - I wonder why if SBASIC is set to OUTLN #0,512,256,0,0 and I
> execute QWord (which resets the screen to 640x480), it is fine when I switch
> to SBASIC (or quit QWord). - Remember that QWord resets the original screen
> dimensions when Quit. However, if I set SBASIC to OUTLN #0,800,600,0,0 and then
> run QWord, on quitting QWord, the screen dimensions are reset to 800x600, but
> there is no cursor available to #0 - in fact, QPC just hangs !!
Not here, it doesn't.
my disp_size is 1024,768
ert hot_wake ('B','')
ert hot_wake ('b',sbasic')
ALT +B -> job 0
DISP_size 800,600
job 0 seems to disappear.
alt +b get a new sbasic, type disp_size 1024,768
alt + B brings back job 0 with t working cursor in channel#�0
(ok, sometimes it's windows aren't reset correctly
>
(...)
> Not too sure - I was hoping for some input from TT. QTYP uses SMS.LIOD to
> link the new device driver and I am storing the address of the link to use for
> the pointer to remove the device with SMS.RIOD. Not actually tested this yet.
It should work...
> The idea is to avoid a boot program altogether, so that people who have not
> installed QTYP on their system as a default, do not have to remember to run a
> BOOT program before executing QWord. Surely that is the main reason for
> linking in extension toolkits when compiling a program !
Indeed it is.
I do suggest, however, that a device driver as such isn't a toolkit, but a system
extension.
Alternative : why not test for the presence of qtyp before re-installing it (if that is
possible at all).
(....)
> QWord can be configured to use the existing screen
> resolution and colour depth (though at present does not support mode 4 or mode 8).
> However, it does mean that if the resolution is smaller than 640x480 on QPC,
> it will not run (reports an error), and if the resolution is greater, then the
> tiles appear smaller on screen (and harder to read).
Yes, this seems indeed the way to go!
> Feedback from users suggests that they would rather QWord be configurable to
> set the screen accordingly so that it appears as large as possible.
Fair enough. I personally wouldn't want that...
(...)
> No - I would want the job to be able to realise that it had lost focus so
> that it could then reset the colour depth and resolution, or maybe do something
> in the background instead (such as stop writing to the screen). The only way
> it can do this at the moment is to have a small window open on the screen that
> it attempts to PRINT to and use error trapping to take alternative action when
> focus is lost (such as not output data). However, this is not always apt !!
If Qword uses the PE, then there is a way to find out if it has lost focus or not.
Read the pointer with a timeout and check the returned pointer position
(e.g. if using QPTR's RD_PTRT, the xrel,yrel parameters will return -1 if the pointer
is
outside the job's window).
> I accept any criticism - postive or otherwise
Perhaps the above was less "otherwise"
Wolfgang
