Get data displayed in Pending changes view via API
I'm trying to gather all API required to find about status of a file in Pending changes view:
1) Is it unresolved ? I understand ILocalChangeManager is the required API.
https://jazz.net/forum/questions/44421/api-to-determine-local-not-checked-in-changes
2) Does it collide with incoming change-set or already require merge ?
3) Is it in incoming change-set ?
4) Is it in outgoing change-set ?
5) Is it locked ?
Also, I'd like to listen to events that change this status, if you have pointers for relevant listeners (currently I know of IConfigurationUpdateEvent.CONFIGURATION_UPDATED, It does not cover all the scenarios) it would be great if you can share them here.
Thanks,
Gidi
Accepted answer
Comments
Hello David,
Many thanks for your reply. I have one more question regarding the initialization of the PC view (when RTC is launched and user performs log-in)- is there an event triggered when the initialization is done and all data in the ComponentSyncModel is updated ? I understand I will need a much better listening mechanism to monitor all the events in EventManager. I am hoping to start my information gathering from a scenario where the initialization is done and then improve it with additional listeners.
Is it IComponentSyncModel.WORKSPACE_SYNC_CONTEXTS ?
Thanks,
Gidi
I don't believe there's a nice easy way to tell when 'initialization' is done. ComponentSyncModel.getInstance() will start the singleton instance, as well as start up other 'manager' (if they have not started already). From there as mentioned above, things are updated in the UI after responding to various events (which come in asynchronously from the different managers and other places...) So there is no real well defined state of 'initialization is done'.
If I recall correctly though. Listening to IUpdateManager.UPDATE_STATUS_COMPLETED would be when the PC view is refreshed... (so hopefully this gets sent out early when things start up and should be roughly initialized).
This can be added like this:
Hello David,
Thanks for your reply. I'm currently testing the behavior of UPDATE_STATUS_COMPLETED, I see it is called once before the user log-in with the operation string CONTEXT_REFRESH_COMPARE_NOTIFY_ACCEPT_OPERATION
and twice after the log-in with the string
CONTEXT_REFRESH_SUSPEND_OPERATION
I can filter the calls to focus on CONTEXT_REFRESH_SUSPEND_OPERATION and add a flag in order not to call twice my initialization code. If there's a way to distinguish between the two calls after the log-in is performed I'll be grateful if you share it here.
Thanks,
Gidi
Hello David,
An update: When I use the second call after log-in (CONTEXT_REFRESH_SUSPEND_OPERATION )the call to IComponentSyncModel.getWorkspaceSyncContexts() returns 0 elements, so I cannot track the status of elements in the model.
Best regards,
Gidi
I guess when the PC view first starts up there are no workspaces tracked, and they come in asynchronously via events later on.
Perhaps try something like:
IActiveWorkspaceManager manager = FileSystemResourcesPlugin.getActiveWorkspaceManager();
manager.addGenericListener(IActiveWorkspaceManager.ACTIVE_WORKSPACES, myIListener);
I suspect this would be the event that is sent when the list of active workspaces changes...
I think the PC view might respond to this event in EventManager and request a refresh of the PC view which would later show the nodes in the UI. The PC view would do this using this code:
if (pce.getProperty().equals(IActiveWorkspaceManager.ACTIVE_WORKSPACES)) {
updateManager.requestModelUpdate(COMPONENT_SYNC_MANAGER_UPDATE_OPERATION);
continue;
}