In fwt::RichText, there is a model property, with get/set accessors. But, in RichTextPeer, the RichTextModel is being set in the create method and never changed.

I think for that to work, all the places in the peer that use model should instead be using something like self.model() -- but the self fan object isn't being kept.

Anyway, the upshot is that changing the model for a RichText currently doesn't work.

I'll take a look

Looking at this problem, my first instinct is to say that you can't change the model once the widget peer has been created (or made visible).

Allowing the whole model to be changed is rife with boundary conditions and portability issues, and I am not sure it makes sense to be modifying the model on the fly.

Thoughts?

RichTextModel is pure Fan; mostly abstract and virtual. So in Fan I can implement my model however I want, no problem; I can replace my idea of swapping models when my data changes with a model implementation that either handles multiple kinds of data or forwards to an implementation class. So, no problem there.

The thing that's missing is, when I programmatically change my data, I've got no way to cause the RichText widget to refresh itself.

In Tree and Table, which similarly use a backing model for their data, there is a refresh method ( Tree.refreshAll and Tree.refreshNode , Table.refreshAll ). RichText doesn't have that.

Looking for a similar effect, I noticed that the model property of RichText called to a native modelHasChanged method and thought maybe it would force an update of the widget from the model data. But, it seems to not be implemented, or not that way at least.

So as things are now, I'm forced to poke new text into the widget through the modify method, then go behind the scenes and make corresponding changes in my richtextmodel object to apply formatting to it. Awkward.

Some way of forcing the native widget to refresh itself from its model would fix it.

The way it is designed now, when the model is changed it is the model's responsibility to fire the onModify event with a TextChange instance.

So the notion of a refreshAll is left up to the RichTextModel subclass. But in the end something has to fire a modify event which indicates to the peer which parts of the document have been modified so that it can update its own internal data structures.

Would that work for your use case?

I think it does; I realize now I was forgetting that the peer listens to onModify events too.

So, all that's left of this thread is, maybe RichText.model:set ought to throw Err if you try to set it after the widget's been created. Or at least document "don't do that".

OK, I pushed a changed to document you can't change it and throw an appropriate exception if you attempt to.