Re: [ql-users] SCR_XLIM on SMSQ/e
Sat, 04 Dec 2004 15:58:46 -,() Rich Mellor [EMAIL PROTECTED] /wrote: Just a quick question I use the function SCR_XLIM in QWord to read the screen dimensions. It works under SMSQ/e on QPC2 and Aurora, but returns channel not open under Minerva Am I right in thinking that the reason for this is that it defaults to using #1. Under SMSQ/e if #1 is not open when a command attempts to use it by default, then the command is redirected to #0. This seems a fair assumption - but surely it would be better if system commands all used #0 anyway? SCR_XLIM is an SMQ/e only function AFAIK I thought you were using the DISPLAY2_CDE for that Phoebus -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SCR_XLIM on SMSQ/e
On Sat, 04 Dec 2004 11:19:24 -0500, Phoebus Dokos [EMAIL PROTECTED] wrote: Sat, 04 Dec 2004 15:58:46 -,() Rich Mellor [EMAIL PROTECTED] /wrote: Just a quick question I use the function SCR_XLIM in QWord to read the screen dimensions. It works under SMSQ/e on QPC2 and Aurora, but returns channel not open under Minerva Am I right in thinking that the reason for this is that it defaults to using #1. Under SMSQ/e if #1 is not open when a command attempts to use it by default, then the command is redirected to #0. This seems a fair assumption - but surely it would be better if system commands all used #0 anyway? SCR_XLIM is an SMQ/e only function AFAIK I thought you were using the DISPLAY2_CDE for that Yes - you are probably right - but I think that it defaults to #1 in both cases Never mind - have just opened #1 within the program to overcome this. Detection of high colour drivers is more of a problem though - see other email -- Rich Mellor RWAP Services 26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ http://www.rwapservices.co.uk/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SCR_XLIM on SMSQ/e
Yes - you are probably right - but I think that it defaults to #1 in both cases Never mind - have just opened #1 within the program to overcome this. Detection of high colour drivers is more of a problem though - see other email Most resolution checking extensions using iop.flim require an open window channel to return maximum window size. Some such as the SMSQE ones implicitly open a channel, so it seems to the user that it doesn't newed one. DISPLAY_CDE extensions don't have a default channel, you must give them the lowest valid CON channel number. It doesn't have to be a big window though, just a little 8x8 window (some extensions will work with minimum 2x1 window, never tested display_cde on that). The latest display_cde has extensions for detecting GD2 and a few other bits and pieces. I thinkit's on my website, if not, I can email you a copy. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SCR_XLIM on SMSQ/e
Sat, 04 Dec 2004 19:07:11 -,() Rich Mellor [EMAIL PROTECTED] /wrote: On Sat, 4 Dec 2004 18:03:18 -, Dilwyn Jones [EMAIL PROTECTED] wrote: Yes - you are probably right - but I think that it defaults to #1 in both cases Never mind - have just opened #1 within the program to overcome this. Detection of high colour drivers is more of a problem though - see other email Most resolution checking extensions using iop.flim require an open window channel to return maximum window size. Some such as the SMSQE ones implicitly open a channel, so it seems to the user that it doesn't newed one. DISPLAY_CDE extensions don't have a default channel, you must give them the lowest valid CON channel number. It doesn't have to be a big window though, just a little 8x8 window (some extensions will work with minimum 2x1 window, never tested display_cde on that). OK - of course I should have implicitly specified a channel number !! Silly me. The latest display_cde has extensions for detecting GD2 and a few other bits and pieces. I thinkit's on my website, if not, I can email you a copy. Just had a look - your GD2 code looks very similar to mine (can't remember if I sent you the code or vice versa). Anyway, it has the same problem (?) in that it will always return a value of 1 (indicating GD2 is present) whenever the current WMAN / PTR_GEN is present, even if its hardware that doesn't support the GD2 drivers (or the GD2 drivers haven't been written, such as Minerva on an Aurora machine). Rich, the code was working fine... and the Aurora version (I still have) still works fine on my Aurora under both Minerva and SMSQ/e Did you change anything? Phoebus -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SCR_XLIM on SMSQ/e
On Sat, 04 Dec 2004 14:41:20 -0500, Phoebus Dokos [EMAIL PROTECTED] wrote: Rich, the code was working fine... and the Aurora version (I still have) still works fine on my Aurora under both Minerva and SMSQ/e Did you change anything? Phoebus Nope - this seems to be linked to the version of ptr_gen and wman that you are using I presume that I can use the latest version on Minerva hmm not tried to run a program under them though... (had to reformat that hard disk as well - drat !!) -- Rich Mellor RWAP Services 26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ http://www.rwapservices.co.uk/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SCR_XLIM on SMSQ/e
On Sat, 4 Dec 2004 19:47:58 -, Dilwyn Jones [EMAIL PROTECTED] wrote: Just had a look - your GD2 code looks very similar to mine (can't remember if I sent you the code or vice versa). Anyway, it has the same problem (?) in that it will always return a value of 1 (indicating GD2 is present) whenever the current WMAN / PTR_GEN is present, even if its hardware that doesn't support the GD2 drivers (or the GD2 drivers haven't been written, such as Minerva on an Aurora machine). You and Marcel told me how to detect GD2. If the OS/WMAN/Whatever supports GD2 it will return GD2 present code no matter what colours. It only detects a GD2-capable OS, you could probably go by mode number after checking for GD2. I think the code needs to be updated then to try and maybe set a high colour mode (but which one cos that depends on the hardware !!) Problem is that WMAN is reporting that it supports GD2 - its just the fact that the drivers for the o/s don't exist Where's Jochen and Marcel when you need them !! -- Rich Mellor RWAP Services 26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ http://www.rwapservices.co.uk/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SCR_XLIM on SMSQ/e
I actually use a 1x1 window at position 0x0 for this. Since I don't normally do anything else with this but use it for a dummy channel for screen size detection, it works great. One note of caution, if you do one this small, make sure you do not have borders set to any size other than 0. It seems that the opw_con call go ahead and attempt to setup a window even if there is not enough room for borders. I was getting away with this until the other day when it starting locking things up. Seems like the error trapping in opw_con isn't quite smart enough to check for stupid code like what I tried to do :) jim On Dec 4, 2004, at 10:03 AM, Dilwyn Jones wrote: Yes - you are probably right - but I think that it defaults to #1 in both cases Never mind - have just opened #1 within the program to overcome this. Detection of high colour drivers is more of a problem though - see other email Most resolution checking extensions using iop.flim require an open window channel to return maximum window size. Some such as the SMSQE ones implicitly open a channel, so it seems to the user that it doesn't newed one. DISPLAY_CDE extensions don't have a default channel, you must give them the lowest valid CON channel number. It doesn't have to be a big window though, just a little 8x8 window (some extensions will work with minimum 2x1 window, never tested display_cde on that). The latest display_cde has extensions for detecting GD2 and a few other bits and pieces. I thinkit's on my website, if not, I can email you a copy. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SCR_XLIM on SMSQ/e
James Hunkins writes: I actually use a 1x1 window at position 0x0 for this. Since I don't normally do anything else with this but use it for a dummy channel for screen size detection, it works great. If all you want is a window channel - but no window - that doesnt affect anything else on screen, then why not go the whole hog? con_0x0a0x0 is fine in SMSQ/E (except for one or two older versions when this feature was broken). If you want to be compatible with Qdos/Minerva con_2x1a0x0 is the minimum. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
