Community
Participate
Working Groups
The method can only be used in areas/dialogs which force single selection i.e. using createWorkingSetSelectionDialog(*, false). Those that allow to select more than one working set for an operation will have to build their own mechanism. It would be great if one single mechanism could be used. The getRecentWorkingSets would then return IWorkingSet[][].
I agree that we should provide something for multi working sets (those selected in multi select working set selection dialogs, possibly more than one working set). However, I don't think multi working sets should share an MRU list with single working sets. If they did then we would again mix or somehow restrict multi working sets with single working sets in dialogs that only support single working sets, like the navigator view filter dialog. This has caused confusion in the past. We could still maintain a single list and make clients that are not interested in multi working sets ignore them. However, the MRU list size would no longer be deterministic. You could possibly have an empty MRU list after filtering out multi working sets. An alternative would be to maintain two MRU lists instead. Adding API along the lines of addRecentMultiWorkingSet(IWorkingSet[]), IWorkingSet[][] getRecentMultiWorkingSets().
What's important to me is that if someone selects a working set via single-select dialog I get this working set when asking fro the multi-LRU list. >however, the MRU list size would no longer be deterministic. This is always true. The list is 0..maxSize.
Revisit post v2. Need to determine how to best handle multi/single recently used working sets. Another option in addition to the ones above would be to make a mixed multi/single working set list the default and maintain a separate one just for single working sets. A new abstraction for multi working sets may be desirable. It could then also implement a working set merge method so that any viewer could easily support multiple working sets.
Should add API that returns both single and multi recently used working sets with each group having the same upper limit (e.g., 5 for a total of 10 MRU working sets). This way the single MRU working sets contained in the mixed list would match exactly the array returned by the existing getRecentWorkingSets.
Reassigning to Nick since he is taking ownership of this component.
No plans to address although it may fall under a general working set refresh at some point.
Just stumbled upon this bug while looking for another 'recently-used-workingset' bug. Why not use an aggregate workingset to house a list of workingsets that you'd like to maintain in the MRU. I agree, this is certainly different from an array of workingsets or the idea presented in the bug, but it accomplishes the purpose. The change to two dimensional array return value is a breaking change. Changing the return type or adding a new method, both seem like options we cannot use.
>The change to two dimensional array return value is a breaking change. Yes, it will need new API, see comment 1.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
