[Qt-interest] Generic input widgets for varying types - how to?

[Helge Preuss]

Andreas Pakulat wrote:
>> Uh-oh. How would I make a dialog contain a ParameterInput then? It must
>> be a QWidget, else it cannot be a sub-widget, am I right?
>>     
>
> That depends on what you actually want to achieve. I just had another
> look at your initial mail. The part about manually editing a uic
> generated file is problematic. It basically makes using the
> uic-generated file completely meaningless, the whole point of doing that
> is to easily update the gui without having to touch code, which is not
> possible with your idea.
>   
/me veers off topic:

I'm not sure about that... I used the Designer to easily build an
interface, which I probably won't have to change manually. Designer/uic
is just not powerful enough to have a variable QWidget in one place, the
way I intend to. Or am I mistaken?

Anyway, I just used the Designer to spare me the tedium of hand-writing
all the code to create the GUI. If I have to change the code manually
later, it will still have spared me that.
> And if you're creating the gui in code by using a factory, there's no
> reason why that factory cannot return a QWidget*  that can be casted to
> either a specific QWidget subclass (like lineedit, spinbox) or your
> ParameterInput interface.
>   
That's right. It even seems easier than going the QItemEditorFactory way.
> So you could just do
> QWidget* inputWigdet = Factory::create( LineEdit );
> dynamic_cast<ParameterInput*>(inputWidget)->setValue( "SomeString" );
>
> Or even pass around the "widget" only by using the ParameterInput
> pointer so no code outside the place that actually creates the widgets
> from the factory sees which widget is behind the ParameterInput.
>   
I'm not quite sure whether this is possible for me, but I'll give your
idea a test ride.
>>>> Question 2:
>>>> This does not really work. The ParameterInput widgets are not displayed.
>>>> I assume I must implement some QWidget methods to make the widgets
>>>> display. Which methods would that be?
>>>>     
>>>>         
>>> I suggest to fix the above first and then revisit this, all kinds of
>>> weird things may happen when you subclass twice from qwidget. In
>>> particular in your case probably the paintEvent of QWidget is being
>>> called (just painting a grey background) instead of the one from the
>>> actual widgets.
>>>   
>>>       
>> That's probably what happens, yes.
>>
>> So if my above hunch about ParameterInput having to be a QWidget is
>> correct, I'll probably have to use composition in the derived classes.
>> Such as:
>>
>> class ParameterLineEdit: public ParameterInput {
>>   private:
>>     QLineEdit *delegateLineEdit;
>>     void setValue(const QString &s) { delegateLineEdit->setText(s); }
>>     //  etc.
>> }
>>     
>
> Well, you'd need the delegating for setValue/value anyway, but more
> importantly in this case you'd need to delegate the whole QLineEdit API
> to make it work. Thats going to be a lot of work for no gain (that I can
> currently see).
>   
It's not the /whole/ QLineEdit interface (the ParameterInput interface
just contains get/setValue()), but apparently those parts that make the
QLineEdit displayable correctly (that is kind of what question 2 in my
original post was aiming at - which functions would that be?). But your
point is taken.

Thanks,

Helge

-- 
Helge Preuss
Freelance Software Developer
+49 30 40 30 10 90
+49 177 2262 484
helge.preuss at gmx.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20090327/c872ca61/attachment.html