Hi,

I've just added TProgressBar support for LCL-fpGUI, but I find the widgetset design extremely confusing.

For example, I implemented TFpGuiWSProgressBar.SetPosition() - the component is painted on the form, but the position property was never set. Adding a SendDebug() call inside TFpGuiWSProgressBar.SetPosition() I noticed that it is _never_ called. Not at the creation of the form, and not when you set the ProgressBar.Position seems to go via the ApplyUpdates() method. I could confirm this inside the progressbar.inc file where TCustomProgressBar class is implemented. So what is TWSProgressBar.SetPosition() then used for, and when is it called?

I had a look at the LCL-Qt widgetset implementation for TProgressBar. I can see code duplication (setting the Position information) in ApplyUpdates and SetPosition() as well.

Regards,
- Graeme -

Yes, that's something pretty weird in TProgressBar implementation.I've asked about it on mailing list few months ago afair, but no answer.

zeljko

zeljko wrote

Yes, that's something pretty weird in TProgressBar implementation.I've asked about it on mailing list few months ago afair, but no answer.

Also the ApplyUpdates() idea is extremely inefficient. You change one property in TProgressBar, and at the widgetset level, every single property of TProgressBar has to be checked and assigned to the widgetset progressbar component. A crazy design.

Regards,
- Graeme -

Ping... to core developers.

Regards,
- Graeme -

Ping... to core developers.

It can be deleted.
Do you need it?

Mattias

Mattias Gaertner wrote

It can be deleted. Do you need it?

No I don't need TFpGuiWSProgressBar.SetPosition(), because of the weird TProgressBar design, where every property change goes via ApplyUpdates(). I just implemented it because it was a blank virtual method from a base class.

But this raises the other question. Why is TCustomProgressBar implemented so different and inefficient.... every property change going through TCustomProgressBar.ApplyUpdates. I say inefficient, because now all the backend widgetsets must check and set all properties of the ProgressBar widget, even if only a single property value has changed.

I ran git-blame to see when it was introduced, and by whom. But the code predates the SubVersion repository.

Regards,
- Graeme -

Yes, clearly it could be improved.