For my attempt to fix the problems in the gtk2 TabControl implementation I need some background information. Can anybody help me, or continue my started update?

In the first step I try to keep the dummy page, that is created together with the notebook widget, and use it for all tabs. I also managed to have the associated dummy tab invisible, but at sudden the implementation started to behave inconsistenly. Sometimes adding tabs (in code) works, but in most cases no tabs are
the code to the previously working implementation didn't help, so that it looks like some random behaviour, as known from uninitialized local variables.

Concrete questions:

- What's the purpose of the page widget, required in many gtk_notebook procedures?

- How is the page Handle defined and managed?
Is it the address of the associated gtk widget?

In my TabCtrl model I use a dummy LCL page (TCustomPage) to transfer parameters to the widgetset. In the Win32 widgetset I could prevent code from dealing with a page without an allocated Handle, but this seems to cause trouble with gtk2. Since now two dummy pages are used, one in the LCL code and one in the gtk2 code, can I assign the "handle" of the gtk2 dummy page widget to the LCL dummy page? How? Can I simply assign the pointer to the page widget to the TCustomPage.Handle?

- How does the gtk2 widgetset determine the ClientRect (of a notebook)? The reported ClientWidth and ClientHeight look good (smaller than the notebook Width and Height), regardless of whether the added tabs are shown or invisible. Could it be that the client origin is wrong, i.e. the dummy page sits at the topleft of the control and makes the tabs invisible?

- When I put an button on a TabCtrl, at design time, that button also is visible at runtime, regardless of whether the tabs themselves are shown or invisible. This seems to indicate that the dummy page widget is the parent of the button.

I can upload the patch with the current state of my gtk2 modifications and a test program, that shows both a TPageControl and TNewTabControl side by side, for the verification that the modifications do not affect the behaviour of the page control.

DoDi

It looks as if the random problem was caused by designtime tabs. The gtk2 designer does not yet work properly, and strings added to the TabControl.Tabs will prevent all tabs from becoming visible. Can somebody find out why?

I've just uploaded the gtk2 patch as NewTab1.patch. Apply and rebuild Lazarus, before using the new tabcontrol with gtk2.

DoDi

There is something, however, that I would like to clarify.

What exactly is wrong with the current TTabControl that you want to fix? What exactly does it do that you expect it to do differently?

I know that the class hierarchy is wrong, but I am not sure if this cannot be fixed by simply overriding for example the handle creating and making it create a TCustomControl Widget and then custom paint it like now.

What I want to clarify is if you are really implementing TTabControl or a new component. If it is a new component, what exactly should it do? If it is TTabControl, is it 100% compatible with Delphi? Will existing Lazarus code which uses TTabControl keep running?

Hans-Peter Diettrich wrote

Concrete questions: - What's the purpose of the page widget, required in many gtk_notebook procedures?

Could you show the concrete place in our code base which you are talking about?

By gtk_notebook* do you mean Gtk rountines?

- How is the page Handle defined and managed? Is it the address of the associated gtk widget?

The Handle is usually a PGtkWidget pointing to the widget representing the client area if I am not mistaken. There is a function GetFixedWidget, or something like that, to obtain the top-level widget for the control, when it is composed by multiple widgets. For pages I'd guess that they are composed by only 1 widget.

There is something, however, that I would like to clarify. What exactly is wrong with the current TTabControl that you want to fix? What exactly does it do that you expect it to do differently?

I started with a test program in Delphi, and used it to test the Lazarus TTabControl. And because the Lazarus component didn't pass the test, I started to update the Win32 widget to behave like in Delphi.

The biggest issue is the container property of a TTabControl, that allows to put any controls into its Tabs.Objects[], and to make one of these controls visible by selecting its associated tab. This behaviour is e.g. required for notebook docking. It also should be possible to put a single control (memo...) into a TTabControl, and to update its content according to the selected tab.

I could not yet achieve this compatible behaviour with gtk2, where child controls of a TTabControl cannot be made visible by simply switching their Visibility - i.e. by the procedure applicable to every container control.

It seems to be possible, though, to have components added to the TTabControl at design time, which stay visible when tabs are added later. This behaviour is broken when pages (TTabSheets) are added for every tab, or when components are added later, after tabs have been created.

IOW a TTabSheet should have a single client area, regardless of the number of added tabs, and it should be possible to put components into that area at runtime, by setting ctrl.Parent:=TabCtrl.

I know that the class hierarchy is wrong, but I am not sure if this cannot be fixed by simply overriding for example the handle creating and making it create a TCustomControl Widget and then custom paint it like now.

Can you find solutions for the above scenarios (basic behaviour)?

What I want to clarify is if you are really implementing TTabControl or a new component. If it is a new component, what exactly should it do? If it is TTabControl, is it 100% compatible with Delphi?

As you can see from above scenarios, I *only* want a TTabControl with *full* Delphi compatibility - not less and not more. More can be added at any time, while less is tolerable only when there exists no way around the different behaviour of other widgetsets.

Will existing Lazarus code which uses TTabControl keep running?

That's another issue, depending on which implementation the code relies. When it relies on the old (Delphi incompatible) behaviour, the code should either be updated to use the old (Lazarus specific) control (easy way), or the code has to be modified to use the Delphi compatible control (may be harder, but also may result in less code with less workarounds). E.g. the handling of the Z-order of the pages can be removed from the LCL high-level code, because nothing like that is required for the Win32 widgetset, and can be moved into the other widgetsets, as far as it is definitely required there.

BTW the old TTabControl designer works perfectly with the new Win32 widget, while it trashes or crashes with e.g. the gtk2 widgetset - either it crashes at design time, or the application will crash when the component is the widgetsets *should* be
made Delphi/Win32 compatible, so that the designer stays independent from the widgetset.

DoDi

Yes. When it's required to supply both the notebook and a page in a call of a Gtk routine, does this mean that the same page widget can be used safely for every tab of a notebook?

And can this widget then be used for the client area of the notebook, so that further components can have it as their parent?

DoDi

Hans-Peter Diettrich wrote

Yes. When it's required to supply both the notebook and a page in a call of a Gtk routine, does this mean that the same page widget can be used safely for every tab of a notebook?

No idea, you can either just try it, or ask at the gtk forum:

http://www.gtkforums.com/

The documentation doesn't say anything about this:

http://developer.gnome.org/gtk/2.24/GtkNotebook.html#gtk-notebook-append-page

And can this widget then be used for the client area of the notebook, so that further components can have it as their parent?

I think that for this the Handle would need to point to the client area and not to the notebook itself (not 100% sure, however). But it will get very nasty to maintain a common code base with TPageControl then, because not even the Handle will be the same.

There is always the possibility of starting a new WS implementation only for TTabControl...