[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
