Hi Ariel,
thanks again for helping me out!
I did what you described and tried to adapt the cpp example.
my extended toolbar has 3 controls (ImageButtons): control1, control2, control3
Each registers at startup by calling addStatusListener( aURL, aListener).
Don't I need to put each of these listeners in a collection to be later able to
send a event to the according control?
like e.g.
com.sun.star.util.URL mURL = new com.sun.star.util.URL();
mURL.Path = "control2";
mURL.Protocol = "de.addon.addonstarter:";
buttonEditEPorto.Complete =
"de.addon.addonstarter:control2";
FeatureStateEvent fsStateEvent = new FeatureStateEvent();
fsStateEvent.FeatureURL = mURL;
fsStateEvent.Source = this; // is called from within
dispatch Method
fsStateEvent.IsEnabled = controlEnabled; //
controlEnabled = false or true
fsStateEvent.Requery = false;
control2.statusChanged(fsStatusEvent);
I am only able to safe a reference to the XStatusListener which was provided by
the last call of addStatusListener(). I don't seem to understand why I can't
keep a reference to the XStatusListeners of the previous calls of
addStatusListener() ( has each control its own thread and the calls happen in
parallel ?)
If I do something like Collection.put(xController) each time addStatusListener
is called, the collection will only contain one element in the end.
What I try then is to click on controll1 in my toolbar. This triggers in the
dispatch method the code above to disable control2. But instead of control2 I
can only use the XStatusListener of the last call of addStatusListener().
As a result control1 gets disabled instead control2 as I would expect.
So to me it seems that my problem is that I can't keep the references to the
according XStatusListener.
I hope this wasn't too confusing and makes any sense to you,
thanks again for the help!
regards,
Fabian
On Jan 23, 2012, at 9:26 PM, Ariel Constenla-Haile wrote:
> Hi Fabian,
>
> On Mon, Jan 23, 2012 at 09:51:27AM +0100, fabian wrote:
>> Hi,
>>
>> I am trying to disable/enable toolbar buttons in my java oo-extension.
>
> I guess you're using the so called "Complex Toolbar Controls" feature,
> aren't you?
>
>> I managed to use the addStatusListener method to use an additional
>> dropdownbutton and know how to enable/disable buttons at startup. My
>> problem is that I can't safe a reference to
>> com.sun.star.frame.XStatusListener xControl to enable/disable a button
>> at wish, since the reference is set back to null after
>> xControl.statusChanged() was called. But looking at the c++ example
>> of the SDK, keeping a copy of xControl is what I have to do to recall
>> statusChanged.
>>
>> Can someone point me to the solution? Thanks!
>
> The toolbar control registers itself as listener at the Dispatch object
> you return in queryDispatch in order to get status updates. This is done
> in the Dispatch object's addStatusListener().
>
> Your Dispatch object should have a collection of listeners:
>
> * when addStatusListener() is invoked, the Dispatch object should:
> * add the listener (the toolbar control) to the collection
> * send to this listener an status update invoking the listener's
> statusChanges() method
>
> * when removeStatusListener() is invoked, the Dispatch object should
> remove the listener from the collection
>
>
> To Enable/Disable a toolbar control is simply sending it a
> FeatureStateEvent with IsEnabled set to false.
>
>
> Now let's suppose that your toolbar control provides functionality for
> drawing shapes; so you want it enabled only when a shape is selected.
> You will have to implement an XSelectionChangeListener that, when the
> selection changes:
>
> * if the selected object is a drawing shape, send a feature update to
> all the status listeners in the collection that were registered for
> the command URL. Here FeatureStateEvent.IsEnabled = true
>
> * if the selected object is not a drawing shape, then you want to
> disable your toolbar control; just send an status update to all the
> status listeners in the collection with IsEnable set to false.
>
> In general this is how context-sensitivity is implemented by sending
> status updates to the user interface element, then the UI element
> updates its representation to reflect the feature state.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
