Hey, Eric Lemoine wrote: > Hi > > If I understand you correctly, on unselect you always redraw the > feature after removing the intent from the intents array, right? >
Yes > Does your logic work with two controls, two of which having the same > render intent. If the intents array is ["a", "b", "a"], I fear that an > not the proper intent will be removed. Am I wrong? > It does, because having the same renderIntent == having the same style applied. The only issue remaining is : does the layer need to keep its selectedFeatures array ? Alexandre > Cheers, > > Eric > > 2009/1/26, Alexandre Dube <[email protected]>: > >> 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 >> >> >> -- Alexandre Dubé Mapgears www.mapgears.com _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
