WSxxxxx and custom controls.

[taazz]

Ok, I'm officially blind, I've been chasing around my tail the last half hour trying to understand how the WSxxxxx and the component link works.

Ctrl_clicking all over the lcl map following leads about the process and always fall upon either empty methods or the dreaded WSFactory unit where everything is declared as an external link.

Is any one brave enough to explain to me how this think works?
Let me make this clear
objective :
  Create a ButtonEdit control with the button inside the editor and not on the side as it is the default stock control that comes with lcl.

clyphs, image lists, events all in the basic package.

Final state :A ButtonEdit that has two buttons in any side of the edit control (left and right) they can be both at one side or one at each side The button class should be dynamic, for now a virtual method getButtonClass should be enough.


Lets take it easy for starters I want to create a custom control that will paint in its background a grid and no I don't want to override erasebackground of a tcustomcontrol descendant I want a small step by step list to create a TCustomControl descendand using the WSxxxxx analogy to get me started.
One more thing forget all that variables and paths you can set and all that, I want a static solution to get the hang of things and then I'll learn how to make them dynamic.

Although I have created some demo components based on existing lcl component and overriding a few methods here and there I would prefer to go a bit deeper this time around and learn how to get the max speed out of my components I will need it later on.

Thank you for any help.

Regards
Jo.

[taazz]

I think I have over done it on this post. Let me make it a bit easier. I'm looking for code that creates and hanldes the TFloatSpinEdit control. I want the portion that creates the spin edit(s) and attach them to the custom edit anyone has seen this code anywhere?

Regards

[Blaazen]

@ Ctrl_clicking all over the lcl map following leads about the process and always fall upon either empty methods or the dreaded WSFactory unit where everything is declared as an external link.

The reason is that LCL is an abstract framework, it depends on the underlaying widgetset.

About TEditButton: a week ago I filled a bugreport about its anchoring: http://bugs.freepascal.org/view.php?id=23029. Juha said that the component will be redesigned in future.

SpinEdits are AFAIK also provided by widgetset so you probably cannot find such code in LCL.

[taazz]

Thank you for replying, you lifted my spirit a bit.

My problem is not the spinedit control or that lcl is an abstract framework, what I was asking, although not very eloquently, is to understand the mechanism of linking the widget set to the abstraction layer.
So far everything seems like compiler magic to me and that is not good. I need to see how the link between the lcl and widget set is made in order for me to understand how to create combined components. I took spinedit as an example because that was a sample of a component created by two others in Delphi.

The current implementation of buttonedit although limited is an elegant solution to a few problems but it is a bad solution for custom combo boxes.
Let me make this clear I do not want to subclass a combo box I just want it to look like one.

My curent implementaion requires to much code duplication to be of any real us on a commercial application. So I was hopping to create a more compound solution.

regards
Jo