Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.acorn.programmer > #1728 > unrolled thread
| Started by | Gazza <usenet@garethlock.com> |
|---|---|
| First post | 2012-05-22 08:42 -0700 |
| Last post | 2012-06-18 13:26 -0700 |
| Articles | 20 on this page of 49 — 9 participants |
Back to article view | Back to comp.sys.acorn.programmer
Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-22 08:42 -0700
Re: Defining action of CTRL key... Martin Wuerthner <spamtrap@mw-software.com> - 2012-05-22 18:09 +0200
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-22 11:33 -0700
Re: Defining action of CTRL key... Martin Wuerthner <spamtrap@mw-software.com> - 2012-05-22 22:45 +0200
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-22 16:03 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-22 23:42 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-23 16:20 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-05-24 13:59 -0700
Re: Defining action of CTRL key... Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-24 22:51 +0100
Re: Defining action of CTRL key... Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-05-26 16:16 +0200
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-25 07:04 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-05-25 07:48 -0700
Re: Defining action of CTRL key... Steve Drain <steve@kappa.me.uk> - 2012-05-25 16:30 +0100
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-05-27 05:43 -0700
Re: Defining action of CTRL key... Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-05-26 16:08 +0200
Re: Defining action of CTRL key... Harriet Bazley <bazley@feathermail.co.uk> - 2012-06-08 08:55 +0100
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-08 01:16 -0700
Re: Defining action of CTRL key... Martin Wuerthner <spamtrap@mw-software.com> - 2012-05-24 11:07 +0200
Re: Defining action of CTRL key... Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-05-26 16:18 +0200
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-27 02:25 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-05-27 10:00 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-05-27 10:55 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-29 10:30 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-05-29 14:14 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-29 16:32 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-05-29 17:34 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-30 04:06 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-05-30 04:35 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-30 05:40 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-30 10:26 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-05-31 06:56 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-01 05:02 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-01 07:01 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-01 07:54 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-06-02 18:18 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-03 01:02 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-06-06 17:29 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-07 16:37 -0700
Re: Defining action of CTRL key... Steve Drain <steve@kappa.me.uk> - 2012-06-08 12:00 +0100
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-08 09:00 -0700
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-11 16:14 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-06-17 17:12 -0700
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-06-18 13:24 -0700
Re: Defining action of CTRL key... Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-06-16 20:18 +0100
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-17 16:08 -0700
Re: Defining action of CTRL key... Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-06-18 04:45 +0100
Re: Defining action of CTRL key... Gazza <usenet@garethlock.com> - 2012-06-18 14:49 -0700
Re: Defining action of CTRL key... druck <news@druck.org.uk> - 2012-06-18 18:41 +0100
Re: Defining action of CTRL key... jgharston <jgh@arcade.demon.co.uk> - 2012-06-18 13:26 -0700
Page 1 of 3 [1] 2 3 Next page →
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2012-05-22 08:42 -0700 |
| Subject | Defining action of CTRL key... |
| Message-ID | <4802cf78-e210-4afa-acf0-a751668b03bb@hq4g2000vbb.googlegroups.com> |
As most of you know, I've been porting UMoria over to BBC BASIC bit by bit for the last couple of years. I'm now at the point of sorting out the keyboard input code. The game uses the ESCape key and various CTRL combinations to perform actions. I've got the ESCape key to behave using OS_Byte &E5 (229). Is there any way of neutering the CTRL key in a similar fashion so that it sets a bit, rather than performing any other action defined by the VDU drivers? I need to be able to distinguish between uppercase & lowercase as both are used as CTRL combos. I seem to remember a way of doing this on the Beeb, though I can't for the life of me remember what it was. Your help would be much appreciated.
[toc] | [next] | [standalone]
| From | Martin Wuerthner <spamtrap@mw-software.com> |
|---|---|
| Date | 2012-05-22 18:09 +0200 |
| Message-ID | <b22fee9352.martin@bach.planiverse.com> |
| In reply to | #1728 |
In message <4802cf78-e210-4afa-acf0-a751668b03bb@hq4g2000vbb.googlegro
ups.com>
Gazza <usenet@garethlock.com> wrote:
> As most of you know, I've been porting UMoria over to BBC BASIC bit by
> bit for the last couple of years. I'm now at the point of sorting out
> the keyboard input code. The game uses the ESCape key and various CTRL
> combinations to perform actions. I've got the ESCape key to behave
> using OS_Byte &E5 (229). Is there any way of neutering the CTRL key in
> a similar fashion so that it sets a bit, rather than performing any
> other action defined by the VDU drivers?
In contrast to Esc, the Ctrl key does not have any associated action,
so there is no need to suppress it. You can enquire about the state of
the Ctrl key at any time using OS_Byte 121. Whatever code you use to
accept keyboard input might do specific things when it sees Ctrl
keypresses, so in order to answer your question you need to tell us
how you accept and interpret keyboard input in your program.
OS_ReadLine, for instance, interprets certain Ctrl keypresses.
--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2012-05-22 11:33 -0700 |
| Message-ID | <125e67a9-7565-4a7b-8439-53c951ff140b@l17g2000vbj.googlegroups.com> |
| In reply to | #1729 |
On May 22, 5:09 pm, Martin Wuerthner <spamt...@mw-software.com> wrote: > In message <4802cf78-e210-4afa-acf0-a751668b0...@hq4g2000vbb.googlegro > ups.com> > Gazza <use...@garethlock.com> wrote: > > > As most of you know, I've been porting UMoria over to BBC BASIC bit by > > bit for the last couple of years. I'm now at the point of sorting out > > the keyboard input code. The game uses the ESCape key and various CTRL > > combinations to perform actions. I've got the ESCape key to behave > > using OS_Byte &E5 (229). Is there any way of neutering the CTRL key in > > a similar fashion so that it sets a bit, rather than performing any > > other action defined by the VDU drivers? > > In contrast to Esc, the Ctrl key does not have any associated action, > so there is no need to suppress it. You can enquire about the state of > the Ctrl key at any time using OS_Byte 121. Whatever code you use to > accept keyboard input might do specific things when it sees Ctrl > keypresses, so in order to answer your question you need to tell us > how you accept and interpret keyboard input in your program. > OS_ReadLine, for instance, interprets certain Ctrl keypresses. > > -- > Martin > --------------------------------------------------------------------- > Martin Wuerthner MW Software http://www.mw-software.com/ > RISC OS Software for Design, Printing and Publishing > --------------------------------------------------------------------- Well... I was running a test program that just read from the keyboard and displayed both the ASCII codes and the character/string representation on the screen. The idea being I could trap CTRL+<key> and display the character on the screen, manually prefixed with "^" if it was part of a CTRL combo. However, I was stumbling across special cases such as CTRL+U and others which of course do funny things with the VDU drivers. What I want to do is to intercept this set a flag if CTRL was pressed and return the ASCII code of just the character pressed. I'm using GET to return ASCII codes with OS_Byte 229 set to a non-zero value to supress Escape.
[toc] | [prev] | [next] | [standalone]
| From | Martin Wuerthner <spamtrap@mw-software.com> |
|---|---|
| Date | 2012-05-22 22:45 +0200 |
| Message-ID | <396e079452.martin@bach.planiverse.com> |
| In reply to | #1730 |
In message <125e67a9-7565-4a7b-8439-53c951ff140b@l17g2000vbj.googlegro
ups.com>
Gazza <usenet@garethlock.com> wrote:
> On May 22, 5:09 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
>> In message <4802cf78-e210-4afa-acf0-a751668b0...@hq4g2000vbb.googlegro
>> ups.com>
>> Gazza <use...@garethlock.com> wrote:
>>
>>> [...] Is there any way of neutering the CTRL key in
>>> a similar fashion so that it sets a bit, rather than performing any
>>> other action defined by the VDU drivers?
>>
>> In contrast to Esc, the Ctrl key does not have any associated action,
>> so there is no need to suppress it. You can enquire about the state of
>> the Ctrl key at any time using OS_Byte 121. Whatever code you use to
>> accept keyboard input might do specific things when it sees Ctrl
>> keypresses, so in order to answer your question you need to tell us
>> how you accept and interpret keyboard input in your program.
>> OS_ReadLine, for instance, interprets certain Ctrl keypresses.
> Well... I was running a test program that just read from the keyboard
> and displayed both the ASCII codes and the character/string
> representation on the screen. The idea being I could trap CTRL+<key>
> and display the character on the screen, manually prefixed with "^" if
> it was part of a CTRL combo. However, I was stumbling across special
> cases such as CTRL+U and others which of course do funny things with
> the VDU drivers.
Of course. Simply do not display characters with a code < 32 to the
screen.
> What I want to do is to intercept this set a flag if
> CTRL was pressed and return the ASCII code of just the character
> pressed. I'm using GET to return ASCII codes with OS_Byte 229 set to a
> non-zero value to supress Escape.
There is no need to do anything special. This is just a question of
interpreting the values you get. If you look at the returned codes it
should not be difficult to work out that Ctrl+A is 1, Ctrl+B is 2,
etc. If you want Ctrl+Shift as well, you need to test the shift key
explicitly.
--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2012-05-22 16:03 -0700 |
| Message-ID | <7e0d1b1e-8a6b-442d-bf39-1804a80ac511@3g2000vbx.googlegroups.com> |
| In reply to | #1731 |
On May 22, 9:45 pm, Martin Wuerthner <spamt...@mw-software.com> wrote: > In message <125e67a9-7565-4a7b-8439-53c951ff1...@l17g2000vbj.googlegro > ups.com> > Gazza <use...@garethlock.com> wrote: > > > > > > > On May 22, 5:09 pm, Martin Wuerthner <spamt...@mw-software.com> wrote: > >> In message <4802cf78-e210-4afa-acf0-a751668b0...@hq4g2000vbb.googlegro > >> ups.com> > >> Gazza <use...@garethlock.com> wrote: > > >>> [...] Is there any way of neutering the CTRL key in > >>> a similar fashion so that it sets a bit, rather than performing any > >>> other action defined by the VDU drivers? > > >> In contrast to Esc, the Ctrl key does not have any associated action, > >> so there is no need to suppress it. You can enquire about the state of > >> the Ctrl key at any time using OS_Byte 121. Whatever code you use to > >> accept keyboard input might do specific things when it sees Ctrl > >> keypresses, so in order to answer your question you need to tell us > >> how you accept and interpret keyboard input in your program. > >> OS_ReadLine, for instance, interprets certain Ctrl keypresses. > > Well... I was running a test program that just read from the keyboard > > and displayed both the ASCII codes and the character/string > > representation on the screen. The idea being I could trap CTRL+<key> > > and display the character on the screen, manually prefixed with "^" if > > it was part of a CTRL combo. However, I was stumbling across special > > cases such as CTRL+U and others which of course do funny things with > > the VDU drivers. > > Of course. Simply do not display characters with a code < 32 to the > screen. > > > What I want to do is to intercept this set a flag if > > CTRL was pressed and return the ASCII code of just the character > > pressed. I'm using GET to return ASCII codes with OS_Byte 229 set to a > > non-zero value to supress Escape. > > There is no need to do anything special. This is just a question of > interpreting the values you get. If you look at the returned codes it > should not be difficult to work out that Ctrl+A is 1, Ctrl+B is 2, > etc. If you want Ctrl+Shift as well, you need to test the shift key > explicitly. > > -- > Martin > --------------------------------------------------------------------- > Martin Wuerthner MW Software http://www.mw-software.com/ > RISC OS Software for Design, Printing and Publishing > ---------------------------------------------------------------------- Hide quoted text - > > - Show quoted text - So as long as I don't try to PRINT it until I figure out what I've got, then all should be OK... Yes?
[toc] | [prev] | [next] | [standalone]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2012-05-22 23:42 -0700 |
| Message-ID | <1f7f4803-c3ca-4c50-b063-d07b7f61a0f3@b1g2000vbb.googlegroups.com> |
| In reply to | #1732 |
OK... As I suspected... I was doing dopey things. I was PRINTing CHR$ (<key>) before I'd worked out whether CTRL was pressed, therefore PRINTing control codes. DUH!! Well... My excuse, it was gone midnight last night when I was trying to figure this out! Anyhow... Got the ESCape part of it nailed and the CTRL part half nailed. In his last post, Martin hinted at having to test the SHIFT key explicitly. Whilst I don't have CTRL+SHIFT+<key> combinations, I do need to differentiate between CTRL+u & CTRL+U for example. This could be achieved by using CTRL+SHIFT+u or having CapsLock on when CTRL +u is pressed, whichever of these it doesn't matter, it's just the character's case that's important. Thanks again in advance...
[toc] | [prev] | [next] | [standalone]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2012-05-23 16:20 -0700 |
| Message-ID | <47c33578-ba43-4f5e-9e25-39dd0527a9ca@m10g2000vbn.googlegroups.com> |
| In reply to | #1733 |
Well... After another little play, I've got no further than I had when I'd made the last post, probably lost a little ground if the truth be known. I'm starting to think about tossing GET altogether and scanning for a keypress with OS_Byte 121 and then reading the keyboard status byte using OS_Byte 202 and interpreting the CTRL, SHIFT & CAPS status from that. Will need to take a long look at this. Any help or advice would be appreciated here.
[toc] | [prev] | [next] | [standalone]
| From | jgharston <jgh@arcade.demon.co.uk> |
|---|---|
| Date | 2012-05-24 13:59 -0700 |
| Message-ID | <f85b54c4-eccd-4b57-9a8e-6bdd30435c9b@w24g2000vby.googlegroups.com> |
| In reply to | #1734 |
Gazza wrote:
> Any help or advice would be appreciated here.
REPEAT
K%=GET:S%=INKEY-1:C%=INKEY-2
IF S%:PRINT" Shift:";
IF C%:PRINT" Ctrl:";
IF K%<32 OR K%=127 PRINT "^";CHR$(K% EOR 64); ELSE PRINT CHR$K
%;
UNTIL FALSE
JGH
[toc] | [prev] | [next] | [standalone]
| From | Matthew Phillips <spam2011m@yahoo.co.uk> |
|---|---|
| Date | 2012-05-24 22:51 +0100 |
| Message-ID | <4228159552.Matthew@sinenomine.freeserve.co.uk> |
| In reply to | #1736 |
In message <f85b54c4-eccd-4b57-9a8e-6bdd30435c9b@w24g2000vby.googlegroups.com> on 24 May 2012 jgharston wrote: > Gazza wrote: > > Any help or advice would be appreciated here. > > REPEAT > K%=GET:S%=INKEY-1:C%=INKEY-2 > IF S%:PRINT" Shift:"; > IF C%:PRINT" Ctrl:"; > IF K%<32 OR K%=127 PRINT "^";CHR$(K% EOR 64); ELSE PRINT CHR$K > %; > UNTIL FALSE That will work nicely if the processing you do on the key presses is swift. If a keypress results in some long-winded processing, the user can press further keys which will be buffered (remembered). While the character that the key would generate is remembered and buffered properly, the above code is reading the state of the shift and ctrl keys *now*, not what they were when the character you have just read with GET was actually generated by the keyboard. If the user changes the state of the shift or ctrl key while your program is caught up in some heavy task and is not responding, then when it catches up with the buffered input you might end up thinking the user pressed the "a" key at the same time as shift, when actually the "a" had been buffered and the shift key was pressed later. If all that could cause a problem you have various options. One is to run through all the keys using negative INKEY values and read the keyboard state as it is at that instant. You can then detect any combination of keys the ham-fisted user might be pressing all at once. But it's not a good method for handling ordinary typing, as you would have to deal with keyboard auto-repeat and all that malarky yourself. The other option is something like the DeepKeys module, which I think only applies with the Wimp's key pressed messages. That manages (I think) to store the state of various modifier keys as they were at the time of the actual keypress. -- Matthew Phillips Durham
[toc] | [prev] | [next] | [standalone]
| From | Rick Murray <heyrickmail-usenet@yahoo.co.uk> |
|---|---|
| Date | 2012-05-26 16:16 +0200 |
| Message-ID | <almarsoft.1991658444556346075@news.orange.fr> |
| In reply to | #1737 |
On Thu, 24 May 2012 22:51:40 +0100, Matthew Phillips <spam2011m@yahoo.co.uk> wrote: > That will work nicely if the processing you do on the key presses is swift. > If a keypress results in some long-winded processing, the user can press [...] > reading the state of the shift and ctrl keys *now*, not what they were when I guess the important factor is how long something *actually* takes. Keypress entry is remarkably slow, a computer can build a display from data in less time than between keydown and keyup (with triangles on an older machine, damn near raytraced in realtime on a newer one). Remember Chocks Away! and the like? Not only was the game logic running, but the world was being redrawn in realtime (that's why it is kinda basic, there's only so much an 8MHz processor can do). Alternatives - write a small bit of code to hang on key events to record the state of keys and modifiers to a circular buffer. Or flush the keyboard buffer before reading so we know we'll only get fresh data. The latter is easy but nasty, the former is hard but the most useful. Best wishes, Rick.
[toc] | [prev] | [next] | [standalone]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2012-05-25 07:04 -0700 |
| Message-ID | <c575f921-7a69-4174-9bc0-85354763c8f0@f30g2000vbz.googlegroups.com> |
| In reply to | #1734 |
Turns out that character case isn't important. Funny... I could have sworn it was... Anyway... This is what I currently have... REM ******************************************************************************************************* REM Debug code... REM ******************************************************************************************************* REM Return "TRUE" if value is boolean TRUE, or "FALSE" otherwise... DEFFNbool2txt(flag%) IF flag% THEN ="TRUE" ="FALSE" REM Parse an 8 bit mask and return a text representation of bit status... DEFFNbits2txt(mask%) LOCAL i%,byte$:byte$="" FOR i%=0 TO 7 IF FNbbc_tstbit(i%,mask%) THEN byte$+="1" ELSE byte$+="0" NEXT =byte$ REM ******************************************************************************************************* REM Exported code... REM ******************************************************************************************************* REM Get keyboard input... REM This behaves just like GET in basic usage. When taken advantage of it will return the character in REM char$ and the state of the CTRL key in flag%. Bit 6 of keyboard status byte is CTRL key state REM according to OS3 PRM. Bit set, CTRL key down. Bit clear, CTRL key up. Var. debug% is here for use REM in test prog. only... DEFFNbbc_getkey(RETURN char$,RETURN flag%,debug%) LOCAL code%,kbflags%:kbflags%=0 flag%=FALSE :REM Clear CTRL key flag on entry... code%=GET:SYS"OS_Byte",&CA,kbflags%,&FF :REM OS_Byte (R0=&CA (202)), (R2=&FF (255)). Read kbd status byte. flag%=FNbbc_tstbit(6,kbflags%) :REM If CTRL key down then set flag% TRUE... REM Debug code. Why OS_Byte is returning zero here ?!?!? IF debug% THEN PRINT"Bit position : 01234567" :REM Create a meaningful table for next line... PRINT"Keyboard status byte : "+FNbits2txt(kbflags%) :REM Debug... Display kbd status byte... PRINT PRINT"CTRL key status : "+FNbool2txt(flag%) :REM Debug... Is CTRL key down... ENDIF REM Deal with special cases, such as NULL, TAB, ENTER, ESCAPE & SPACE. There may be more... REM Otherwise, if code% < 65, add 64 to take it out of CTRL character range before getting it's character REM representation, then RETURN that on exit. CASE code% OF WHEN 0 : char$="NULL" WHEN 9 : char$="TAB" WHEN 13 : char$="ENTER" WHEN 27 : char$="ESCAPE" WHEN 32 : char$="SPACE" OTHERWISE : IF code%<65 THEN code%+=64:char$=CHR$(code%) ENDCASE REM Finally return ASCII code read. This will be offset to uppercase if regular CTRL character. =code% REM Test a bit at pos% in bitmask mask%. Return TRUE if set. DEFFNbbc_tstbit(pos%,mask%) =((mask% AND 1<<pos%)=(1<<pos%)) REM ******************************************************************************************************* View code with fixed width font. Sorry if it wraps... Calling program disables ESCape key with OS_Byte 229 (&E5) before this is called. Can't get anything meaningful back from OS_Byte 202 (&CA). Always returns zero even if CTRL key held down. My debug routines are included here for completeness, but finished code will not have debug% passed to it, or call any of the debug routines bool2txt() or bits2txt(). Any help would be appreciated...
[toc] | [prev] | [next] | [standalone]
| From | jgharston <jgh@arcade.demon.co.uk> |
|---|---|
| Date | 2012-05-25 07:48 -0700 |
| Message-ID | <c85f61b8-15c7-41a7-aeb9-935f38097744@fr28g2000vbb.googlegroups.com> |
| In reply to | #1738 |
Gazza wrote:
> REM Parse an 8 bit mask and return a text representation of bit
> status...
> DEFFNbits2txt(mask%)
> LOCAL i%,byte$:byte$=""
> FOR i%=0 TO 7
> IF FNbbc_tstbit(i%,mask%) THEN byte$+="1" ELSE byte$+="0"
> NEXT
> =byte$
errr..? Return the binary string value of a number?
REM Binary padded with zeros (mdfs.net/blib/Number)
DEFFNb0(A%,N%):LOCAL A$,B$,L%:B$="0":IFA%<0:B$="1":A%=A
%AND&7FFFFFFF
REPEATA$=STR$(A%AND1)+A$:A%=A%DIV2:L%=L%+1:UNTILL%>30:=RIGHT$(B$+A
$,N%)
Ok, that's a bit dense, because it's a library function, but the
first rule of programming is "find and reuse pre-existing code".
> code%=GET:SYS"OS_Byte",&CA,kbflags%,&FF
> flag%=FNbbc_tstbit(6,kbflags%)
> REM Why OS_Byte is returning zero here ?!?!?
You haven't returned *anything* from the osbyte call. All you've
done is pass values *top* the osbyte call.
SYS "OS_Byte",&CA,0,&FF TO ,kbflags%
And, as you've looking at the state of the Ctrl key 'now', you
may as well just use INKEY-2.
> CASE code% OF
> WHEN 0 : char$="NULL"
> WHEN 9 : char$="TAB"
> WHEN 13 : char$="ENTER"
> WHEN 27 : char$="ESCAPE"
> WHEN 32 : char$="SPACE"
> OTHERWISE : IF code%<65 THEN code%+=64:char$=CHR$(code%)
> ENDCASE
Ctrl-I returns "TAB", Ctrl-M returns "ENTER". Is that what you want?
Don't you want to distinguish between Ctrl-M and Enter, between
Ctrl-I and TAB?
> Any help would be appreciated...
REM Return a string with the keypress, and returns Shift and Ctrl
status
:
DEFFNbbc_getkey(RETURN shift%, RETURN ctrl%)
LOCAL key%, char$
key%=GET:shift%=INKEY-1:ctrl%=INKEY-2 :REM Read keypress, shift and
ctrl keys
char$=CHR$key% :REM Prepare to return
keypress as a character
IF key%<32 OR key%=127 THEN char$="^"+CHR$(key% EOR 64)
: :REM If a Ctrl+key, prepare to
return "^X"
IF ctrl%=0 THEN
: :REM If Ctrl was /not/
pressed...
CASE key% OF
: :REM Translate to key names
WHEN 8 : char$="BACKSPACE"
WHEN 9 : char$="TAB"
WHEN 13 : char$="ENTER"
WHEN 27 : char$="ESCAPE"
WHEN 30 : char$="HOME"
WHEN 32 : char$="SPACE"
WHEN 127 : char$="DELETE"
ENDCASE
ENDIF
=char$ :REM Return keypress string
Can be optimised quite a bit.
JGH
[toc] | [prev] | [next] | [standalone]
| From | Steve Drain <steve@kappa.me.uk> |
|---|---|
| Date | 2012-05-25 16:30 +0100 |
| Message-ID | <iCNvr.94553$8q1.62651@fx29.am4> |
| In reply to | #1739 |
jgharston wrote: > Gazza wrote: >> REM Parse an 8 bit mask and return a text representation of bit >> status... >> DEFFNbits2txt(mask%) >> LOCAL i%,byte$:byte$="" >> FOR i%=0 TO 7 >> IF FNbbc_tstbit(i%,mask%) THEN byte$+="1" ELSE byte$+="0" >> NEXT >> =byte$ > > errr..? Return the binary string value of a number? > > REM Binary padded with zeros (mdfs.net/blib/Number) > DEFFNb0(A%,N%):LOCAL A$,B$,L%:B$="0":IFA%<0:B$="1":A%=A > %AND&7FFFFFFF > REPEATA$=STR$(A%AND1)+A$:A%=A%DIV2:L%=L%+1:UNTILL%>30:=RIGHT$(B$+A > $,N%) > > Ok, that's a bit dense, because it's a library function, but the > first rule of programming is "find and reuse pre-existing code". errr..? SYS"OS_ConvertBinary1",mask%,END+255,255 TO byte$ or, with Basalt: byte$=NUM$(mask%,4,1)
[toc] | [prev] | [next] | [standalone]
| From | jgharston <jgh@arcade.demon.co.uk> |
|---|---|
| Date | 2012-05-27 05:43 -0700 |
| Message-ID | <19038740-420a-49e7-856a-2f065dc0fc01@s5g2000vbc.googlegroups.com> |
| In reply to | #1740 |
Steve Drain wrote: > > errr..? Return the binary string value of a number? > > SYS"OS_ConvertBinary1",mask%,END+255,255 TO byte$ Doh! Of course. Zero'th law of programming: can the underlying system do it? JGH
[toc] | [prev] | [next] | [standalone]
| From | Rick Murray <heyrickmail-usenet@yahoo.co.uk> |
|---|---|
| Date | 2012-05-26 16:08 +0200 |
| Message-ID | <almarsoft.3384037181680336964@news.orange.fr> |
| In reply to | #1739 |
On Fri, 25 May 2012 07:48:09 -0700 (PDT), jgharston <jgh@arcade.demon.co.uk> wrote: >> IF FNbbc_tstbit(i%,mask%) THEN byte$+="1" ELSE byte$+="0" > errr..? Return the binary string value of a number? Isn't there an OS_ConvertBlahBlah SWI that can do this? Best wishes, Rick.
[toc] | [prev] | [next] | [standalone]
| From | Harriet Bazley <bazley@feathermail.co.uk> |
|---|---|
| Date | 2012-06-08 08:55 +0100 |
| Message-ID | <d41d829c52.harriet@blueyonder.co.uk> |
| In reply to | #1738 |
On 25 May 2012 as I do recall,
Gazza wrote:
> Turns out that character case isn't important. Funny... I could have
> sworn it was...
[snip]
*I* could have sworn that character case was important in Moria... how
else do you tell the difference between a bat and a Balrog?
In a turn-based dungeon crawl, on the other hand, I shouldn't have
thought that keyboard scanning speed was terribly significant.
--
Harriet Bazley == Loyaulte me lie ==
One man tells a falsehood, a hundred repeat it as true.
[toc] | [prev] | [next] | [standalone]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2012-06-08 01:16 -0700 |
| Message-ID | <3e1b6bbd-7583-4f0d-aea7-5a40367bf945@x21g2000vbc.googlegroups.com> |
| In reply to | #1791 |
On Jun 8, 8:55 am, Harriet Bazley <baz...@feathermail.co.uk> wrote: > On 25 May 2012 as I do recall, > Gazza wrote: > > > Turns out that character case isn't important. Funny... I could have > > sworn it was... > > [snip] > > *I* could have sworn that character case was important in Moria... how > else do you tell the difference between a bat and a Balrog? > > In a turn-based dungeon crawl, on the other hand, I shouldn't have > thought that keyboard scanning speed was terribly significant. > > -- > Harriet Bazley == Loyaulte me lie == > > One man tells a falsehood, a hundred repeat it as true. What I meant when I said character case didn't matter was that there were no lowercase CTRL combos used, so from a keyboard scanning perspective scanning for lowercase CTRL combos wasn't req'd
[toc] | [prev] | [next] | [standalone]
| From | Martin Wuerthner <spamtrap@mw-software.com> |
|---|---|
| Date | 2012-05-24 11:07 +0200 |
| Message-ID | <1229cf9452.martin@bach.planiverse.com> |
| In reply to | #1733 |
In message <1f7f4803-c3ca-4c50-b063-d07b7f61a0f3@b1g2000vbb.googlegrou
ps.com>
Gazza <usenet@garethlock.com> wrote:
> OK... As I suspected... I was doing dopey things. I was PRINTing CHR$
> (<key>) before I'd worked out whether CTRL was pressed, therefore
> PRINTing control codes. DUH!! Well... My excuse, it was gone midnight
> last night when I was trying to figure this out!
> Anyhow... Got the ESCape part of it nailed and the CTRL part half
> nailed. In his last post, Martin hinted at having to test the SHIFT
> key explicitly. Whilst I don't have CTRL+SHIFT+<key> combinations, I
> do need to differentiate between CTRL+u & CTRL+U for example. This
> could be achieved by using CTRL+SHIFT+u or having CapsLock on when CTRL
> +u is pressed, whichever of these it doesn't matter, it's just the
> character's case that's important.
Taking CapsLock into account when interpreting Ctrl keypresses sounds
unusual to me. I think CapsLock should only be relevant when entering
real characters. However, if you really want to take CapsLock into
account, then that would be easy enough. Simply read both the Shift
and the CapsLock status.
--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Rick Murray <heyrickmail-usenet@yahoo.co.uk> |
|---|---|
| Date | 2012-05-26 16:18 +0200 |
| Message-ID | <almarsoft.9157515247677535714@news.orange.fr> |
| In reply to | #1735 |
On Thu, 24 May 2012 11:07:07 +0200, Martin Wuerthner <spamtrap@mw-software.com> wrote: > account, then that would be easy enough. Simply read both the Shift > and the CapsLock status. Be aware, however, the the configurations Caps, NoCaps, and ShCaps subtly alter how Caps Lock behaves. Best wishes, Rick.
[toc] | [prev] | [next] | [standalone]
| From | Gazza <usenet@garethlock.com> |
|---|---|
| Date | 2012-05-27 02:25 -0700 |
| Message-ID | <7ff248eb-a30d-4f65-9716-73e720443488@q2g2000vbv.googlegroups.com> |
| In reply to | #1745 |
Thanks JGH... I've grafted parts of what you had into my latest routine and have something sort of working. Still however, can't tell the difference between CTRL+ESC & CTRL+[ for example. This is just the one I tried, there were others you mentioned previously. What I have now looks like this. In it's most basic form, I need it to return an ASCII code as a result, like GET, with one, or both of the other values RETURNed, so I've messed it about a bit to return the values in the correct places. Again, you'll need to use a fixed width font and sorry if code wraps... REM Get keyboard input... REM This behaves just like GET in basic usage. When taken advantage of it will return the character in REM char$ and the state of the CTRL key in flag%. Bit 6 of keyboard status byte is CTRL key state REM according to OS3 PRM. Bit set, CTRL key down. Bit clear, CTRL key up. DEFFNbbc_getkey(RETURN char$,RETURN flag%) LOCAL code%,shift%,ctrl%,caps%,kbflags% char$="":flag%=0 :REM Clear all values on entry... shift%=3:caps%=4:ctrl%=6 code%=GET:SYS"OS_Byte",&CA,0,&FF TO void%,kbflags% :REM OS_Byte (R0=&CA (202)), (R2=&FF (255)). Read status. flag%=FNbbc_tstbit(ctrl%,kbflags%) IF (code%<32 OR code%=127) AND flag% THEN char$=CHR$(code% EOR 64) REM Deal with special cases, such as NULL, TAB, ENTER, ESCAPE & SPACE. There may be more... IF (NOT flag%) THEN CASE code% OF WHEN 0 : char$="NULL" WHEN 8 : char$="BACKSPACE" WHEN 9 : char$="TAB" WHEN 13 : char$="ENTER" WHEN 27 : char$="ESCAPE" WHEN 30 : char$="HOME" WHEN 32 : char$="SPACE" WHEN 127 : char$="DELETE" OTHERWISE : char$=CHR$(code%) ENDCASE ENDIF =code% REM Test a bit at pos% in bitmask mask%. Return TRUE if set. DEFFNbbc_tstbit(pos%,mask%) =((mask% AND 1<<pos%)=(1<<pos%))
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | comp.sys.acorn.programmer
csiph-web