Get Character of nKeyCode from within Key_Press event 2

[dantheinfoman]

Hi All,

I'm trying to return the character (for a seek or locate) of whatever key(s) is pressed in the keypress event. I have a grid and want to allow users to start typing and for it to search the nearest values in order for them to zoom around the grid, rather than clicking the down arrow a gazillion times. I've heard of incremental grid searching, but frankly, I'd be happy to just be able to SEEK on the first letter typed. I can't even do that because I can't seek on a number, I need a way to convert the 'nKeyCode' into a Character. For example, instead of the nKeyCode being 115, I'd rather be able to convert to see that it was a letter 's' that was typed. 115 is meaningless to my SEEK command.

Thanks for any advise!

Dan

 

[dantheinfoman]

Just to be clear, I'd rather not have a textbox just for searching, I'd like to emulate foxyclasses locatorgrid, wherein the user simply clicks within the grid and begins typing and it seeks the nearest entry.

If only I could decypher the locatorgrid.vcx, I could just use that code.

Thanks

Dan

 

[Olaf Doschke]

I think this would also work native without needing the kepress, but the help topic on INKEY has a table showing keys and their number, for letters it's quite simply the ascii code, so in case ISALPHA(CHR(nKeyCode)) and nShiftAltCtrl=0 you have a letter and the letter is CHR(nKeyCode).

Bye, Olaf.

 

[dantheinfoman]

Haha! Olaf, I'm such a ninny. I'd all but given up on using CHR, though I'd seen this referred to this evening. What I did wrong was using CHR(TRANSFORM(nKeyCode)), because I'm so used to having to use TRANSFORM with any numbers. Apparently, there are exceptions to those rules.

Thanks so much, this worked!!

Dan

 

[Olaf Doschke]

Well, functions needing a numeric parameter need a numeric parameter, TRANSFORMS() turns any type into a string representation.

And don't just use CHR(), you get false positives, if nShiftAltrCtrl<>0, eg SHIFT+F1 to F10 causes nKeycodes, that fall into the region of letters.
More specific, if nShiftAltrCtrl no modifier key is pressed and you expect lower case letters, if CHR(nKeyCode) returns an upper case letter while nShiftAltrCtrl =0, that's a false positive, and also if Bitset(nShiftAltrCtrl,1) =1 the SHIFT key is pressed and CHR(nKeyCode) giving a lower case letter then also is wrong, besides CTRL+letters are hotkeys you don't want to capture. It's not that simple, if you want it to give you the right char, so it's easier to put a textbox above the grid to simply enter a search expression. Then there is no guessing and the user sees what's located and can also modify with backspace, eg.

Bye, Olaf.

 

[Mike Lewis]

Dan, it's not really an exception to the rule. The point is that most functions take parameters of specific data types. You can always know what data type you need to pass by referring the function's calling sequence, as documented in the Help.

In the case of the CHR() function, the calling sequence is:

[tt]CHR(nANSICode)[/tt]

The n at the start of nANSICode tells you that the parameter must be numeric. As Olaf pointed out, the TRANSFORM() function converts a value to a character string, which is why you wouldn't use it here.

Similarly, most functions return a value of a specific data type. This is usually documented in the Help under the heading "Return Value". In this case of CHR() and TRANSFORM(), this is character.

Sorry if I am stating the obvious here, but I know how easy it is to be tripped up by these details.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

> used to having to use TRANSFORM with any numbers

Well, there is one simple rule, if you use a function, watch for the intellisense help about parameters, the tooltip tells you the parameter of CHR is nANSICode and the prefix n stands for numeric.
See

https://msdn.microsoft.com/en-us/library/4k6dthew(v=vs.80).aspx

This talks about two prefix chars for each variable name to denote the scope of a variable and it's type. The syntax section of commmand and function help topics and the intellisense tool tip texts about parameters follow that naming convention without the scope prefix, as you are allowed to pass in any scoped variabe and even constants, so parameter names are only prefixed with type.

Bye, Olaf.

 

[newtofoxpro]

OP, experts already posted good idea. Just take a look of my code.

PUBLIC ofrm
ofrm=CREATEOBJECT("myForm")
ofrm.show()

DEFINE CLASS myForm as Form
   Width=500
   ADD OBJECT myGrd as Grid WITH Width=this.Width, AllowCellSelection=.F.
   PROCEDURE Init
      USE (HOME(2)+"northwind\customers") IN 0 ALIAS "Cust"
      SELECT Cust
      this.myGrd.RecordSource="Cust"
   ENDPROC
   PROCEDURE myGrd.Keypress(nKeyCode, nShiftAltCtrl)
      IF ISALPHA(CHR(nKeyCode))
         OutString=CHR(LASTKEY())
         DO WHILE INKEY(1)#0
            OutString=OutString+CHR(LASTKEY())
         ENDDO
         LOCATE FOR EVALUATE(FIELD(1))=ALLTRIM(UPPER(OutString))
         IF EOF()
            LOCATE FOR UPPER(OutString)$EVALUATE(FIELD(1))
         ENDIF
         OutString=""
         this.Refresh()
      ENDIF
   PROCEDURE destroy
      USE IN Cust
ENDDEFINE

 

[Olaf Doschke]

Well,

all I said is not incorporated when only testing ISALPHA(CHR(nKeyCode)).

Bye, Olaf.