QTimeEdit issues

[Perdrix]

I have a table view that contains an exposure column. I have used:

	QWidget* ItemEditDelegate::createEditor(QWidget* parent,
		const QStyleOptionViewItem& option,
		const QModelIndex& index) const
	{
		switch (static_cast<Column>(index.column()))
		{
		       // Omitted ...
		case Column::Exposure:
			{
				QTimeEdit* editor = new QTimeEdit(parent);
				editor->setDisplayFormat("hh:mm:ss.zzzz");
				//
				// Commented out as parent class already sets an eventFilter up!
				//
				// editor->installEventFilter(const_cast<ItemEditDelegate*>(this));
				
				return editor;
			}
			break;
		}
		//
		// Not one we want to handle so return the default
		//
		return Inherited::createEditor(parent, option, index);
	}

A user reports that when he double clicks the cell to edit, and then clicks away then the displayed value is saved. He says this is problem when the edit doesn't display more than (say) three decimal places for the seconds and the actual value is 0.00025 seconds!! (see below about display format).

He suggests: "Leaving field event should only save the displayed exposure when has manually changed the entry."

Is that possible?

It seems that the display format is limited to four decimal places - e.g. "hh:mm:ss.zzzz" Is that correct - trying to edit an exposure time of 1/4000s is problematic with only four digits.

Thank you
David

[SGaist]

Hi,

How are you storing the value ?
As for displaying, you can reimplement the displayText method to adjust what is shown without modifying the underlying data stored.

[Perdrix]

@SGaist data is stored as a double. When I refer to display format I mean the EDIT control display format, not the display of the data in the field when not being edited

[SGaist]

AFAIK, QDateTime does not support microseconds so you would need to implement that yourself. Or add the feature to QDateTime.

[Perdrix]

@SGaist Re microseconds: Apart from rewriting the control is there an "easy" approach to handling that?

Regarding the other part of the question is there a way to achieve what has been suggested?

[JonB]

@Perdrix
I have read your thread. It seems that you want a "time range" which on the one hand allows for hours and on the other hand allows for like 4 or 5 decimal points' worth of seconds, i.e. 1/10,000-th or 1/100,000-th of a second. Is that really what you need? It's a pretty wide range!

QDateTime/QTime is only down to milliseconds. Hence same for the edit widgets based on this. Furthermore, QTime and QTimeEdit are not for what you want: they are for a a time of day, you want a duration. (You might already have seen an "AM/PM" designator in the edit widget, demonstrating it is not the right thing for a duration.)

Consequently I suggest you roll your own widget for your "exposure duration".

The QElapsedTimer class is for time durations, and goes down to nanoseconds (handled as a qint64). This sounds more suitable for your requirement. I don't think it has an editing widget, create one suited to what you want to present to the user.

[Perdrix]

@JonB I looked at QElapsedTimer - that looks like it is for timing stuff in code. I just want to edit a number that is the exposure time for an image which could range from 1/10000s to days. I hold it as a double so that will cover the range without problem.

I could edit that purely in seconds with 6 decimals but when dealing with larger exposure time it would be nice to have an editor that would use e.g. DD|hh|mm|ss|zzzzzz - similar to QTimeEdit but extended to handle many days and better than millisecond accuracy.

Thanks
David

[JonB]

@Perdrix said in QTimeEdit issues:

nice to have an editor that would use e.g. DD|hh|mm|ss|zzzzzz - similar to QTimeEdit but extended to handle many days and better than millisecond accuracy.

If you don't mind my saying, I do not think that would be useful. I just do not see where many applications would require input ranging from days to micro or nanoseconds.

My point was that only QElapsedTimer is for representing a duration, QTime is not. I would not be using a QTimeEdit for your specification. Anyway, you could put together 5 spin boxes as a widget. IMO, each to their own.