Skip to main content

[Migrated content. Thread originally posted on 09 November 2004]

Is it just me? Shouldn't the tab control be simpler to implement? It's bothered me for a while, but since I've only used it on occasion I've just lived with it. Now that I'm using it more, it just seems like it could be easiar.

For instance, shouldn't each tab page automatically act as a virtual container for a group of controls that display on it without extra coding for controlling group section visibilty in an event handler?

It seems like the screen section could accomplish this by optionally allowing a group item(a group of controls) to be referenced in the TAB-TO-ADD property of a Tab control. Then, the DISPLAY statement could automatically(no need for event coding) control visibility of controls on tab pages based upon which tab was active.

For instance,


01 TAB-FORM.
   03 MY-TAB,               TAB-CONTROL
      COL                   10 PIXELS
      LINE                  10 PIXELS
      LINES                 200 PIXELS
      SIZE                  200 PIXELS
      TAB-TO-ADD            IS (TAB-PAGE-1, TAB-PAGE-2)
      EVENT                 PROCEDURE TAB-EVENT
      VALUE                 WS-ACTIVE-PAGE.

   03 TAB-PAGE-1.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 1"
         LEFT.

   03 TAB-PAGE-2.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 2"
         LEFT.


In this example, when DISPLAY TAB-FORM statement executes, only the controls on TAB-PAGE-1 would be visible. TAB-PAGE-2 controls remain invisible until CMD-TABCHANGED occurs to activate it(without need for event handler code) and then TAB-PAGE-1 controls become invisibile.

Yes, I know, I did not specify a title for the tabs. Maybe a new property like TAB-TITLES = ("Tab1", "Tab2") or something?

But does any of this make sense, would it be helpful to anyone?

[Migrated content. Thread originally posted on 09 November 2004]

Is it just me? Shouldn't the tab control be simpler to implement? It's bothered me for a while, but since I've only used it on occasion I've just lived with it. Now that I'm using it more, it just seems like it could be easiar.

For instance, shouldn't each tab page automatically act as a virtual container for a group of controls that display on it without extra coding for controlling group section visibilty in an event handler?

It seems like the screen section could accomplish this by optionally allowing a group item(a group of controls) to be referenced in the TAB-TO-ADD property of a Tab control. Then, the DISPLAY statement could automatically(no need for event coding) control visibility of controls on tab pages based upon which tab was active.

For instance,


01 TAB-FORM.
   03 MY-TAB,               TAB-CONTROL
      COL                   10 PIXELS
      LINE                  10 PIXELS
      LINES                 200 PIXELS
      SIZE                  200 PIXELS
      TAB-TO-ADD            IS (TAB-PAGE-1, TAB-PAGE-2)
      EVENT                 PROCEDURE TAB-EVENT
      VALUE                 WS-ACTIVE-PAGE.

   03 TAB-PAGE-1.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 1"
         LEFT.

   03 TAB-PAGE-2.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 2"
         LEFT.


In this example, when DISPLAY TAB-FORM statement executes, only the controls on TAB-PAGE-1 would be visible. TAB-PAGE-2 controls remain invisible until CMD-TABCHANGED occurs to activate it(without need for event handler code) and then TAB-PAGE-1 controls become invisibile.

Yes, I know, I did not specify a title for the tabs. Maybe a new property like TAB-TITLES = ("Tab1", "Tab2") or something?

But does any of this make sense, would it be helpful to anyone?
Yes it would help alot.

I'm using many tabs in my application and I'm struggling with it for a long time now.

If a control on tab-1 is depending on a visible-variable, when tabs are changed, the control of tab-1 is still visible so I have to put some code around to make it unvisible and visa versa.

A property like tab-title would be more then helpfull because our application has the opportunity to change languages, so for now, titles on tabs aren't changed.

I would suggest another enhancement.

Let's say a Tab-control has 3 tabs. When you delete tab-2, it would be hence if you just could use 'add tab-2' again.
For now, tabs that can be deleted are put at the back of the control so it's a work around but still...

[Migrated content. Thread originally posted on 09 November 2004]

Is it just me? Shouldn't the tab control be simpler to implement? It's bothered me for a while, but since I've only used it on occasion I've just lived with it. Now that I'm using it more, it just seems like it could be easiar.

For instance, shouldn't each tab page automatically act as a virtual container for a group of controls that display on it without extra coding for controlling group section visibilty in an event handler?

It seems like the screen section could accomplish this by optionally allowing a group item(a group of controls) to be referenced in the TAB-TO-ADD property of a Tab control. Then, the DISPLAY statement could automatically(no need for event coding) control visibility of controls on tab pages based upon which tab was active.

For instance,


01 TAB-FORM.
   03 MY-TAB,               TAB-CONTROL
      COL                   10 PIXELS
      LINE                  10 PIXELS
      LINES                 200 PIXELS
      SIZE                  200 PIXELS
      TAB-TO-ADD            IS (TAB-PAGE-1, TAB-PAGE-2)
      EVENT                 PROCEDURE TAB-EVENT
      VALUE                 WS-ACTIVE-PAGE.

   03 TAB-PAGE-1.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 1"
         LEFT.

   03 TAB-PAGE-2.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 2"
         LEFT.


In this example, when DISPLAY TAB-FORM statement executes, only the controls on TAB-PAGE-1 would be visible. TAB-PAGE-2 controls remain invisible until CMD-TABCHANGED occurs to activate it(without need for event handler code) and then TAB-PAGE-1 controls become invisibile.

Yes, I know, I did not specify a title for the tabs. Maybe a new property like TAB-TITLES = ("Tab1", "Tab2") or something?

But does any of this make sense, would it be helpful to anyone?
Hans,
I think what would take care of putting tabs back is to be able to have an INSERTION-INDEX just like a listbox. This way you can add a tab in the order that you want.

[Migrated content. Thread originally posted on 09 November 2004]

Is it just me? Shouldn't the tab control be simpler to implement? It's bothered me for a while, but since I've only used it on occasion I've just lived with it. Now that I'm using it more, it just seems like it could be easiar.

For instance, shouldn't each tab page automatically act as a virtual container for a group of controls that display on it without extra coding for controlling group section visibilty in an event handler?

It seems like the screen section could accomplish this by optionally allowing a group item(a group of controls) to be referenced in the TAB-TO-ADD property of a Tab control. Then, the DISPLAY statement could automatically(no need for event coding) control visibility of controls on tab pages based upon which tab was active.

For instance,


01 TAB-FORM.
   03 MY-TAB,               TAB-CONTROL
      COL                   10 PIXELS
      LINE                  10 PIXELS
      LINES                 200 PIXELS
      SIZE                  200 PIXELS
      TAB-TO-ADD            IS (TAB-PAGE-1, TAB-PAGE-2)
      EVENT                 PROCEDURE TAB-EVENT
      VALUE                 WS-ACTIVE-PAGE.

   03 TAB-PAGE-1.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 1"
         LEFT.

   03 TAB-PAGE-2.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 2"
         LEFT.


In this example, when DISPLAY TAB-FORM statement executes, only the controls on TAB-PAGE-1 would be visible. TAB-PAGE-2 controls remain invisible until CMD-TABCHANGED occurs to activate it(without need for event handler code) and then TAB-PAGE-1 controls become invisibile.

Yes, I know, I did not specify a title for the tabs. Maybe a new property like TAB-TITLES = ("Tab1", "Tab2") or something?

But does any of this make sense, would it be helpful to anyone?
It's funny, I don't use AcuBench often because I'm so comfortable with Multi-Edit, but I noticed that AcuBench handles code generation for the scenario I described with the Tab control pages really well. Kudos to Acucorp on that.

[Migrated content. Thread originally posted on 09 November 2004]

Is it just me? Shouldn't the tab control be simpler to implement? It's bothered me for a while, but since I've only used it on occasion I've just lived with it. Now that I'm using it more, it just seems like it could be easiar.

For instance, shouldn't each tab page automatically act as a virtual container for a group of controls that display on it without extra coding for controlling group section visibilty in an event handler?

It seems like the screen section could accomplish this by optionally allowing a group item(a group of controls) to be referenced in the TAB-TO-ADD property of a Tab control. Then, the DISPLAY statement could automatically(no need for event coding) control visibility of controls on tab pages based upon which tab was active.

For instance,


01 TAB-FORM.
   03 MY-TAB,               TAB-CONTROL
      COL                   10 PIXELS
      LINE                  10 PIXELS
      LINES                 200 PIXELS
      SIZE                  200 PIXELS
      TAB-TO-ADD            IS (TAB-PAGE-1, TAB-PAGE-2)
      EVENT                 PROCEDURE TAB-EVENT
      VALUE                 WS-ACTIVE-PAGE.

   03 TAB-PAGE-1.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 1"
         LEFT.

   03 TAB-PAGE-2.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 2"
         LEFT.


In this example, when DISPLAY TAB-FORM statement executes, only the controls on TAB-PAGE-1 would be visible. TAB-PAGE-2 controls remain invisible until CMD-TABCHANGED occurs to activate it(without need for event handler code) and then TAB-PAGE-1 controls become invisibile.

Yes, I know, I did not specify a title for the tabs. Maybe a new property like TAB-TITLES = ("Tab1", "Tab2") or something?

But does any of this make sense, would it be helpful to anyone?
It's funny, I don't use AcuBench often because I'm so comfortable with Multi-Edit, but I noticed that AcuBench handles code generation for the scenario I described with the Tab control pages really well. Kudos to Acucorp on that.

[Migrated content. Thread originally posted on 09 November 2004]

Is it just me? Shouldn't the tab control be simpler to implement? It's bothered me for a while, but since I've only used it on occasion I've just lived with it. Now that I'm using it more, it just seems like it could be easiar.

For instance, shouldn't each tab page automatically act as a virtual container for a group of controls that display on it without extra coding for controlling group section visibilty in an event handler?

It seems like the screen section could accomplish this by optionally allowing a group item(a group of controls) to be referenced in the TAB-TO-ADD property of a Tab control. Then, the DISPLAY statement could automatically(no need for event coding) control visibility of controls on tab pages based upon which tab was active.

For instance,


01 TAB-FORM.
   03 MY-TAB,               TAB-CONTROL
      COL                   10 PIXELS
      LINE                  10 PIXELS
      LINES                 200 PIXELS
      SIZE                  200 PIXELS
      TAB-TO-ADD            IS (TAB-PAGE-1, TAB-PAGE-2)
      EVENT                 PROCEDURE TAB-EVENT
      VALUE                 WS-ACTIVE-PAGE.

   03 TAB-PAGE-1.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 1"
         LEFT.

   03 TAB-PAGE-2.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 2"
         LEFT.


In this example, when DISPLAY TAB-FORM statement executes, only the controls on TAB-PAGE-1 would be visible. TAB-PAGE-2 controls remain invisible until CMD-TABCHANGED occurs to activate it(without need for event handler code) and then TAB-PAGE-1 controls become invisibile.

Yes, I know, I did not specify a title for the tabs. Maybe a new property like TAB-TITLES = ("Tab1", "Tab2") or something?

But does any of this make sense, would it be helpful to anyone?
It's funny, I don't use AcuBench often because I'm so comfortable with Multi-Edit, but I noticed that AcuBench handles code generation for the scenario I described with the Tab control pages really well. Kudos to Acucorp on that.

[Migrated content. Thread originally posted on 09 November 2004]

Is it just me? Shouldn't the tab control be simpler to implement? It's bothered me for a while, but since I've only used it on occasion I've just lived with it. Now that I'm using it more, it just seems like it could be easiar.

For instance, shouldn't each tab page automatically act as a virtual container for a group of controls that display on it without extra coding for controlling group section visibilty in an event handler?

It seems like the screen section could accomplish this by optionally allowing a group item(a group of controls) to be referenced in the TAB-TO-ADD property of a Tab control. Then, the DISPLAY statement could automatically(no need for event coding) control visibility of controls on tab pages based upon which tab was active.

For instance,


01 TAB-FORM.
   03 MY-TAB,               TAB-CONTROL
      COL                   10 PIXELS
      LINE                  10 PIXELS
      LINES                 200 PIXELS
      SIZE                  200 PIXELS
      TAB-TO-ADD            IS (TAB-PAGE-1, TAB-PAGE-2)
      EVENT                 PROCEDURE TAB-EVENT
      VALUE                 WS-ACTIVE-PAGE.

   03 TAB-PAGE-1.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 1"
         LEFT.

   03 TAB-PAGE-2.
      05 LABEL
         COL                   30 PIXELS
         LINE                  50 PIXELS
         TITLE                 "This is page 2"
         LEFT.


In this example, when DISPLAY TAB-FORM statement executes, only the controls on TAB-PAGE-1 would be visible. TAB-PAGE-2 controls remain invisible until CMD-TABCHANGED occurs to activate it(without need for event handler code) and then TAB-PAGE-1 controls become invisibile.

Yes, I know, I did not specify a title for the tabs. Maybe a new property like TAB-TITLES = ("Tab1", "Tab2") or something?

But does any of this make sense, would it be helpful to anyone?
Dan,

No it's not just you!

We have just started using the GUI side of AcuCobol after almost 10 years of coding in the character version.

We've found it really hard going and some of the behaviour does not seem logical.

With tabs the whole page visibilty thing can get very complicated, especially with the 'bug' that sub-control visible flags override their group visible flags. That one just doesn't make any sense. Why would you want to make a whole screen invisible except for one control on that page?

We also don't understand the fact that tab controls have to come last in the screen section for them to be on the 'bottom'.

I guess, once you get past these it all seems to work ok.
Terms & ConditionsAccessibility statement