Lazy readonly textbox

[Toman]

Hi,

In VFP7 I've noticed a strange behavior. If readonly textbox gets a focus and you press a key eventually hold the key to let it auto repeat and fill the keyboard buffer, (mouse) cursor disappears or takes hourglass shape for a surprisingly long time. Many seconds on 2 GHz machine. During this period is program busy.

I understand that readonly textbox could (i) ignore keyboard buffer at all or (ii) discards its contents fully.

Does someone know what happens at that long time and how to avoid this situation. I don't like to give up of using readonly textboxes – they are better then disabled ones if one wants to prevent values to be changed by user.

Thank you, Toman

 

[robsuttonjr]

How about not holding the key down?

Regards,

Rob

 

[crewchiefpro6]

Why in the world would you want a readonly control to get focus at all? Seems like a bad idea to me.

make sure it is also disabled unless you need it, in which you can enable it and turn off read only.



Don Higgins

http://www.crewchiefpro.com

 

[Toman]

Hi Rob, thank you for your post. I am afraid, you did not help me a lot.

Hi Don, in my opinion even readonly textboxes should be sometimes accessible to allow selecting the value and copying it into the clipboard. Try to select and copy Product ID from This computer – Properties window. This is what I'm talking about.

But I don't want to discuss where readonly property is suitable and where not.
I'd only like to know what happens in keyboard buffer when a key is pressed in readonly textbox. Stay characters in a buffer? If not, which process discards them? Why take it so long.

Tom.

 

[Mike Lewis]

Tom,

I'm only guessing, but I would think a read-only text box handles keystrokes in the same way as a read-write text box. The only difference is that the keystrokes don't update the underlying value.

After all, even a read-only text box needs to process Ctrl+C, Ctrl+X, Ctrl+A, Tab, Enter and perhaps some others.

Just like with any other control, if the textbox receives more keystrokes than it can handle, the program will suspend until catches up. The text box has to look at each character and decide if it can process it. If it can't, it will discard it.

I don't know if that answers your question.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[robsuttonjr]

It would make sense to investigate what's going on with keyboard buffers for a situation that is considered a norm, ie users entering into textbox's. But why try to understand what is going on when a user is doing something improper like holding down a key for 10 minutes or a key getting stuck. That is why I said just don't hold the key down. It just seems a waste of time to worry about something that is abnormal. It is somewhat like asking what happens to the keyboard buffer when I power off my computer. But don't take it personal its just my thought on the matter.

Regards,

Rob

 

[Toman]

Hi Mike,

...The text box has to look at each character and decide if it can process it. If it can't, it will discard it.

Yes, this is an answer to my question. Only missing is the explanation, why it take so long.

Nevertheless I don't insist on knowing the true any more. I see that important is to know how read only text box behaves and select other approach if really needed. To open this thread was probably a mistake.

I am sorry, Tom.

 

[robsuttonjr]

Tom,
Executing a NODEFAULT in the KeyPress event prevents Visual FoxPro from placing the key press into the Visual FoxPro keyboard buffer. I believe this would solve your problem. This is the link I got this from:

http://gethelp.devx.com/techtips/vfox_pro/10min/10min0100/10min0100.asp

Regards,

Rob

 

[Mike Lewis]

Tom,

To open this thread was probably a mistake.

Not at all. It was an interesting question, even though you didn't get the full answer.

Rob,

Executing a NODEFAULT in the KeyPress event prevents Visual FoxPro from placing the key press into the Visual FoxPro keyboard buffer.

True, but won't that also interfere with the legitimate keystrokes, such as Ctrl+C?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[robsuttonjr]

Nope works fine. You can USE CTRL-C still and infact leave the box readonly=.T. and nothing is entered into the keyboard buffer from keys pressed. Sure the textbox ignores the 'CTRL-C' but windows system doesn't. So all you would have to do is create a visual class and add this textbox if you so desired to no allow the user to fill the keyboard buffer on these readonly textbox's but external events such as ctrl-c still work.

Regards,

Rob

 

[robsuttonjr]

Another intersting thing is that if you have the TextBox.ReadOnly=.F. and the keypress event NODEFAULT, you can't type anything but could CTRL-C AND CTRL-P inside the box. Not that I can see any need for such a condition.

Regards,

Rob

 

[Mike Lewis]

Rob,

Thanks for that. It might just come in useful one day (perhaps).

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[DSummZZZ]

Another untried option may be setting the TYPEAHEAD limit to 1 in the GotFocus event and back to whatever it was on the LostFocus event.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Toman]

Typeahead buffer size seems not to affect described behavior of text box.
One more observation – The TextBox Control is present probably in all visual languages. I've tested it in Visual Basic v.6. There is a corresponding property to Read Only called Locked. Text box with Locked set to True behaves quite normally e.g. does not produce any delay in computer work.
Tom