Page 1 of 1

API control over features

Posted: Fri Jan 08, 2016 12:19 am
by tzimnoch
What is the proper way to select and/or disable features through the API, specifically for Track Changes and Accept Changes?

I'm using the AuthorComponentSample as a starting point for an applet. Based on external factors (business workflow/specific user, rather than document type), I need to be able to set both the selected state (on) and the disabled state (so user cannot toggle it off) for track changes. I also need to turn off the Accept Changes feature at some workflow stages, but re-enable them in others.

For Accept Changes, for the most part I can just not create the buttons or grey them out, but I don't have that level of control over the reviews panel. Can you turn off the accept/reject features found in the review panel accessed by

Code: Select all

editorComponent.getAdditionalEditHelper(AuthorComponentProvider.REVIEWS_PANEL_ID);
or is there another version of this review panel that only shows data without the ability to accept or reject changes?

For track changes, AuthorReviewController allows me to toggle the Track Changes setting, but not disable it.

I tried going deeper:

Code: Select all


	Map<String, Object> authorCommonActions = ((WSAuthorComponentEditorPage) editorComponent
.getWSEditorAccess().getCurrentPage()).getActionsProvider()
.getAuthorCommonActions();

final javax.swing.Action aca = (Action) authorCommonActions
.get("Edit/Track_Changes");
aca.putValue(Action.SELECTED_KEY, true);
aca.setEnabled(false);
This works for a very brief period of time until something else resets the values on user keystroke.

I registered a PropertyChangeListener to see what was happening. I can set the values as I want them to be in the PropertyChangeListener, and it almost works, but there are several PropertyChangeEvents on every keystroke as my listener and some other component battle it out for primacy. I was afraid of an infinite loop, but the other component eventually gives up. I haven't figured out what other component keeps trying to re-enable track changes.

Still, this has all the appearances of doing it wrong.

Code: Select all


		aca.addPropertyChangeListener(new PropertyChangeListener() {
@Override
public void propertyChange(PropertyChangeEvent event) {
System.out.println("track_changes property change "
+ event.getPropertyName() + " old: "
+ event.getOldValue() + "\t new: "
+ event.getNewValue() + "\t source:"
+ event.getSource() + "\t PropagationId:"
+ event.getPropagationId());
aca.putValue(Action.SELECTED_KEY, true);
aca.setEnabled(false);
}
});
This is typical output on a keystroke.

track_changes property change enabled old: false new: true source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null
track_changes property change enabled old: true new: false source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null
track_changes property change enabled old: false new: true source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null
track_changes property change enabled old: true new: false source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null
track_changes property change enabled old: false new: true source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null
track_changes property change enabled old: true new: false source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null
track_changes property change enabled old: false new: true source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null
track_changes property change enabled old: true new: false source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null
track_changes property change enabled old: false new: true source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null
track_changes property change enabled old: true new: false source:ro.sync.ecss.component.i.f.g.gb@f04cb9 PropagationId:null

The source is the same as when I click the Track Changes button, so that didn't help me figure it out.

How can I keep the Track Changes Action disabled, but its value selected?

Re: API control over features

Posted: Fri Jan 08, 2016 10:15 am
by Radu
Dear Todd,

Please see some answers below:
For Accept Changes, for the most part I can just not create the buttons or grey them out, but I don't have that level of control over the reviews panel. Can you turn off the accept/reject features found in the review panel accessed by

or is there another version of this review panel that only shows data without the ability to accept or reject changes?
In the Author SDK available for Oxygen 17.1 we added new API ro.sync.ecss.extensions.api.AuthorReviewController.getAuthorReviewViewController() which would allow you to control the actions in the review panel.
For track changes, AuthorReviewController allows me to toggle the Track Changes setting, but not disable it.
Indeed our code enables or disables actions quite often, sometimes based on caret moves for example.
So you could indeed try to add that property changed listener and disable again the action. You can use a flag to avoid an infinite recursion:

Code: Select all

     aca.addPropertyChangeListener(new PropertyChangeListener() {
boolean revertingValues = false;
@Override
public void propertyChange(PropertyChangeEvent event) {
if(! revertingValues){
revertingValues = true;
try{
aca.putValue(Action.SELECTED_KEY, true);
aca.setEnabled(false);
} finally{
revertingValues = false;
}
}
}
});
or as a workaround add a before action performed listener on the action:

Code: Select all

    actionsProvider.addActionPerformedListener(aca, new ActionPerformedListener() {
/**
* @see ro.sync.exml.workspace.api.editor.page.author.actions.ActionPerformedListener#beforeActionPerformed(java.lang.Object)
*/
@Override
public boolean beforeActionPerformed(Object actionEvent) {
//Reject the event, the action will do nothing.
return false;
}
});
so that the action will look enabled but it should do nothing when pressed.
Or as you said, you have full control over the toolbar. So when you want to disable the action you can for example set another action on the toolbar button, that custom action using the toolbar icon from the original action but being totally disabled. Or your custom action could be a wrapper over our action (delegate to it various methods) but remain disabled.

Regards,
Radu