Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

HOW TO PREVENT USER FROM CLICKING ON A TEXT BOX 2

Status
Not open for further replies.

TNN

Programmer
Sep 13, 2000
417
0
0
US
I have 120 text boxes and I want to prevent the user from clicking or dbl clicking on certain text boxes and therefore preventing any entries to these text boxes after clicking. I can't disable the text boxes because I want the user to tab thru and make entries but not to be able to use the mouse to go back. Also don't want user to be able to tab backwards. Any suggestions are appreciated.
Thank You,
TNN, Tom
TNPAYROLL@AOL.COM

TOM
 
checking the text box name,

private sub txt_click()
if activecontrol.name = "txt1" then
....
endif
end sub
 
use the lost focus event:

Private Sub txtText_LostFocus()
txtText.Enabled = False
End Sub
 
Another option...

Private Sub txtText_LostFocus()
txtText.Locked = True
End Sub
Locks the text box but still allows for
tabbing.
 
Thank You All for your suggestions but none quite fill the bill.
All the text boxes are not necessarily landed on as user tabs thru, some are skipped, therefore cannot use GotFocus LostFocus.

Don't want user to be able to put cursor in the text box.

I'll try that If statement, hmmm....maybe

Any other ideas out there. Thanks everbody.

TNN, Tom
TNPAYROLL@AOL.COM

TOM
 
I guess I have to ask why you want to do this. It violates the spirit of Windows applications, namely, that the user drives the program, not the other way around.

Your application is very unforgiving. What you want to do makes it impossible for a user to correct a mistake once he/she has tabbed out of the box. That's pretty poor application design, if you ask me. Nothing the user does should be set in stone before he/she clicks a command button or chooses a command from a menu to finalize what they've entered.

Users will hate your design and resist using it. I think you should reconsider whether this is the best way to solve whatever problem is causing you to want to do this. Rick Sprague
 
Well said, Rick ..Sometimes advise is easly learned, and sometimes it hits us like a MACK truck. Been there, done both !
 
Rick,

Your advice is well taken but what I am trying to accomplish is keyboard rapid entry withhout having to take your hands off the keyboard to use that silly mouse which sooo slows down rapid data entry. I was trying to have the user go back to make corrections or changes without having to use the mouse and not having to do a shift tab back to the correction but enter through to get back or esc to get back to the starting point.
However, It looks like I may have accomplished my goal with limited mouse usage and yes the user drives the program. The typical windows app does not lend itself to rapid data entry. A good data entry user or operator does not want to mess with that mouse or click on drop down menus.

Rick, Thank You so much for your input. Your advice is well taken.
TNN, Tom
TNPAYROLL@AOL.COM

TOM
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top