Forum > LCL
TWSButton descendance
lagprogramming:
I have a patch that fixes custom-drawn's TButton's empty caption but there is an issue. I've looked at lcl/widgetset/wsstdctrls.pp and I've noticed the following lines:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- TWSButtonControl = class(TWSWinControl) published class function GetDefaultColor(const AControl: TControl; const ADefaultColorType: TDefaultColorType): TColor; override; end; { TWSButton } TWSButton = class(TWSButtonControl) published class procedure SetDefault(const AButton: TCustomButton; ADefault: Boolean); virtual; class procedure SetShortCut(const AButton: TCustomButton; const ShortCutK1, ShortCutK2: TShortCut); virtual; end; TWSButtonClass = class of TWSButton; { TWSCustomCheckBox } TWSCustomCheckBox = class(TWSButtonControl) published class function RetrieveState(const ACustomCheckBox: TCustomCheckBox): TCheckBoxState; virtual; class procedure SetShortCut(const ACustomCheckBox: TCustomCheckBox; const ShortCutK1, ShortCutK2: TShortCut); virtual; class procedure SetState(const ACustomCheckBox: TCustomCheckBox; const NewState: TCheckBoxState); virtual; class procedure SetAlignment(const ACustomCheckBox: TCustomCheckBox; const NewAlignment: TLeftRight); virtual; end; TWSCustomCheckBoxClass = class of TWSCustomCheckBox; { TWSCheckBox } TWSCheckBox = class(TWSCustomCheckBox) published end;
Notice that as an example, TWSCheckBox is a descendant of TWSCustomCheckBox, but TWSButton is not a descendant of a TWSCustomButton.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- TWSEdit = class(TWSCustomEdit) published end; { TWSMemo } TWSMemo = class(TWSCustomMemo) published end;TWSMemo is a descendant of TWSCustomMemo, TWSEdit of TWSCustomEdit, and so on. It's TWSButton the one that looks out of ordinary.
Isn't this a bug in LCL? :-\ Shouldn't TWSButton have been a descendant of TWSCustomButton where TWSCustomButton would have been a descendant of TWSButtonControl, like TWSCheckBox is?
lagprogramming:
I'm still looking forward for an answer.
Maybe an experienced LCL developer can explain why TWSButton isn't a descendant of TWSCustomButton.
zeljko:
Maybe bug from the beginning of WS. Maybe Mattias or Marc know exact reason for this.
Marc:
I don't recall why, but I think the main reason is that a WS custom is not of much use. The WS has to implement the "real thing" and not some abstract control. So if you want to derive your control from a custom control, you want specific features which have to be available in the widgetsets too. So in most cases you need a specific WS class as well.
The fact that there exist TWSCustom classes might be that they have been added later either simply as counterpart of the LCL one, or that there indeed was a shared piece of functionality
Martin_fr:
The question is, does it cause a problem? And if so, what problem.
TCustomSomething is usually the implementation of Something, and TSomething only publishes the relevant properties => that is so you can have a T[Custum]SpecialSomething, which does not publish all the properties that TSomething published.
But in the TWS.... classes, there is no such thing as publishing properties. (there is published, but not sure why... where it is used / there should be no need to un-publish).
So as pointed out, the TWS... classes usually do not need that distinction.
It seems that for many classes they have been added. If really matters to you why, then use git blame to see when (and maybe if mentioned in commit message: why) they were added. Or maybe they were added in the beginning, and eventually it was realized that there was no need.
That said, the way WS classes work has at times been misunderstood, and there could be commits that are tainted by that.
In any case, I would classify it as: If it ain't broke, ...
Navigation
[0] Message Index
[#] Next page