Re: [ql-users] Changing DISP_SIZE under SMSQ/e
[EMAIL PROTECTED] wrote: On 8 Dec 2003 at 5:49, [EMAIL PROTECTED] wrote: (...) Surely if the screen resolution is altered, any jobs which have windows which fall outside the new area should be suspended rather than removed and only reinstated once the screen size is large enough to accomodate their windows.. Umpf, and how do you test for that? What happens if the user unsuspends the job whilst the screen is still too small? I have made it configurable in QWord (similar to Launchpad) as to whether it can alter the screens resolution and colour depth, but this does not help if SuperBASIC is killed off, even after the program resets the screen resolution and colour depth. 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.. I think it cannot be killed but CAN BE replaced (ie from another shell or whatever... at least I think that's what TT said at one point) (or something) Also, if anyone has followed my work on QWord, they will notice that I now need to perform two main tasks if a QWord is QUIT - namely, remove the QTYP device driver and reset the colour depth and screen resolution if necessary. 1- As a general idea, I would think it to be a pretty bad idea to remove a device driver simply because a job no longer needs the device. Surely it is better to load the device driver separately by way of a boot program. Many of us will have it installed anyway. What happens if the driver is there twice? Which one is removed? (BTW - are you sure you're allowed to link the QPYP extensions into your program?). IIRC he is ie the extensions are royalty free. (Of course don't hold me to that but I can assure you that whatever Rich does is 1000% (yes the extra 0 is intended) legal. And even if the extensions weren't freely distributable Rich will always pay royalties... 2- Surely it would be better if your QWord adapted itself to the existing screen resolution colour depth rather than the other way around? Not really. Remember QWord (the same executable) works regardless of the presence of Colour Drivers (ie it runs on Minerva and QDOS Classic). In the latter cases it manually modifies the hardware registers to switch to the colour depth and resolution required. So if QWord was to adapt to the existing screen colour depth, you would only get 4 colour QWord on the Aurora with Minerva or non-colour SMSQ/E ;-) Plus that the whole thing is based around careful measurements that are resolution specific. Unless of course someone wants to implement for just one game scaleable graphics and draw every object on the screen (plus icons, plus letters, 3D effects, shadows etc.) instead of using pre-rendered graphics. They are sure welcome to try ;-) Of course, it cannot do this if the job is killed from outside or loses focus - we really need an event which can be monitored (aka Windows) to allow a program to take certain action when it is killed externally or loses focus. Do you mean that you want to quit the job every time it loses focus? Does this make any sense on a multitasking machine? Again, the major problem is for systems without colour drivers where Q-Word has to hog the system (suspending the scheduler would be a good idea if it weren't for the Audio server ;-) Sorry if I sound rather critical, perhaps I haven't really understood what you meant. Rather the latter :-) Phoebus
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
In a message dated 08/12/2003 15:16:37 GMT Standard Time, [EMAIL PROTECTED] writes: On 8 Dec 2003 at 5:49, [EMAIL PROTECTED] wrote:(...) Surely if the screen resolution is altered, any jobs which have windows which fall outside the new area should be suspended rather than removed and only reinstated once the screen size is large enough to accomodate their windows..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... Sorry - not too well today, so not thinking straight... Not sure if this is possible I have made it configurable in QWord (similar to Launchpad) as to whether it can alter the screens resolution and colour depth, but this does not help if SuperBASIC is killed off, even after the program resets the screen resolution and colour depth.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 hotkeyeg 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 thescreen to 640x480), it is fine when I switch to SBASIC (or quit QWord).- Remember that QWord resets the original screendimensionswhen 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 !! Also, if anyone has followed my work on QWord, they will notice that I now need to perform two main tasks if a QWord is QUIT - namely, remove the QTYP device driver and reset the colour depth and screen resolution if necessary.1-As a general idea, I would think it to be a pretty bad idea to remove a device driver simply because a job no longer needs the device. Surely it is better to load the device driver separately by way of a boot program. Many of us will have it installed anyway. What happens if the driver is there twice? Which one is removed? 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. 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 ! (BTW - are you sure you're allowed to link the QPYP extensions into your program?).2-Surely it would be better if your QWord adapted itself to the existing screen resolution colour depth rather than the other way around? As Phoebus has pointed out - this is nigh impossible with the way that the graphics are designed. 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). Feedback from users suggests that they would rather QWord be configurable to set the screen accordingly so that it appears as large as possible. Of course, it cannot do this if the job is killed from outside or loses focus - we really need an event which can be monitored (aka Windows) to allow a program to take certain action when it is killed externally or loses focus.Do you mean that you want to quit the job every time it loses focus? Does this make any sense on a multitasking machine? 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 !! Sorry if I sound rather critical, perhaps I haven't really understood what you meant. I accept any criticism - postive or otherwise --Rich Mellor RWAP Services35 Chantry Croft, Kinsley, Pontefract, West Yorkshire, WF9 5JHTEL: 01977 610509Visit our website at:URL:http://www.rwapsoftware.co.ukIn need of adventure?URL: http://www.rwapadventures.comStuck with ordinary dial up internet connection ?? Read our review of internet accelerators and broadband at:URL:http://www.rwapservices.co.uk
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
I have made it configurable in QWord (similar to Launchpad) as to whether it can alter the screens resolution and colour depth, but this does not help if SuperBASIC is killed off, even after the program resets the screen resolution and colour depth. I found out the hard way some of the things that can go wrong if a job does something like this, if you know how to do it, even Launchpad can crash itself by doing this, never mind what it can do to other jobs or even to the OS itself with the problems caused by some programs' inability to cope with the situation. I'm glad I was persuaded to alter the way Launchpad behaves, it makes it that much more flexible even though it was a bit more of a chore to make it adapt itself to whatever it found itself running in. -- Dilwyn Jones
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
On 8 Dec 2003 at 12:44, Phoebus Dokos wrote: I think it cannot be killed but CAN BE replaced (ie from another shell or whatever... at least I think that's what TT said at one point) (or something) ? It's a moot point here since that is not what is happening. (...) IIRC he is ie the extensions are royalty free. (Of course don't hold me to that but I can assure you that whatever Rich does is 1000% (yes the extra 0 is intended) legal. I don't intend at all to question his honesty. I just didn't know that you're allowed to do that. (...) 2- Surely it would be better if your QWord adapted itself to the existing screen resolution colour depth rather than the other way around? Not really. Remember QWord (the same executable) works regardless of the presence of Colour Drivers (ie it runs on Minerva and QDOS Classic). In the latter cases it manually modifies the hardware registers to switch to the colour depth and resolution required. So if QWord was to adapt to the existing screen colour depth, you would only get 4 colour QWord on the Aurora with Minerva or non-colour SMSQ/E ;-) I understand (now). Still, instead of automatically chaning the screen resoultion colour depth, At LEAST make it configurable, i.e. 'Do you want this program to change colour depth resolution automatically Yes/no. If not, and if it doesn't run on a system already having higher colour, then don't switch. Plus that the whole thing is based around careful measurements that are resolution specific. Does that mean that wen I run in a higer resolution, its doesn't change the screen? Unless of course someone wants to implement for just one game scaleable graphics and draw every object on the screen (plus icons, plus letters, 3D effects, shadows etc.) instead of using pre-rendered graphics. They are sure welcome to try ;-) Prowess? (...) Wolfgang
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
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