Anyone got any ideas on the easiest way to disable the Tab-Key functionality on a form? In other words, to change the control focus, I'd like to require that the user use the mouse. If they press the tab key, I'd just prefer that nothing happen.
Printable View
Anyone got any ideas on the easiest way to disable the Tab-Key functionality on a form? In other words, to change the control focus, I'd like to require that the user use the mouse. If they press the tab key, I'd just prefer that nothing happen.
.TabStop property of control.
Nice Dragokas. Sometimes I get my head stuck in so deep, I forget about the easy stuff. I hadn't started coding, but I was well on my way to thinking through how to use some subclassing to get it done. The TabStop property is a much easier way. I'll write a method to do it and post it shortly.
Yep, this does exactly what I want:
Thanks Again Dragokas,Code:
Public Sub DisableTabbing(frm As Form)
Dim c As Control
'
On Error Resume Next ' Not all controls may have the TabStop property.
For Each c In frm.Controls
c.TabStop = False
Next c
On Error GoTo 0
End Sub
Elroy
Wouldnt you just set the TabStop property to false when in design view of the forms? No need to send resources looping through every control or form.
Possibly but if they are heavy complex forms then one can always go into the .frm file and open it with notepad, find n replace ".TabStop = True" with ".TabStop = False". Save the file and reopen with Visual Studio. Fast, easy and one time processing.
nice! except that doesn't work.
Unless you've set the tabstop manually once - it's not even stored in the frm.
edit: multiselect seems to work in the IDE, but then it gets complicated if you use containers, or have to dodge controls that don't have a tabstop property.Quote:
In theory there is no difference between theory and practice. In practice there is.
Besides - us posting / debating the best way to micro-optimize this, may have already taken longer than the lifetime cumulative microseconds of load time added to Elroy's forms :)
Makes perfect sense... Default property values aren't typically written, just like well designed usercontrol propertybags.Quote:
Unless you've set the tabstop manually once - it's not even stored in the frm.
the frm file is just a textual layout and whats to stop you from adding an entry for it in?
Absolutely nothing. Most text editor's won't allow you to insert carriage returns and tabs (during search & replace) so that the inserted items could be added in the same visual format as other entries. But this could be a case of building a one-time mini-app to parse all the files, add the tabstop property for all the forms and be done with it.
Edited: manual update of the text file is out of the question... I've seen samples of his forms too :eek:
On a side-note. I'm a keyboard guy. I use tabs to navigate the keyboard vs using just the mouse. My fingers have been trained to know Tab and one-handed Shift+Tab. Apps that don't allow keyboard navigation are not as user-friendly as they could be. But there must be a reason why Elroy doesn't want them -- hope his customers aren't hindered. If I was a customer, I'd throw the app in the recycle bin. For data-entry, I don't want to be taking my hands off the keyboard every time I need to move to a different field. But that may just be me; don't think so.
Time, money and diminishing returns.
like lavolpe said though - maybe he can write a little utility to add in properties, or allow him to better select all the controls on a form and update properties en mass as you suggest. Then theoretically he will gain time saved from future efforts. All in the name of saving his users microseconds.
:DQuote:
Originally Posted by dexwerx
Attachment 148539
he-he. Nothing to replace.
+1Quote:
Originally Posted by lavolpe
Dragokas, confused a bit. The "TabStop = 0 ' False" line shouldn't exist unless it was changed in design view. By default, any control that has a tabstop property, the value is true and that wouldn't be in the frm file. So, to add them in the frm file via a text editor, you'd need to insert a line and add the entry. Again, I don't think you'd find a line, written by VB, like: TabStop = 1 ' True. Elroy wants all tabstops set to false
I just confirmed that Elroy cannot open frm and run "replace" true into false, because by default nothing to replace.
"TabStop = 1 ' True" is not exists by default in frm file.
hahaha, geez. Who knew I'd generate so much discussion.
Just as an FYI, here's the form.
Attachment 148543
I probably will someday go back and set the TabIndex properties. But I'm just trying to get some other work done right now and didn't want to mess with it.
Also, as a further FYI, That's a control I call OptionEx. It has a GroupNum property for grouping (rather than depending on the container).
Best Regards,
Elroy
Elroy
Nifty image .. :thumb:
If it's not out of place, a thought regarding "You should have the full SRS-30 beside you ..."
Add a "Help" button.
.. when off (default), nothing.
.. when on, Labels with a fuller explanation appear, depending on the cursor position.
EDIT:
Natch, it would involve a fair amount of coding (fairly easy, but lots of cases), but it
might not always be convenient for users to have the manual at hand.
Spoo
Hi Spoo,
I'm sort of already ahead of you. In other places, I've got help buttons all over the place that pull up images, text help, and PDFs. On this one, there's actually another section that administers the questionnaire one-screen-per-question. And that will be the typical way it's administered. However, on occasion, they'll use a patient a pencil-and-paper version for administration. Therefore, this screen essentially has two purposes: 1) to allow the therapist a quick way to enter this pencil-and-paper version, and 2) an easy way to view the answers that were entered via the one-screen-per-question approach.
That caveat you quote is just to suggest that this screen should not be used for direct administration with the therapist asking questions from it.
Again, good idea though, and I actually do that in many other places.
Best Regards,
Elroy
EDIT1: Just to show off a bit, I suppose, here's an example where I do something similar:
Attachment 148563
No offense but that form would drive me crazy trying to use the mouse to select the correct option and not the line above or below. It definitely looks like it should be keyboard friendly imo.
I always try to think outside the box like when suggesting edit the frm file. Sure if opened in Word it would work easier but alas if time is the constraint, just get it working is the best solution. Perhaps writing some kind of utility to set all tabstops to false will be somewhere down the line.
Elroy,
The attached will allow you to disable the Tab Key
HTH,
Rob
Hi Bobbles,
:) Well, that certainly gets it done. However, it also disables the tab key for all other programs, including something like Word.
I actually do something similar in another situation. I sendkeys-like (actually through API) automate another program from my program. It's a confusing program my clients use for foot-pressure-during-walking studies. The program has no "exposed" automation, so I'm stuck with the sendkeys-like approach to pull down its menus and execute what I want. However, the users would sometimes foul things up by using the keyboard and/or mouse while my controller program was attempting to do its quasi-automation. Therefore, I completely lock the mouse and keyboard for small intervals while I'm sending my keystrokes to the other program.
Hey, I'll hang onto your work, and work it up as a comctl32 style of subclassing if I ever use it.
Truth be told, I'm pretty much good-to-go with what I did in post #4 regarding this issue.
All The Best,
Elroy