Community
Participate
Working Groups
Tested on 3.0.1-RC3a. If folder was not expanded, properties show 0 as number of children. After expanding the folder properties show correct number of children. The same can be seen on processes tree for TCF connection.
Might be similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=160763
I guess this is kind of expected behavior. In order to know the number of children, we'd have to list contents of each folder. But we try to avoid that in order to reduce remote communications. Imagine you open a folder which has 1000 subfolders. Getting the number of children of each of these 1000 subfolders would need significant amount of time, even if you are typically not interested in the number of children. I agree, that a better solution than showing "0" children for not-yet-expanded folders would be showing "(not yet retrieved)" or a similar text. I personally find this a minor to trivial issue, reducing severity and priority -- feel free to up again if you disagree.
That's fine for me but "0" is really very confusing. Especially when it is changed to some other number after you expand.
Hm, I see... in fact other properties may have similar issues. What about changing the bug summary into "Properties not yet computed should indicate that state (rather than reading invalid values)"
Agreed.
*** Bug 233525 has been marked as a duplicate of this bug. ***
We should have a "pending" state for Properties. I believe that this should be API, so I'm planning M5 for it.
Is it enough to change return value of getPropertyValue to "(not yet retrieved)" instead of "0"?
I think one problem here is that we'll want the "(not yet retrieved)" String to be NLS translated, but also be available as a constant for Programs to check. Another problem is, that some programs may expect an "int" value on some Properties, and be confused (down to throwing an exception) when they see a String. In terms of backward compatibility, I think I'd prefer a solution that only changes appearance in the Viewer, but keeps the actual data as it is today ("0"). Internally, Properties could have an additional boolean flag ("not yet retrieved)" to trigger display of the special "not yet retrieved" status. In terms of API, we could have String[] ISystemViewElementAdapter#getPropertyNamesPending(Object element) to return the Property Keys of those Properties that are still "pending". Since we expect that in most cases the Properties will be available, the String would typically return an Empty String array (String[0]), which could be provided in the AbstractSystemViewElementAdapter for backward compatibility. In other words, without special handling the "old" subsystems would work as they do today, and "new" subsystems could return proper pending state through this API.
Don't have time for it for M6.
