I needed to take a field out of the keyboard-tabbing sequence (that field's value automagically defaulted to a value, and requiring a user to click on the field to change the value.)
Too easy, I said.
Then I spent the better part of an hour figuring out why VisWinSetTabOrder(hWndItem, hWndNULL) wasn't taking the field out of the tab order.
During SAM_Create processing of the window and child objects and during SAM_CreateComplete processing of the window, keyboard-tabbing sequence hasn't been applied to the child objects yet. The application of the sequence numbers (or "tab order" positions set via the "Layout" menu) happens only after SAM_CreateComplete of the winow.
So, I created a custom "PM_CreateComplete" message, and on SAM_Create of the field, I call SalPostMsg( hWndItem, PM_CreateComplete, 0, 0 ). and in the "On PM_CreateComplete" processing for the field, that's where I call VisWinSetTabOrder(hWndItem, hWndNULL).
I've been working with SQLWindows and Team Developer long enough that I should have thought of that tout-de-suite.
For newbies, it would be a good thing for the function's documentation to include this "wee by-the-way heads-up" on usage.
So this didn't work?
Code: Select all
Form Window: ... On SAM_CreateComplete Call VisWinSetTabOrder(<field name/handle>, hWndNULL)
Code: Select all
Form Window... On SAM_CreateComplete .... any other code ! this would be the last line in this create complete msg Call SalSendMsgToChildren( hWndForm, PM_CreateComplete, 0, 0 )
Code: Select all
Data Field:... PM_CreateComplete Call VisWinSetTabOrder( hWndItem, hWndNULL )
Thanks for the heads-up, and good to know about what you found out and for future reference.
Maybe something fixed beyond TD5.2SP3, or something that just exists with TD5.2SP3, or I'm possibly delusional (it might not be a bad idea for somebody else to do a little sanity check. Insanity check ???)
I can't say, not without a test case, Charlie. I have 5.2 SP5 installed and could try that there. In any event, if it's a bug with SP3 other or otherwise, the workaround would seem to be 1 of the options I suggested. Did you code any of those and try it?Maybe something fixed beyond TD5.2SP3, or something that just exists with TD5.2SP3
I already had my "PM_CreateComplete" solution in my first post. That resolves the "timing issue" A-1.
I'm adding "Solution" in my first post to better highlight it.
I don't know if I would necessarily call it a bug with Team Developer. I'd call it a bug with the documentation.
Maybe tab order assignment should be done before SAM_CreateComplete, but then again: maybe it shouldn't (who knows what kind of problems a "fix" would create ?
Reminds me of a great story:
There is a Taoist story of an old farmer who had worked his crops for many years.
One day his horse ran away.
Upon hearing the news, his neighbors came to visit.
"Such bad luck," they said sympathetically.
Maybe," the farmer replied.
The next morning the horse returned, bringing with it three other wild horses.
"How wonderful," the neighbors exclaimed.
"Maybe," replied the old man.
The following day, his son tried to ride one of the untamed horses, was thrown, and broke his leg.
The neighbors again came to offer their sympathy on his misfortune.
"Maybe," answered the farmer.
The day after, military officials came to the village to draft young men into the army.
Seeing that the son's leg was broken, they passed him by.
The neighbors congratulated the farmer on how well things had turned out.
"Maybe," said the farmer.
attached is a little app (TD 6.2) with a wrapper function HfsSetTabOrder.
Give it a try...
'Taborder rückwärts' + ohne df2 will not do as expected . It's only a simple sample.
What do you expect? I modified your test to remove that reordering on SAM_CreateComplete; I like to have a known starting point.ohne df2 will not do as expected
Beginning Test: focus on df1, top left. Tabs cycle through controls as defined in the form.
Click "rückwärts" -- 'backwards'. set focus df1, now tab. Tab jumps to the 4 PBs, then the fields in reverse order.
BUT... how do you expect the PBs to behave with tabbing? Your "rückwärts" button only changes tab order for the fields
Now click "ohne df2" -- 'without df2'. Set focus on df1, now tab. Tab jumps over df2 but now last tab of the data fields has df2 in the sixth/6th place for tabbing.
Once again, you wrote that "ohne df2 will not do as expected" -- what do you expect the tabbing to do?
As I read Charlie's first posting, though:
I understand that to mean he wants the field to be removed from the tabbing order, not changed. That is, is the field to be disabled? Or should it always be skipped when the user tabs? Or am I wrong, Charlie?? Thx.I needed to take a field out of the keyboard-tabbing sequence
SIDE NOTE: This test reminds me that long ago -- maybe Dave R. can verify this or say 'not true'? -- I recall that internally the tabbing order had something to do with the child control type, like fields were 'arranged' internally by TD in a certain order different from pushbuttons, for example. If what I remember is true, then for a much earlier tab order issue how it worked was said to be "as designed" by development.
Charlie: How about modifying the test case so it performs -- or fails, and give us the steps and describe how you want it to perform -- as you wrote in your initial posting?
I was talking only about the dfs.
This sample doesn't intend to be a complete one, it just wanted you to show that you can do without the Vis-function.
There is of course the possibility to remove a field from the tab-list .
The code in SAM_CreateComplete - sorry, that code was just to show, that you do not need a POST-Message to have your fields ordered at form startup.
Sorry that I was not clear enough for you ...
Yup, it is simply a field we want out of the tab order.
The field isn't disabled, just infrequently filled in.
On the rare occasion a user does want to put a value in the field, he/she clicks on it with the mouse.
Let's say 90% of the time, users don't want to put a value in the field, so they just want tabbing to "skip over" the rarely used field.
Alternatively, we could have placed that field last in the tab order, but that puts the field in a lousy spot in the code outline.
I'll see if I can put together a sample on some coffee break today.
Back to the app that I had to monkey around with to get VisWinSetTabOrder working ...
There are no other calls to VisWinSetTabOrder in the app, so nothing in that regard that could undo the VisWinSetTabOrder call I was making on SAM_Create.
Aside: is there any function call that would "reset" the tab order of child windows on a form back to the original tab order setup on the form ???
So there is something else about the processing going on that is either undoing my call to VisWinSetTabOrder, or something that is causing the "internal" assignment of tab order to get delayed (such that my call to VisWinSetTabOrder needs to be delayed.)
It would seem that it takes a series of unfortunate events to put a "timing kink" in my VisWinSetTabOrder call. That's going to take more than a coffee break to figure out.
Who is online
Users browsing this forum: Ccbot [Crawler] and 0 guests