Property Provider

[Destiser]

Hello,

I'm coming from .NET and there you can create a component, a so called "property provider", where you can define some properties to provide to other controls (Widgets). You drag the component on your form and then magically all controls on that form have extra properties provided by that component (the property provider).

Now, does Qt have something similar for Qt Widgets?

I really would like to use this technique again because it's usefull to add functionality to existing controls that way, otherwise I need to create a custom widget for all the widgets where I need the extra functionality. In my case, I use it to link a value coming from the PLC to the control (widget).

Thanks!

[StrikeByte]

Hey,

It is possible to add custom properties to a standard item. in the creator you can select one or more objects and you can click the plus in the property window this will add a custom property. (it works a little different than c#)
Another possibility is to create a derived class and promote a widged to the self written class

[Destiser]

- Dynamic properties:

this is very handy indeed! Thanks for the tip! But, I'm in some logical problems now. In C#, the property provider was also the component that fetched the data from the PLC for every registered control (widget) in runtime, that was easy because the controls were registered during "design time" via the extended properties. Now the dynamic properties aren't an extra component and therefore I don't know how I can easily find every widget on a complex multiform application that has the required properties set. It looks to me that things get very messy that way.

- Promote a widget

I presume, that you mean that I need to make a custom control derived from a particular control and add the extra properties there along with the 'handling code'. I could do that, but it's against the antipattern copy-paste, because I need several diffrent types of widgets that need this extra functionality (slider, pushbutton, label, textbox,... sorry for the .net names!), and thus I would need to copy paste a lot of code then. this is why I started using 'property providers' in .NET to avoid this.

Now, I'm not an IT-er actually so I still need to learn alot about design patterns and making good classes etc., so it could be you need some patience to explain the concept of what I should do here.

Thanks in advance!

[StrikeByte]

If you want to use drag and drop this is what I would do:
Create an inheritance of somthing like QWidget, this inheritance is a controller that connects to the PLC gets and sets data using SIGNALS and SLOTS
create all the SIGNALS and SLOTS you need for the variables in the plc.
if thats ready place the controller on the form (by using promotion of a normal qwidget)
connect all the slots and signals (press F4 in the designer or click the edit signal/slot icon) and drag the controller to the textboxes and/or scrollbars and vice versa (click the right signals and slots in the dialog)

Example:
for this example the controller has a slot named setPressure(QString) this slot converts the string into an int and sends it to the plc

drag the textbox (used for setting pressure) to the controller (while in edit signal/slot mode)
click in the poped up dialog in the left box the textChanged(QString) signal and in the rightbox the setPressure(QString)
Done.

[yeye_olive]

I am not sure I fully understand your problem (and I never used C#). If you want to run some code for all the widgets of a form (such as adding a dynamic property, updating the value of this property, etc.), you can use the following ingredients:
- QObject::children() to obtain a list of all QObjects whose parent is the form (use that recursively if you have nested widgets);
- QObject::isWidgetType() to identify those among them that are QWidgets;
- QObject::setProperty() to add/update a dynamic property (the programmatic equivalent of what StrikeByte suggested).
You can also test the type of each child at runtime (e.g. by using qobject_cast<>()) to handle type-specific aspects. If the set of handled widgets does not change at runtime, I suggest you compute it once and for all when the application starts.