Don’t really consider this a request; consider it a hypothetical request in the form of a monologue, and help me reach my conclusion
Would it be too much to add a pair of callbacks to changebroadcaster, so we can be notified just before and just after the messages are sent to the listeners?
I have a system of ‘aspectflags’, so I can know which major aspects have changed in my object. When i get a change message, I can check to see which aspects are flagged as dirty and only update the relevant ui parts. However, clearing these flags isn’t something I can really do in the callback, as another listener may care about that part too; if that is the case, the only time I can safely clear the flags is at the point where the last listener has been notified.
Of course, I guess I could instead pass a pointer to some dummy ‘aspect’ variable as the change source… When I get a change message I can check against that exposed member of my source; only problem there is that I might not only be listening for that source object - also, that would mean multiple messages, whereas if several aspects change at once using the first method, they could be coalesced into a single message. Also, a dummy member is a little abstract a concept and not quite as intuitive.
So, I ask ‘what would the wise one do?’. I know i could make a different message handler, but everything else about changebroadcaster is bang on so i’m simply being a combination of lazy and greedy. like a big fat sloth.
for now, i’ve got a typedef char Aspect, and given my object simple public Aspect members to check against. It’d be nice if i didn’t have to have an otherwise useless byte member, but at least it’s kinda logical.
AM I CRAZY?? I bet this is where you say “why don’t you just use XXXXXXX class, it does exactly this” and i go “duh, i’m so blind”.
Ooh, now that’s a nice idea. I’d like to be able to handle the clearing at the source so there’s no risk of forgetting; if I send a change message then trigger an async update immediately afterwards, would I be safe to assume that the messages will be handled in the same order (I.e., the async callback would happen after the last listener had been notified).
I just need to be sure that listeners wouldn’t end up getting a callback after the flag has been cleared.
Edit: hmmm, I can imagine a scenario where the changemessage is handled, and a call to mark a flag as dirty arrives just before the async callback happens… If that were possible, I guess maybe all flag-marking calls should start with a ‘cancelPendingAsyncUpdates’ or whatever, (it’d then call sendchangemessage and triggerasyncupdate). I would imagine the ‘cancelpending’ would be negated by triggering it again though, if the message was already in the system queue?
