Hi Eric, You're right. So instead of removing the last renderIntent from the stack, we need to remove the last renderIntent of the current SelectFeature.
SFC = SelectFeature Control RIA = renderIntents array Let's say the mouse goes hover a feature and get selected by a 1st SFC : RIA : ["temporary"] Then the user click it to select it with an other SFC : RIA : ["temporary", "select"] Then the mouse goes out of the feature, unselecting it from the 1st SFC : RIA : ["select"] The feature is still drawn with the "select" renderIntent. What do you think ? With this, you don't need to have 4 different possibilities. The user can define an infinite number of different renderIntents, have a styleMap defining each one of them. Alexandre Eric Lemoine wrote: > Hi Alex > > Consider this sequence: mouse goes over feature, feature is clicked > (for selection), and clicked again (for unselection). With your "stack > of intents" logic, the feature isn't redrawn as a result of the second > click; instead it should be redrawn with the hover control's render > intent, shouldn't it? > > Eric > > 2009/1/23, Alexandre Dube <[email protected]>: > >> 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 >> [email protected] >> http://openlayers.org/mailman/listinfo/dev >> >> -- Alexandre Dubé Mapgears www.mapgears.com _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
