Workaround for CAPS() or NUML() in FPD26 under XP

[foxven]

First Post.

My name is Antulio Sardi, working with FPD26 since when i can't remember, and still stuck on it with hard resistance to upgrade my coding habits to visual/object new stuff, (kind'a nerd... i know!), enough for meets, going to the stuff...

As many of us know, both of those functions ( CAPS()/NUML() ) doesn't change the keyboard light under XP.

The only thing one can do is to trap the ACTUAL status of the NUMLOCK and/or CAPSLOCK in the screen and encourage the user to select the apropriate mode to satisfy the system/user needs.

But when i use NUML() to get the status i always get the wrong value, then i found using the next code to get what i need:

NUMLCK=NUMLOCK()
NONLCK=NOT NUMLCK
NUMLCK=NOT NONLCK

And then, i get the proper value...

My question is why, if someone knows...

BTW: Never tried with CAPS()/never need it...

 

[mmerlinn]

Would help if you would tell us what values you are getting, both correct and incorrect, and what values you are wanting. And what you are doing to get all of those values.


mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[foxven]

Well i think i was obvious (sorry), but let me clarify a little bit this issue...

In past threads, the actual impossibility of changing the numlock status programmaticaly under Windows XP by FoxDos was discussed, and it was stated that the only thing you can do with the NUMLOCK() function (and with the CAPSLOCK() function i guess), is "detect" the actual status of the NUMLOCK key under Windows XP and then inform the user to set the correct status of it in order to proceed with whatever it's required.

The problem is that at any random time, FPD26 does't recognize the proper status of the numlock key under Windows XP, sometimes when the keyboard light is ON, foxpro recognizes the inverse (an OFF ".F." status) by the NUMLOCK() function, and when you switch it to the opposite, then Foxpro recognizes a .T.

It get worst when Foxpro "decides" it's time to recognize the correct status, so i can't use a simple NOT operator assuming it always will be the inverse, since then the double NOT procedure is what does the work, i don't know why , i only know that it works.

I have a P.O.S. application which is intended to run in keypad-only workstations, that is, no alphanumeric keyboards attached, and the first time i noticed this problem was when several users complaint about a non functioning keypad, tracing away the problem, i realize that when the application needs the numlock set to numeric status it gets the opposite (an .F. status) and viceversa.

It seems that the double-negation, by any means, "flushes" or "refreshes" the numlock status... or something like that.

The original algorithm was something like this (not exactly):

cycle=.T.
do while cycle=.T.
if numlock()=.T.
     @10,00 say "Enter amount :" get amount default 0
     read
     cycle=.F.
else
     wait window "please set your keypad numlock to ON" nowait
endif
enddo

Several tests after, i get this "double negation" workaround, which allowed to get the proper status of the numlock key and this way inform the user the actual keypad numlock status, or better said, the windows XP actual numlock status, which i repeat, sometimes is not what FPD26 think it is:

cycle=.T.
do while cycle=.T.
NUMLCK=NUMLOCK()
NONLCK=NOT NUMLCK
NUMLCK=NOT NONLCK
if numlck=.T.
     @10,00 say "Enter amount :" get amount default 0
     read
     cycle=.F.
else
     wait window "please set your keypad numlock to ON" nowait
endif
enddo

My question if anyone knows is about the logical reason of this (if there is one), because i can't figure out...

Thanks to all, and excuse my lazy last explanation.