Bug 213722 - [Viewers] In DeferredTreeContentManager: no access to family ID
Summary: [Viewers] In DeferredTreeContentManager: no access to family ID
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2007-12-21 13:33 EST by Alex Chapiro CLA
Modified: 2019-09-06 16:08 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Chapiro CLA 2007-12-21 13:33:39 EST
Build ID:  I20070503-1400 (3.3 release)


This is rather change request. Is it possible to add into public API for DeferredTreeContentManager class method that returns family ID in order to let user to synchronize against children collection process?
Comment 1 Boris Bokowski CLA 2008-01-02 11:19:10 EST
Could you please explain your use case in more detail? Thanks.
Comment 2 Alex Chapiro CLA 2008-01-02 11:42:16 EST
I just want to have a sort of synchronization with fetch children process. Family identification object is not exposed in the current implementation of DeferredTreeContentManager class. Instead of natural way I have to use job change listener, which is not reliable (at least in theory,  because job can finish before listener added).
Comment 3 Boris Bokowski CLA 2008-01-02 11:48:50 EST
I'll try to look at this for 3.4 M5.
Comment 4 Boris Bokowski CLA 2008-02-03 16:42:19 EST
Sorry, but I still don't understand what your use case is. Why do you need to synchronize with the job that executes the fetching of children? Can this synchronization not be done elsewhere?
Comment 5 Alex Chapiro CLA 2008-02-04 10:46:57 EST
I just want to do some job after all the children are collected, not earlier. I wouldn't ask about creating of new feature specially for me. But I made a search and found that there were somebody else who needed this functionality (see http://dev.eclipse.org/newslists/news.eclipse.platform.rcp/msg24481.html for example). Besides that I thought that this was very trivial task (just change of method visibility attribute or something like that). Never mind if I fell in mistake thinking this way because the workaround works well so far. It would be nice to have this option, but I cannot say that I critically need it. Thanks for paying attention on this case. 
Comment 6 Boris Bokowski CLA 2008-05-02 14:56:53 EDT
Mass update - removing 3.4 target. This was one of the bugs I marked for investigation (and potential fixing) in 3.4 but I ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
Comment 7 Boris Bokowski CLA 2009-11-26 09:43:14 EST
Hitesh is now responsible for watching bugs in the [Viewers] component area.
Comment 8 Eclipse Webmaster CLA 2019-09-06 16:08:42 EDT
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.