Is this a good case for a QStateMachine?

[waxwed]

Hi,

I'm in the process of designing a screen that will display financial data. It is quite simple as it is a table with up to 30 columns and 100 rows. The cells will display various pieces of data either text, images or a combination of the two. The cells won’t be directly editable. I don’t have a problem creating the Model with an appropriate View to display this data but I would like some advice on how to control the visual ‘highlighting’.

Part of this display is to highlight a cell when something has changed. In the simplest example it would be if a price goes up flash it blue, if it goes down flash it red.

I’m thinking about using a state machine per cell because the underlying data can be in different states, ‘up/down/up on day/down on day/suspended/crossed/blah/blah/blah/…’, all of which will change the visual aspect of the cell. I’ve not used a state machine before and I was wondering if this would be a good fit?

I would probably use something like a QEventTransition with barriers to cause the states to change.

Is this just overkill? As I’m sure I could achieve all this with a few switch statements, and with there being circa 3000 cells is it going to be a CPU hog?

Thanks.

[ZapB]

I would say that one state machine per cell is a massive overkill. Each state machine has it's own event queue and requires some processing time in the event loop.

At first thought I would probably take the approach of encoding the state into a new data role so that you can query it via your model's data() function in your custom view.

If you are using a standard view then in your data() function you can provide a custom value for the cell background etc. depending upon the value of your custom field using a simple switch as you say.

[waxwed]

Thanks for getting back to me. I did a bit of R&D yesterday and came to the same conclusion.

I decided to have QStandardItem descendant that creates a set of objects that define the behaviour of the cells (FlashableCell), which will control the display through the data() method, exactly as you have suggested.

Instead of a switch I can decide upfront, using composition, how the comparison logic and subsequent colouring will work.

The next item to tackle is the flashing and how to make this efficient. My current thoughts are to populate a list of FlashableCells when a cells' content changes. This will set a timeout/expiry against the cell ... basically I'm creating a MRU ... and every second I can run through this list and see if the cell has expired. If it has I will then revert it to a non-flashed state ... anyways ...

Thanks again for confirming the direction to go in.

[ZapB]

Hmmm, one way would be to provide a custom delegate (see [[Doc:QStyledItemDelegate]]) that knows about flashing.