Repeating Corrupt code Behavior 1

[lameid]

I have a continuous form that the numlock key toggles on as I tab between records. Sometimes decompiling the file and compiling fixes it but sometimes I have to jigger around in code and compile to get it to behave. This keeps coming up as the form is transferred to new FE's when a FE and BE pair is generated out of a central system based on specific purpose (walking the proprietary/non-proprietary line here).

That said this particular form has a 0 width control on it...

Private Sub txtTabStop_GotFocus()
    'This visible behind not seen control is needed for the record to receive focus when all data entry controls are disabled with conditional formatting
    'Otherwise the focus jumps to something like the close button in the footer instead of the next record
    
    SendKeys "{TAB}" 'Tab to next enabled control or record
    
End Sub

The issue to my best recollection started occuring after using the above workaround.

Any thoughts on repeated compiled code issues or alternatives to my Sendkeys?

 

[1DMF]

It's a known issue apparently..

https://support.microsoft.com/en-us/kb/179987

It suggests putting a DoEvents after the SendKeys command to ensure it finishes before another is called.

Or mess about manually keeping the state of the numlock key.

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[lameid]

D'oh... Search for bugs on the statement you added when things are weird.

Interestingly adding Doevents after the Sendkeys line did not seem to help in this case.

But understanding the source of the problem lead me to use conditional formatting on txtTabStop with logic opposite that which makes the control needed to receive focus.
I'm not saying the bug will never be experienced on the form but it at least it isn't nearly every tab amongst records.

Now that the control can only receive focus on bad records, I can seriously consider just navigating to the next record and possibly avoid sendkeys.

Many thanks. As I like to say, when all else fails go with the obvious.

 

[1DMF]

SendKeys has always been a bit of a blackhat command, and should be avoided where ever possible.

I like their solution, even MS are well .. this might fix it , if not try this, or maybe that

i thought it funny that if you implemented the numlock key state option, it might start flashing like a Christmas tree if the SendKeys was looping that often.

I can imagine a lot of support calls from users complaining their keyboard was freaking out and lights were flashing like crazy

I might write a function to toggle that and the capslock and see if I can make the keyboard go into 'Disco' mode

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[lameid]

I've avoided Sendkeys for a long time but it seemed right in this case because I wanted it to tab to the next control or record... It looks like I didn't try hard enough to avoid it in this case.