In 7.01 we have many multipage forms using "tabbed" pages. Using a Rev supplied stored procedured called at create time that sets the pagelist of any control suffixed with '_FIX', as well as hiding the verticle scroll bar and re-ordering the checkboxes with the "autotab" bitmaps.

This works beautifully except for a couple of gotchas:

1) When tabbing off the last control on a page focus does not go to the first control on the next page.

2) When IOOPTIONS=1 (enforce required fields at WRITE) focus is set to the first required control without data, however if that control is not on the 'active' page, the page on which the control is located is not made 'active'. This is particularly annoying since the error message give no clue as to which control is at fault and focus from the erring control will most likely be lost when tabbing through the pages.

Is there a ready solution to these 'gotchas'? Or should I forgoe using tabbed pages until 7.1?

If I have to resort to enforcing required fields in my own procedure, how can I determine what 'page' any particular control is painted on?

If this topic has been discussed previously, please point me to the relevant threads. Thanks.

As far as going to the next page when tabbing through the last control you should be able to put a lost fouc event on the control to go to the next page.

True, it would get tricky because I'd have to test that the 'new' focus is on first field of the new page and not a button, menu option or some other control on the current page.

Is there a way to determine what page a particular control is on given the id of the control? e.g. EDITLINE_50 is on page 3

Hi Warren. 7.1 will allow you to use the new menu item "Select Control" to select a control from a listbox. In the case of controls on tabs, when selected it will bring you to the control you selected even if it not on the first tab.

Bill

Hi again Warren. If you meant finding out what page a particular control is on at runtime, I do not know how you would find that. Perhaps someone else can enlighten us both.

Bill

Warren,

] Is there a way to determine what page a particular control is on given the id of the control?

In the old days you could determine that from the y coordinate of the control (even though I never quite found out why the values from pages 2 and upwards were exactly what they were). But tabbed pages in OI7 might be different from multipage and tabbed pages in earlier versions. I'm still at OI4, and currently haven't got a copy of OI7 installed, so I can't check myself.

If tabbed pages work well in OI7 I have an MDI-based tabbed interface I might be interested in converting. Then I might need answers to the same questions that you ask.

] True, it would get tricky because I'd have to test that the 'new' focus is on first field of the new page and not a button, menu option or some other control on the current page.

I'm not certain I get the exact point. Could you elaborate?

- Oystein -

The page is part of the y position.

You can see it in the orig_y property

if the control is on page 1, orig_y will look like 200

if the control is on page 2, orig_y will look like 200:1

if the control is on all pages it will look like it is on page 1

Thus

$Insert Logical

orig_y=Get_Property(CtrlEntId, 'ORIG_Y')

pageNr=field(orig_y, ':',2) + 1

Note:

The sysreposwins record for the window will show the page number in the POS_Y$ field for the prompt. There, controls on all pages will show a negative value for the page number, e.g. 200:-1

For more info on the structure of Sysreposwins records see the Sprezzatura Technical bulletin TR2, available as a Works download.

Bob

Ah ha! Thanks.

BTW: I looked for the tech report in the works download section but didn't see it listed.

] True, it would get tricky because I'd have to test that the 'new' focus is on first field of the new page and not a button, menu option or some other control on the current page.

]I'm not certain I get the exact point. Could you elaborate?

Suppose EDITLINE_20 is the last edit field on page one and EDITLINE_21 is the first on page two. We could not unconditionally send a PAGE 2 message and set focus to EDITLINE_21 when losing focus from EDITLINE_20. Focus could have been lost because the user wanted to change another control on page one, e.g. EDITLINE_5 or they Shift-tabbed to EDITLINE_19 or hit an accelerator key etc.

Warren,

If I make a multipage window in 4.1.2 the tab order runs through all pages and back again. Tabbing from the last control in a page brings up the next page. Tabbing from the last control in the last page brings up the first page again. Is all this different in 7.0.1?

Or does something get screwed up when that stored procedure you mention runs at create time?

- Oystein -

7.01 does not change to the next page when tabbing off the last control of a tabbed page. It cycles through the controls on page.

Warren,

If it's a temporary design flaw, and you can wait until it's fixed, then wait.

If you need proper tabbing now, let your multipage windows have a CREATE handler that fixes the tab order by changing the NEXT and PREVIOUS properties of the first and last controls on each page.

Does that sound difficult? I think perhaps it's dead easy. I believe the list of control names you find in the window's CTRLMAP property are sorted in tab order. Even if the actual tab order of 7.0.1 multipage windows loops back on itself for each page I would expect the order in CTRLMAP to be exactly what you want for your tab order. So let CREATE iron out the wrinkles in the following manner:

- get the list of control names from CTRLMAP

- loop through the list, and set the NEXT property of each control to the next name in the list, and the PREVIOUS property to the previous name. Remember to handle the special case of the very first and last controls, so they are NEXT and PREVIOUS to each other.

See how you don't need to know exactly which controls are first and last on each page?

If I am wrong about this you could take a more manual approach. You could hardcode it altogether, but myself I would go for a half manual, half automatic way:

- For each window put text controls FIRST and LAST on, say, the first page, so they are visible to you as a developer, and easy to maintain

- Set the text of FIRST to a comma-delimited list of names of the first controls on each page, and the text of LAST to a corresponding list of last controls

- Let the CREATE handler loop through the lists and fix the NEXT/PREVIOUS properties of the controls in the lists.

You must either make FIRST and LAST invisible (and turn on View | Show Invisible Controls in Form Designer), or let the CREATE handler set them invisible at runtime.

No matter which alternative you choose you can use same the CREATE handler for all your multipage windows. I'f you're adventurous you can make it a promoted handler.

(Hmmm. Does setting A's NEXT to B automatically set B's PREVIOUS to A? I don't think so, but I don't really remember.)

- Oystein -

I can wait for 7.1 tabs. I had just converted all the multipage screens to use the 7.01 scheme when I discovered the little idiosyncrasies such as this and the required field enforcement at Write event. Since we were going live with some screens, I took out the tabbed pages for now.

View this thread on the Works forum...