[haiku-3rdparty-dev] Re: Finding property changes in a widget or BControl
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-3rdparty-dev@xxxxxxxxxxxxx
- Date: Tue, 17 Nov 2009 11:06:59 +0100
Hi,
On 2009-11-17 at 05:06:22 [+0100], Yashasvi A.C. <yashasviac@xxxxxxxxx>
wrote:
> Last time, you had mentioned that SendNotices() would be the right method
> to use in this case. However, in the BeBook, it says that this method
> will send a
> B_OBSERVER_NOTICE_CHANGE<http://www.haiku-os.org/legacy-docs/bebook/TheApp
> licationKit_MessageConstants.html#B_OBSERVER_NOTICE_CHANGE>message to the
> handler. The problem is that I would need to also pass in parameters
> (uint32 what, const BMessage* msg = 0).
Anything that is necessary to distinguish the notifications.
> So, does this mean that I would need to create a new message and pass
> this as a parameter? Because that would not be useful to me. I want to be
> able to listen to messages regarding the property change. I don't think I
> completely understand the description that is given. If I implement the
> method directly, will it provide me with property change messages? I am a
> bit confused. :(
First of all, I am saying the implementation of the observer notifications
in Haiku itself may be incomplete. So if you were to take this solution,
work needs to be done inside Haiku Interface Kit class implementations, as
well as in your own application to take adventage of this approach. The
observer notifications are an existing built-in mechanism, and IMHO, it
would be the most fitting technique to solve your problem. But it probably
needs to be extended to support everything you need from it, especially
code needs to be added such that it is triggered on every property change
in an Interface Kit class (I will give an example below). Since you need
this right now, you are probably the best person to do this work.
In my opinion, there is no harm done by making all the Interface Kit
classes support observing of basically any property change that they can
perform on themself.
Additionally, I think I mentioned before that there needs to be support
added to the scripting interface such that it becomes possible to register
observers from a remote team (as in your situation).
With these things in mind, please take a look at the Interface Kit class
implementations, their support for triggering BHandler style observer
notices and at the scripting implementation. How could it be extended to
support registering remote observers?
I will try to give you an example: Take a look at the BControl class
implementation. In the method BControl::Invoke(), you can see that the
SendNotices() method is called. The BInvoker class basically has one
target. The observer mechanism is something that Be added later with
support for multiple targets - it could basically replace the former
BInvoker mechanism. In the case of BControl::Invoke(), it sends notices to
all registered observers via the invokation of SendNotices().
Now take a look at BControl::SetEnabled(). I don't see any SendNotices()
there - but why not? It is a property change and someone may be interested
in it. Why not add the invokation of SendNotices() also in
BControl::SetEnabled()? Maybe introduce a new notication kind if nothing
suitable is defined yet. Maybe pass another message with additional
descriptive parameters like it's done in BControl::Invoke().
Do you see what I mean now? Any code could disable a control by calling
SetEnabled(false), and no message passing would be involved that you can
catch and filter. But by extending the BControl class itself to send out
notices when the property changes, you force BMessages to be sent to
registered observers. This needs to be added everywhere you need it.
Additionally, you need a way to register remote observers. And once you are
done, you can use this technique to solve your problem.
Best regards,
-Stephan
Other related posts:
