Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 345238

Summary: [Markers] Marker should provide flexible numeric filed support
Product: [Eclipse Project] Platform Reporter: Feng Liu <fengllf>
Component: UIAssignee: Platform UI Triaged <platform-ui-triaged>
Status: CLOSED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: daniel_megert, john.arthorne, prakash, Szymon.Brandys
Version: 3.7   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard: stalebug
Attachments:
Description Flags
Incorrect sort and workaound none

Description Feng Liu CLA 2011-05-10 05:23:02 EDT 
Build Identifier: M20080911-1700

Our project use Marker Support Framework to provide bookmark support for our special editor input. We have one numeric property for our marker, like "baseValue", and it is shown as a field in our custom bookmark view. Most of functions works well except that:
  (1) Sort all the bookmarks by the numeric field.(Escpecially when we want to format this field)
  (2) Right align the numeric field.

We also try to close sort function for this field but find no relevant API or extension point.

The workaround we use is to stuff spaces at preceding for each numeric but this has two limits:
  (1) Many spaces have to stuffed for minor value, especially when the numeric is "long" type.
  (2) This workaround can not work for negative values.

Reproducible: Always

Steps to Reproduce:
1. Define a numeric field for a marker
2. Add some markers
3. Sort the markers by the numeric field in the marker view.
Comment 1 John Arthorne CLA 2011-05-10 08:49:16 EDT 
By numeric field do you mean floating point numbers or integers? IMarker already supports integer attributes.
Comment 2 Feng Liu CLA 2011-05-11 00:21:17 EDT 
Created attachment 195294 [details]
Incorrect sort and workaound

"BaseValue" is an integer attribute of IMarker and is shown in the view with comma inserted. It seems the view uses String comparator to sort "BaseValue" column, so we obtain wrong order when we take them as integer.

"StartTimeStamp" is also integer attribute of IMarker and is shown with spaces stuffed in the preceding. This is the workaround we used now.
Comment 3 Feng Liu CLA 2011-05-11 00:39:46 EDT 
We know IMarker support String, Integer, and Boolean as its attributes, but it seems the MarkerSupportView just sort the markers by the string values of each field, not by the attribute value.

BTW, if the MarkerSupportView could sorted markers by attribute value, Long type attribute is needed for us.
Comment 4 Dani Megert CLA 2011-05-11 02:39:39 EDT 
(In reply to comment #3)
> We know IMarker support String, Integer, and Boolean as its attributes, but it
> seems the MarkerSupportView just sort the markers by the string values of each
> field, not by the attribute value.
> 
> BTW, if the MarkerSupportView could sorted markers by attribute value, Long
> type attribute is needed for us.

Would maybe a separate view for your custom markers make more sense?
Comment 5 Feng Liu CLA 2011-05-11 05:33:45 EDT 
(In reply to comment #4)
> (In reply to comment #3)
> > We know IMarker support String, Integer, and Boolean as its attributes, but it
> > seems the MarkerSupportView just sort the markers by the string values of each
> > field, not by the attribute value.
> > 
> > BTW, if the MarkerSupportView could sorted markers by attribute value, Long
> > type attribute is needed for us.
> 
> Would maybe a separate view for your custom markers make more sense?

Yes, we have a separate view for our custom markers, we just make our view extend MarkerSupportView.

Today, I find compare(MarkerItem, MarkerItem) in the MarkerField, we can overwrite it to sort all markers by model, like by attribute, and this can resolve our problem. Although we have to save the attribute as String and parse it into Long when comparing.

Thanks for your comments.

BTW, can MarkerField expose API let users specify align ?
Comment 6 Lars Vogel CLA 2019-11-14 02:24:01 EST 
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.

If the bug is still relevant, please remove the "stalebug" whiteboard tag.