[OpenLayers-Dev] multipleSelectFeature on one layer

Amos Hayes ahayes at gcrc.carleton.ca
Fri Jan 23 15:49:14 EST 2009

Sorry, that should have read 'the 4 states to worry about'.

Also, I can envision a case where you do multiple selection by  
dragging a box. In that case, you might go from state 1 to state 4  
without going through 2 and 3. Either way, it should be possible to  
change state from any to any and have the styles keep up.

Amos Hayes
Geomatics and Cartographic Research Centre
Carleton University
ahayes at gcrc.carleton.ca

On 23-Jan-09, at 3:42 PM, Amos Hayes wrote:

> Hi Alexandre.
> I like the idea of a stack of styles.
> If we use select (clicked) and hover (moused over) as distinct  
> terms, then the 4 styles to worry about are:
> 1. Not selected and not hovering (normal)
> 2. Not selected but hovering (user is exploring with the mouse)
> 3. Selected and hovering (user has made a selection and mouse is  
> over the selected feature)
> 4. Selected but not hovering (user has made a selection but is now  
> somewhere else with the mouse)
> It should be possible to style each of these feature states  
> differently. Any style stacking code would have to be able to go  
> from one to four and back again. Application developers will also  
> want a way to put the feature directly into any one of those states.
> Hope that helps.
> --
> Amos Hayes
> Geomatics and Cartographic Research Centre
> Carleton University
> ahayes at gcrc.carleton.ca
> +1.613.520.2600x8179
> On 23-Jan-09, at 3:10 PM, Alexandre Dube wrote:
>> Hi devs,
>> Eric was right :
>> <<<
>> A first note. The current select feature implementation should
>> accomodate this use case: two controls on the same layer, one working
>> on click and the other on hover, only one of them actually changing
>> the feature style. This is achievable by registering a
>> beforefeatureselected listener, and have this listener return false.
>> Adding beforefeatureunselected might help fully accomodate that use
>> case.
>> Now if we want the two controls to do feature styling, we need the
>> stuff I mentioned previously - per-control selectedFeatures arrays  
>> and
>> events. But this is unfortunately not sufficient. Use case: two
>> controls, one working on click and the other on hover, both doing
>> feature styling but with different render intents. If we have this
>> sequence "mouse goes over feature, mouse clicks feature, mouse goes
>> out of feature", then the feature ends up being rendered with the
>> "default" render intent, while it's still selected from the click
>> control's perspective. In most cases, this isn't desirable I think.
>> At this point I don't have a solution to the above issue.
>> An idea that could resolve this issue : features could have a stack  
>> of
>> renderIntent instead of a normal string value.  Instead of  
>> assigning new
>> renderIntent value, it would stack in renderIntents array.  Instead  
>> of
>> reseting to "default", it would remove the last renderIntent in the
>> stack.  When the stack is empty, the "default" renderIntent is  
>> applied.
>> That could work.  I'll try this and come back with more details.
>> Alexandre
>> Alexandre Dube wrote:
>>> Hi devs,
>>> I would like to propose some changes about the SelectFeature  
>>> control.
>>> First, I'll introduce what I want to do : I want to change the color
>>> of a feature while the mouse is over it without selecting it.  I  
>>> managed
>>> to do this by building a customized control similar to the  
>>> SelectFeature
>>> control named HighlightFeature.  I shared the code and some people
>>> showed interest in this feature.  In fact, it was a good enough to  
>>> be
>>> added to trunk but there was a problem : it's too similar to the
>>> SelectFeature control.
>>> My first new option was to modify the SelectFeature control to be  
>>> able
>>> to select and highlight.  That's what I did, but I hit a wall : I  
>>> needed
>>> to add more new events "beforefeaturehighlighted",  
>>> "featurehighlighted",
>>> etc.  a new array of highlightedFeatures, etc...  That also became a
>>> pain because it was yet an other duplication of something already
>>> existant ( similair "select" feature events, an array of selected
>>> features, etc....)
>>> SO, that brings me to this solution, the first one Eric Lemoine
>>> proposed : an array of selectedFeatures and select events for the
>>> control ( without removing the ones of the layer ).  Doing that, one
>>> vector layer could have multiple select feature controls that  
>>> would know
>>> which feature it has selected, they could all have a different
>>> renderIntent value ( this is already possible ) or their own style.
>>> Then, the user could interact directly with the desired control's
>>> selectedFeatures.
>>> My example : One SelectFeature that select on click, has the default
>>> render intent "select", on which I register a "featureselected" to
>>> display a form to fill.  And one other SelectFeature that select on
>>> hover, has a custom render intent "temporary" to have a different  
>>> color
>>> and an event registered to "featureselected" to display a quick  
>>> popup of
>>> the infos of the hovered feature.
>>> Even my DeleteFeature control I created a couple of weeks ago could
>>> work by using an other SelectFeature control and using its own
>>> featureSelected array.
>>> I'll make thoses small changes, an example and propose this as an
>>> enhancement.  What do you think ?
>>> Regards,
>> -- 
>> Alexandre Dubé
>> Mapgears
>> www.mapgears.com
>> _______________________________________________
>> Dev mailing list
>> Dev at openlayers.org
>> http://openlayers.org/mailman/listinfo/dev

More information about the Dev mailing list