[Ql-Users] QDOS/SMS Questions
There is a system variable for the current keyboard queue. I assume that as there is only one, that it refers to the currently executing job? So If SuperBasic is executing, it will refer to the QDOS channel ID for Channel #0 in SuperBasic. Ok, given that the above is true, I assume that when the scheduler reschedules a task, then the above system variable will be loaded with the keyboard queue for the (now) current job? If so, then how on earth does QDOS/SMS manage to find the keyboard queue for the job that the scheduler has just switched to? I've looked in the QDOS Manual and I can find no way from a Job Id to a channel ID for the keyboard input or to the keyboard queue for that job. Does anyone know how QDOS/SMS does it? I have a reason for asking. At some point soon(ish) in QL Today, I want to do an article on the Pointer Environment and I have a utility in mind where I can pointerise a non-pointer application by wrapping it in a PE application and attempting to grab the keyboard/screen channels. It might not be possible, but I'd love to be able to, say, wrap George's GWASL in a pointer environment application and have it (the PE) allow me to select a filename (using QMENU perhaps) and pass that to GWASL for assembly, then grab the result of the assembly, and on no errors, run the SYM_BIN utility on the generated symbol file. A bit like make, but interactive. GWASL opens a con_ channel and accepts keyboard input from that. I'd like to intercept that channel, and feed it input from the PE wrapper. I remember (or do I?) a long time back, there was a similar sort of utility that enabled Quill to have certain commands fed to it from a file, I think it was run from SuperBasic. I'm sure I looked at the code and it did stuff with the keyboard queue, and at a certain point, started feeding F3 command sequences to the queue. I'd like to do something similar. Any ideas? Am I barking mad again? ;-) I suppose the ultimate outcome would be something like an IDE where you could choose an editor, assembler, linker etc as desired and have the PE wrapper pass commands to the appropriate utility, all of which would hopefully display their output in one or more of the wrapper's application windows, perhaps? Too ambitious? Cheers, Norm. PS. My Thunderbird spell chequer wants to change GWASL to HOGWASH! I was most offended. I put it right and added GWASL to my dictionary. Hogwash indeed! -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QDOS/SMS Questions
Norman Dunbar wrote: Ok, given that the above is true, I assume that when the scheduler reschedules a task, then the above system variable will be loaded with the keyboard queue for the (now) current job? You're already off path here. The queue is not the one of the currently executing job (that would be quite fun to use...) but of the window that is in the foreground, no matter if the job is currently executing or not. The windows are organised in a stack and picking one (by mouse or CTRL+C) switches the keyboard queue to this window. Due to the historic QDOS-PE progression the actual CTRL+C switching mechanism is a bit dirtier than the description here, though. GWASL opens a con_ channel and accepts keyboard input from that. I'd like to intercept that channel, and feed it input from the PE wrapper. Well, all channels have an owner, which is your job-ID. Furthermore, all channels are organised in the channel table, so you can scan for them there. I'm too tired to reflect on the rest of your ideas, sorry ;-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QDOS/SMS Questions
Norman, I'm not sure how far this could help you forward, but it's rather that the channel is related to the job waiting for it than the other way round. The channel table's header has CH_JOBWT - The job that's waiting for input on this channel. That is how the device driver can kick a job back into action once it has data for it. The address of the keyboard input buffer seems to be private to the console channel - There's no variable in the channel table for that. I could even imagine that all console channels share the same keyboard queue - As there can always be only one channel connected to the keyboard there is actually no need for multiple queues, I guess. That is: You need po pick a job into the foreground before you can actually push characters into it - That is how the various toolkit routines doing this seem to work. Regards, Tobias -Original-Nachricht- Von: Norman Dunbar nor...@dunbar-it.co.uk An: ql-us...@q-v-d.com Betreff: [Ql-Users] QDOS/SMS Questions Datum: Mon, 05 Nov 2012 13:25:17 +0100 There is a system variable for the current keyboard queue. I assume that as there is only one, that it refers to the currently executing job? So If SuperBasic is executing, it will refer to the QDOS channel ID for Channel #0 in SuperBasic. Ok, given that the above is true, I assume that when the scheduler reschedules a task, then the above system variable will be loaded with the keyboard queue for the (now) current job? If so, then how on earth does QDOS/SMS manage to find the keyboard queue for the job that the scheduler has just switched to? I've looked in the QDOS Manual and I can find no way from a Job Id to a channel ID for the keyboard input or to the keyboard queue for that job. Does anyone know how QDOS/SMS does it? I have a reason for asking. At some point soon(ish) in QL Today, I want to do an article on the Pointer Environment and I have a utility in mind where I can pointerise a non-pointer application by wrapping it in a PE application and attempting to grab the keyboard/screen channels. It might not be possible, but I'd love to be able to, say, wrap George's GWASL in a pointer environment application and have it (the PE) allow me to select a filename (using QMENU perhaps) and pass that to GWASL for assembly, then grab the result of the assembly, and on no errors, run the SYM_BIN utility on the generated symbol file. A bit like make, but interactive. GWASL opens a con_ channel and accepts keyboard input from that. I'd like to intercept that channel, and feed it input from the PE wrapper. I remember (or do I?) a long time back, there was a similar sort of utility that enabled Quill to have certain commands fed to it from a file, I think it was run from SuperBasic. I'm sure I looked at the code and it did stuff with the keyboard queue, and at a certain point, started feeding F3 command sequences to the queue. I'd like to do something similar. Any ideas? Am I barking mad again? ;-) I suppose the ultimate outcome would be something like an IDE where you could choose an editor, assembler, linker etc as desired and have the PE wrapper pass commands to the appropriate utility, all of which would hopefully display their output in one or more of the wrapper's application windows, perhaps? Too ambitious? Cheers, Norm. PS. My Thunderbird spell chequer wants to change GWASL to HOGWASH! I was most offended. I put it right and added GWASL to my dictionary. Hogwash indeed! -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ 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] QDOS/SMS Questions
tobias.froesc...@t-online.de wrote: The address of the keyboard input buffer seems to be private to the console channel - There's no variable in the channel table for that. I could even imagine that all console channels share the same keyboard queue - As there can always be only one channel connected to the keyboard there is actually no need for multiple queues, I guess. That is: You need po pick a job into the foreground before you can actually push characters into it - That is how the various toolkit routines doing this seem to work. Every CON channel has its own queue (which becomes the active keyboard queue when you pick the channel), located at sd_keyq. I guess one can stuff bytes directly into that and leave the active keyboard queue alone. But I don't really remember the specifics if I ever knew them ;) Cheers, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QDOS/SMS Questions
Afternoon Gents, thanks for the information and pointers. I'll have a rummage in the bowels of QDOS/SMSQ and see what, if anything, I come up with. I get the impression I'll be doing this: * create a job. * activate the job. * wait a bit. * scan the QODS channel table for channels owned by my job. * scan the CON channels looking for the keyboard queue. * stuff it. Or something similar to the above. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QDOS/SMS Questions
Marcel, as a side note: I can find sd_keyq at offset $68 of the Screen Driver Channel Definition Block in the SMSQ/E sources. But nowhere in the documents. Whatever that might mean. Regards, Tobias -Original-Nachricht- Von: Marcel Kilgus ql-us...@mail.kilgus.net An: ql-us...@q-v-d.com Betreff: Re: [Ql-Users] QDOS/SMS Questions Datum: Mon, 05 Nov 2012 15:00:01 +0100 tobias.froesc...@t-online.de wrote: The address of the keyboard input buffer seems to be private to the console channel - There's no variable in the channel table for that. I could even imagine that all console channels share the same keyboard queue - As there can always be only one channel connected to the keyboard there is actually no need for multiple queues, I guess. That is: You need po pick a job into the foreground before you can actually push characters into it - That is how the various toolkit routines doing this seem to work. Every CON channel has its own queue (which becomes the active keyboard queue when you pick the channel), located at sd_keyq. I guess one can stuff bytes directly into that and leave the active keyboard queue alone. But I don't really remember the specifics if I ever knew them ;) Cheers, Marcel ___ 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] QDOS/SMS Questions
Hi Tobias, On 05/11/12 14:59, tobias.froesc...@t-online.de wrote: I can find sd_keyq at offset $68 of the Screen Driver Channel Definition Block in the SMSQ/E sources. But nowhere in the documents. In my docs, updated recently, I see sd_end at that offset in the screen driver channel definition block. For QDOS 1.10 onwards. Interesting. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QDOS/SMS Questions
On 5 Nov 2012, at 12:25, Norman Dunbar wrote: There is a system variable for the current keyboard queue. I assume that as there is only one, that it refers to the currently executing job? So If SuperBasic is executing, it will refer to the QDOS channel ID for Channel #0 in SuperBasic. For QDOS CTRL/C takes you through the cursor winking list. A program without such a cursor was effectively lost. In SMSQ CTRL/C takes you through the list of jobs. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QDOS/SMS Questions
On 5 Nov 2012, at 15:13, Norman Dunbar wrote: On 05/11/12 14:59, tobias.froesc...@t-online.de wrote: I can find sd_keyq at offset $68 of the Screen Driver Channel Definition Block in the SMSQ/E sources. But nowhere in the documents. In my docs, updated recently, I see sd_end at that offset in the screen driver channel definition block. For QDOS 1.10 onwards. The keyboard queue starts at the end of the channel block. For QDOS this is @ $68 for v1.01 onward and $64 for earlier versions. For PE the value is $98 (counting from the start of the extended channel block). The Turbo TK commands COMMAND_LINE and TYPE_IN allow you to push characters into an S*BASIC keyboard queue. The source code for these should show how to put characters into any queue. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
