Hi Ivan, Eric, I was actually thinking a similar idea. The more I thought about it, the more I thought about copying/pasting the SelectFeature control, make some changes to the copy and name it HighlightFeature. But Eric's idea is much better.
Having the control itself know which feature it has selected + having its own events could enable the possibility of having multiple SelectFeature controls for a single layer. Having both selecting on hover and/or click won't matter except for the style and the renderIntent applied to the selected feature. I guess the last declared control would have the last word of determining those... About that, what if we want 2 different colors for each ctrl ? Having 2 selectfeature ctrls doing the same thing ( hover and click ) is not very logic, but let's say one select on hover, the other on click, it would be nice be able to have 2 different styles for each action. But how could we do that ? (I guess I don't fully understand the whole renderIntent stuff yet... Could we specify a specific renderIntent for the selectFeature ? Could "select" be the default value and we could be able to set our own ?) To do so without changing the renderIntent of the feature is to change its style only, without selecting it. Ivan's idea (selectOnHover:false) sounds good. I'd like to see the code and try it. Ivan, could you share what you've done ? At the same time, I'd like to try to add events to the control and its selectedFeatures array, like Eric said. Finally, I would like to know more about what you think about all this. Best regards, Alexandre Ivan Grcic wrote: > On Mon, Jan 19, 2009 at 10:19 PM, Eric Lemoine <[email protected]> wrote: > >> On Mon, Jan 19, 2009 at 3:30 PM, Alexandre Dube <[email protected]> wrote: >> >>> Hi Eric, >>> >>> I took a look at the SelectFeature control. Now I understand what you >>> meant and it makes sense. Also, it's also making sense to have this control >>> have the possibility to highlight on hover or on click. >>> >>> "beforefeaturehighlighted" and "featurehighlighted" events make sense, but >>> a "featureunhighlighted" (or some other term meaning that the feature was >>> highlighted and is now no more) would also be useful. >>> >> Alexandre, >> >> The more I think about this highlight feature control the more I think >> there's no room for both a select feature and a highlight feature >> controls. >> >> > Same opinion here. We already have a bunch of controls, and now adding > two very similar ones... > > Currently im using slightly modified SelectFeature control, i added > one more option to it: selectOnHover, thats how i quickly solved the > problem of only highlighting feature without selecting it. > > If selectOnHover is true, feature is selected&higlighted (select > method is called) on hover, if its false feature is only higlighted, > not selected. > > >> What causes people trouble is that they can't use two select feature >> controls, one in hover mode and the other in click mode. This is >> because once a feature is hovered it is selected, and cannot be >> selected again when it is clicked. >> >> Maybe we could modify the select feature control so that (1) it >> optionally uses its own selectedFeatures array, as opposed to relying >> on the layer's, and (b) defines its own "beforefeatureselected", >> "featureselected" and "featureunselected" event types. In this way, >> one should be able to use two select feature controls, and get >> "featureselected" events, from the first control when features are >> hovered and from the second control when features are clicked. >> >> Tell me what you think, >> >> > > >> -- >> Eric >> _______________________________________________ >> Users mailing list >> [email protected] >> http://openlayers.org/mailman/listinfo/users >> >> > > > > -- Alexandre Dubé Mapgears www.mapgears.com _______________________________________________ Users mailing list [email protected] http://openlayers.org/mailman/listinfo/users
