The implementation of the TTabControl seems to cause headaches, and reveals wrong assumptions of the devlopers about the behaviour of that control :-(

When I recently submitted an patch, with a new implementation of the TTabControl (named TTabs in the patch), this implementation was tested with the Win32 widgetset, and was fully compatible with the Delphi TTabControl - in contrast to any preceding implementation.

Felipe acted a bit too fast, and replaced the TTabControl by the new implementation, without waiting for the complete implementation with all widgetsets. The consequential problems showed up very soon :-(

When consequently problems with other widgetsets occured, he removed the intented implementation of TTabs (TNewTabControl), making it unusable at all. This step was undone later.

When it turned out that the IDEInspector uses a TTabControl, and stopped working (#19803) due to an misplaced override of ChildClassAllowed, this problem was not fixed in the suggested and obvious way (by moving that method into TPageControl). Instead the wrong assumption was stated, that a TTabControl cannot have child controls - what is not true for a Delphi compatible control.


So where are we now? We are back to the old TTabControl, that is not Delphi compatible, and have a TNewTabControl without an designer. Was this worth all the trouble?

IMO we should accept that a Delphi compatible TTabControl doesn't exist yet, for widgetsets other than Win32. What can/should we do, when it turns out that such a control can not be implemented in all widgetsets?


Why not offer the new implementation (TTabs/TNewTabControl) as TTabControl, to make Delphi migrants happy, and restrict its use to only the supported widgetsets? At the same time the old implementation can be renamed into TLazTabControl, that is not fully Delphi compatible, but immediately usable with all widgetsets?

And since the old TTabControl and TNotebook effectively share the same code, except for the control that shows the tabs, it would be a good idea to merge both into a common base class. The difference between both controls is implemented in their Pages classes (TUNBPages, TTabControlNoteBookStrings), so that effectivly only their constructors have to be different, where this object is created. An even simpler solution were to make the tabs switchable ON/OFF.

More things can be simplified, in detail the difference between visible and invisible pages, which applies *only* to the TPageControl. By moving that part out of the widgetsets into TPageControl, the implementation of the widgetsets and all TCustomTabControl descendants could be simplified a lot. Then also the restrictions would become more obvious, introduced by the various widgetsets.

DoDi


--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply via email to