Bugreport at :
http://bugs.freepascal.org/view.php?id=20442
-Tee-

Mailing lists / lazarus / 2011-10
6 messages · 4 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Bugreport at :
http://bugs.freepascal.org/view.php?id=20442
-Tee-
2011/10/9 Tommi Prami :
Bugreport at : ?http://bugs.freepascal.org/view.php?id=20442
If you use lazarus 0.9.31 from trunk, then read
http://wiki.lazarus.freepascal.org/Lazarus_0.99.0_release_notes#TCustomPageControl.2FTPageControl.OnPageChanged_were_removed
That page contains breaking changes, so read that before submitting a bug report.
Vincent
IMO the recent rename was bad, because the current TCustomTabControl is implemented as a TPageControl, incompatible with a (Delphi) TTabControl. I had hoped that the widgetset interface would allow to implement simple tabbed controls (without pages), and derive paged controls in the LCL, but nothing happened in that direction :-(
Most ComCtrls suffer from the duplicate storage of the items, in the widgets and in the controls. I'd be happy with the way how Delphi manages all items, using a *temporary* item list *only* while no widget exists - i.e. when such a control is loaded from a resource, or when it must be recreated later. On nowadays machines it will do no harm to refer to the properties stored in the widgets, which will be up-to-date and consistent all the time.
DoDi
2011/10/9 Tommi Prami : If you use lazarus 0.9.31 from trunk, then read…
OK,
I'll put this in Bugreport also, but the Event is not used in any way... And it is visible in the "Events list"...
And I checked the .lfm (the .dfm equivalent) and there was no trace of the Event also (I was thinking that maybe it is there and not in sync with code etc...
-TP-
IMO the recent rename was bad, because the current TCustomTabControl is implemented as a…
I had hoped that the widgetset interface would allow to implement simple
tabbed controls (without pages), and derive paged controls in the LCL, but nothing happened in that direction :-(
Wasnt you the one sending patches for the new ttabcontrol? But then stopped suddenly. Of course the new ttabcontrol will not fall from the sky, someone has to write it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111010/2be9551d/attachment.html>
Right. My patches implemented a Delphi compatible TTabControl, at least with the Win32 widgetset.
But then stopped suddenly.
Not suddenly, I can not implement widgetsets which are unavailable on my machine.
Of course the new ttabcontrol will not fall from the sky, someone has to write it.
The TTabControl was ready for use, provided that the widgetsets are updated accordingly. Without such updates the only solution for a TTabControl is a crippled TPageControl, with hidden pages. This workaround still exists, so what do you expect me to do more?
The intended roadmap was:
1) provide a Delphi compatible TTabControl, under a new name for now.
2) make it work with at least one widgetset.
--- this was what I have done already ---
3) make it work with the other widgetsets - not me!
4) replace the old TTabControl by the new one.
Renaming the old TCustomNotebook by TCustomTabControl was a bad decision, breaking the TTabControl events :-(
I'd suggest to revert the names to the original ones, and continue with step 3.
The final state could provide different implementations, depending on the widgetsets. Every widgetset can continue to use the workaround, until an unpaged tabcontrol can be made work with it. This would allow to compile Delphi applications without any changes, at least for the Win32 widgetset. The current workaround could be named e.g. TLazTabControl, indicating that it is not fully compatible with the Delphi control, but is available with all widgetsets.
DoDi