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 > _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
