Dear guest !

Welcome to Team Developer Community Forum. A place created by the community, for the community !

This is a resource for Q & A and discussion about everything related to OpenText Gupta Team Developer, SqlBase, TD Mobile and Report Builder.
It is the alternative for the OpenText customer forums which can only be accessed with an active support contract.

Please register your account now. It will make you part of the active community.
Also, this guest message will not be displayed for registered users.

As a bonus, registered users have access to the 'Newsgroups' subforum, holding 10 years worth of posts from the good old Gupta newsgroups.

Having an account gives you the opportunity to ask questions and get help from others.
We hope this free gathering will help you and the community getting forward!

Best regards,
The forum site admins.

FYI: VisWinSetTabOrder

General discussion forum about all things Team Developer 5.x
Post Reply
Charlie
Canada
Posts: 39
Joined: 07 Mar 2017, 18:52
Location: Fredericton, New Brunswick, Canada

FYI: VisWinSetTabOrder

Post by Charlie » 22 Mar 2017, 11:29

"The Problem"

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.

Duh. Timing...

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.

"The Solution"

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.
Last edited by Charlie on 27 Mar 2017, 10:36, edited 1 time in total.
A little trick to help direct folk from old Gupta forum to this one: Link to post

Jeff Luther
Site Admin
United States of America
Posts: 74
Joined: 04 Mar 2017, 18:34
Location: Palm Springs, California
Contact:

Re: FYI: VisWinSetTabOrder

Post by Jeff Luther » 22 Mar 2017, 15:31

Interesting to read that the SAM_CreateComplete msg. sent to the parent form wasn't late enough to (re)set tab order for the child control, Charlie. I always thought that the complete msg. was just that: Any create/init/setup for the form and children was in fact done.

So this didn't work?

Code: Select all

Form Window: ...
    On SAM_CreateComplete
        Call VisWinSetTabOrder(<field name/handle>, hWndNULL)
I have myself written and seen this coded in by others as well, often defined within a form's class for this msg:

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 )
And then in any individual child control, trap PM_CreateComplete and do any last-minute/final processing on a per child control basis:

Code: Select all

Data Field:...
    PM_CreateComplete
        Call VisWinSetTabOrder( hWndItem, hWndNULL )
That's a good generic way to guarantee that the msg. is really sent last and late enough that any internal init. and setup of the form and its children is complete.

Thanks for the heads-up, and good to know about what you found out and for future reference.
Jeff Luther @ PC Design
Palm Springs, California
TD info. & samples: http://www.jeffluther.net/TD/

Charlie
Canada
Posts: 39
Joined: 07 Mar 2017, 18:52
Location: Fredericton, New Brunswick, Canada

Re: FYI: VisWinSetTabOrder

Post by Charlie » 22 Mar 2017, 19:00

That's right. Upon SAM_CreateComplete of the form window, a call to VisWinSetTabOrder had no effect.

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 ???)
A little trick to help direct folk from old Gupta forum to this one: Link to post

Jeff Luther
Site Admin
United States of America
Posts: 74
Joined: 04 Mar 2017, 18:34
Location: Palm Springs, California
Contact:

Re: FYI: VisWinSetTabOrder

Post by Jeff Luther » 26 Mar 2017, 20:39

Maybe something fixed beyond TD5.2SP3, or something that just exists with TD5.2SP3
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?
Jeff Luther @ PC Design
Palm Springs, California
TD info. & samples: http://www.jeffluther.net/TD/

Charlie
Canada
Posts: 39
Joined: 07 Mar 2017, 18:52
Location: Fredericton, New Brunswick, Canada

Re: FYI: VisWinSetTabOrder

Post by Charlie » 27 Mar 2017, 10:35

Jeff Luther wrote:
26 Mar 2017, 20:39
Maybe something fixed beyond TD5.2SP3, or something that just exists with TD5.2SP3
... Did you code any of those and try it?
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.
A little trick to help direct folk from old Gupta forum to this one: Link to post

Charlie
Canada
Posts: 39
Joined: 07 Mar 2017, 18:52
Location: Fredericton, New Brunswick, Canada

Re: FYI: VisWinSetTabOrder

Post by Charlie » 27 Mar 2017, 10:44

Jeff Luther wrote:
26 Mar 2017, 20:39
Maybe something fixed beyond TD5.2SP3, or something that just exists with TD5.2SP3
... if it's a bug with SP3 other or otherwise ...
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.
A little trick to help direct folk from old Gupta forum to this one: Link to post

H3PO4
Germany
Posts: 21
Joined: 10 Mar 2017, 07:53
Location: Rohlstorf, Germany
Contact:

Re: FYI: VisWinSetTabOrder

Post by H3PO4 » 04 May 2017, 14:07

Hi Charlie, hi Jeff,

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.

Regards
Henning
Attachments
HfsSetTabOrder.zip
(5.39 KiB) Downloaded 7 times

Jeff Luther
Site Admin
United States of America
Posts: 74
Joined: 04 Mar 2017, 18:34
Location: Palm Springs, California
Contact:

Re: FYI: VisWinSetTabOrder

Post by Jeff Luther » 04 May 2017, 15:20

ohne df2 will not do as expected
What do you expect? I modified your test to remove that reordering on SAM_CreateComplete; I like to have a known starting point.
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 needed to take a field out of the keyboard-tabbing sequence
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.

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?
Attachments
HfsSetTabOrder-JL-MOD.zip
(5.44 KiB) Downloaded 6 times
Jeff Luther @ PC Design
Palm Springs, California
TD info. & samples: http://www.jeffluther.net/TD/

H3PO4
Germany
Posts: 21
Joined: 10 Mar 2017, 07:53
Location: Rohlstorf, Germany
Contact:

Re: FYI: VisWinSetTabOrder

Post by H3PO4 » 05 May 2017, 06:25

Hi Jeff,

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 :) ...

Regards
Henning

Charlie
Canada
Posts: 39
Joined: 07 Mar 2017, 18:52
Location: Fredericton, New Brunswick, Canada

Re: FYI: VisWinSetTabOrder

Post by Charlie » 05 May 2017, 10:33

Jeff Luther wrote:
04 May 2017, 15:20
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.
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.
A little trick to help direct folk from old Gupta forum to this one: Link to post

Charlie
Canada
Posts: 39
Joined: 07 Mar 2017, 18:52
Location: Fredericton, New Brunswick, Canada

Re: FYI: VisWinSetTabOrder

Post by Charlie » 05 May 2017, 11:28

Crap. No issues with the test app I'm putting together.

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.
A little trick to help direct folk from old Gupta forum to this one: Link to post

Post Reply

Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest