Hi,
I would not say that this class has a design flaw. Let's say you have a base class accepting all characters. After a while you decide create a derived class accepting only a particular format and work with particular type of data. Would you then use the derived class object to work with particular data or would you rather use the base class object?
QLineEdit can work they way you want.(mask/validation/format)
QDataTime has a predefined format. It is hard to keep the same flexibility of a class when it is intended to be specialized/ intended to concentrate on a particular data type/format.
What I am trying to say is that QDateTime was design to work with Date/time typical format data. You can change the format of displaying the data, but still the data entered need to be valid. You can show a '-' char as a separator, but still the '-' chat is not a part of the data.
To create a custom format use QLineEdit as I said before.
Kacper
wysotaQt allows you to use everything you want
--------------------------------------------------------------------------------
#if defined(Q_OS_UNIX) && defined(QT_DEBUG)
abort(); // trap; generates core dump
#else
exit(1); // goodbye cruel world
#endif
I don't think we come to an agreement here.
I think having a NULL value in an edit field is essential for many applications. Using QLineEdit directly practically means writing my own date edit classes from scratch. With the QDateTime classes Qt provides it would not be overly complicated, but IMHO for such a basic requirement it just should not be necessary.
Hi,
I agree with you up to a point : )
In my opinion a date edit class is "obligated" to contain a date, still there should be a way of settings a "null" value, you're right here.
I understand what you want to achieve, but still do not know why don't you use QLineEdit and use the settings you need.
Kacper
wysotaQt allows you to use everything you want
--------------------------------------------------------------------------------
#if defined(Q_OS_UNIX) && defined(QT_DEBUG)
abort(); // trap; generates core dump
#else
exit(1); // goodbye cruel world
#endif
Oh, this is exactly what I will do, have to do. As I said, with the other date/time classes Qt provides it is not overly complicated, but still the necessary validators are not trivial either, e.g. to prevent dates like 31/02/2008. If there were no classes like QDateTimeEdit/QDateEdit/QTimeEdit I'd happily do it. But as it is, I just feel like being forced to reinvent the wheel. I wanted to see whether there is a better way to do it, since I just can't imagine that I am the first one who has this problem. That's all.
Yes, you're right you will have to do a bit of work, what should have been replaced by using a method or settings on QDateEdit/QTimeEdit.
Thanks for the discussion : )
Kacper
wysotaQt allows you to use everything you want
--------------------------------------------------------------------------------
#if defined(Q_OS_UNIX) && defined(QT_DEBUG)
abort(); // trap; generates core dump
#else
exit(1); // goodbye cruel world
#endif
Yes, IMHO this IS STILL (Qt4.8) a design flaw: If you set a simple QDateEdit and connect it with a QDataWidgetMapper to a model which is connected with a SQL database, just put a NULL value into the database field that is read by the model and tied to the QDateEdit ->the edit will show 1/1/00 then which is NOT a NULL value.
This is, on the first glance, not a big problem. But if you want to check in a form if there is already data in the widgets and COMPARE all the widgets' value fields (QLineEdit's "text" property etc) with the correlating database fields - the compare between the QDateEdit and the date DB field is just WRONG, it compares NULL with 1/1/00.
So yes, design flaw IMHO. Struggling here too, I will do a QlineEdit with inputmask and validator. this way you can even allow more than one method to enter a date: 01/02/1987, 010287, 01021987 etc. to be all valid.
Bookmarks