[Qt-interest] C++ or QML

BRM bm_witness at yahoo.com
Wed Jun 30 22:34:13 CEST 2010


----- Original Message ----

> >> If the customer want a grid that behaves like microsoft excel,
> >> it is pretty hard to solve this in QT. I had expected that this is
> >> a common request to the QT developers, but emulation of different
> >> navigation types are not implemented yet and are hard to do so.
> > So you add a delegate to a QTableWidget, and then add the extra behavior you want.
> It would be fine if it where that easy  :-(.
> With a delegate you can only modify the style the item is painted if 
> it is not edited. Since the delegate creates the editor, you now have to 
> create a custom editor and so forth. It becomes a nightmare if you also need 
> special hotkeys.

Sub-class the QTableWidget and you can probably do more.

> > Though honestly I wouldn't call an MS Excel grid a native type
> Yes, right. I hate excel and i have thought for years that the
> way user has to input data is not deterministic. QT does it pretty
> right, but if the customer wants excel input scheme, it is very hard
> to solve this with qt. Since this is a common request, i had expected
> that QT would support this in a way.
> So this would be perfect:
> setNavigationType(int type);
> with
> Qt::NavigationOsDefault,
> Qt::NavigationOpenOffice,
> Qt::NavigationExcel,
> Qt::NavigationVi,
> Qt::NavigationEmacs,

That's not exactly an easy set to deal with, and it's not Qt's business (IMHO) either.
Vi and Emacs alone are highly programmable for movement.
And getting into that kind of thing would be a real hassle for the Qt guys.
For example - differences between Excel 6, Excel 2003, Excel 2007, and Excel 2010; which are you going to follow?
Is it really realistic to try to make the framework follow third party interface of which they have no control?
Is it really realistic to have to track how each one individually works - especially when one vendor (e.g. Microsoft) is not known for consistency - especially in the small details?

The only way to provide true Excel support is to use an embedded Excel spreadsheet. Anything else is unrealistic, IMHO.

> > it does require using the MS Excel Active X control at the very least,
> >which you get as part of VisualStudios, but is not necessarily on the
> >Windows platform unless someone else has put it there - either through
> >installing Office or another App that pulled the ActiveX control along.

> I don't want embed excel. I want to set QTableView in a mode that  it
> behaves like excel. Once again: It's not my idea ;-).

I would guess two parts - delegates, subclassing (delegates and QTableView), and custom widgets for each cell.

You probably want to look at QTableWidget::setItemProtocol() too - likely would provide a very quick way to do what you want from a centralized place. (Thiago?)

Yes, it'll be a lot of work; but that's your requirements not Qt's.

> > Even displaying floats with more then 2 decimal points
> > float myValue = 
> > 3.1458;
> > QString myQStringValue = 
> > QString("%1").arg(myValue,0,'f',4');
> > QLabel* someLabel = new 
> > QLabel(myQStringValue); // or use setText() to update
> That approach comes all the time and it really sucks!
> It works only if the user don't edit the cell. Then you have
> the same nightmare again.If i have a model based on 
> double values it makes no sense to change that to QString. It shows only the 
> limitations of the model / view concept.

It's all a matter of the widgets, etc that you embed in the cells.
I typically will embed QLabels into the cells to make data read-only. No delegate required.
On the other hand, you can also use QValidators to enforce that certain data is the correct data.

> Don't understand me wrong. I love the idea of model / view, 
> but IMO that approach is not fully developed yet.

There's far more than just the model/view at work here.  Understanding the whole picture is key to getting what you want the way you want it.
Above are some pointers that I am aware of; and I'm sure others on the list may say there is a better/easier way - or point out other enhancements (e.g. QString::sprintf()).

If it seems hard, you're likely looking in the wrong place, or trying to do it the wrong way. Hopefully we can point you in the right direction.

Ben




More information about the Qt-interest-old mailing list