Whether or not you have following the ‘Selection by polygon’ conversation, I am going to make a proposal regarding the behavior of the SelectionChanged and SelectBoxFinal events. To summarize, the two events should be triggered independently of each other, and behave in a consistent manner independent of each other.
Regarding the SelectionChanged event, the following describes the current behavior, and will remain unchanged.
Both the cmSelection and cmSelectByPolygon tools are capable of selecting from a single layer (via the ChooseLayer event) or from multiple layers (based on the Shapefile.Selectable property).
Whether using the cmSelection or cmSelectByPolygon tool, if any shapes are ‘selected’, you will receive a SelectionChanged event for each layer containing ‘selected’ shapes.
Regarding the SelectBoxFinal event
If you set the Map.SendSelectBoxFinal property = True, then the SelectBoxFinal event should be raised any time you finish dragging a selection box on the screen. This currently applies to the both the cmZoomIn and cmSelection tools, and should not be dependent upon whether or not any shapes were actually ‘selected’ by the cmSelection tool.
This behavior differs slightly from what has been in place up through v4.9.x of MapWinGIS, for which the SelectBoxFinal event was only raised from the cmSelection tool if no shapes were ‘selected’ by the tool. It is more consistent to always raise the SelectBoxFinal event, whether or not any shapes were ‘selected’. The SelectionChanged event is always raised first, and thus the programmer can decide within the SelectBoxFinal event whether or not any further action is necessary.
I believe these rules represent a simple and intuitive behavior, and result in a consistent and predictable programming paradigm.
Please feel free to provide any feedback as you see fit, and unless there are any serious concerns, I will likely move forward with this behavior within the next week. My goal would be to get these updates into a near-term follow-up to the v5.0 release.
I can perfectly live with the changes you suggest, however I have a few remarks/suggestions which could further improve selection event handling IMO. Just some ideas, feel free to dismiss anything.
I do not find it intuitive that the SelectBoxFinal event is raised after the SelectionChanged event. The SelectBoxFinal event is related to finalizing the drag-select operation and should occur before the actual selection is made (due to which the SelectionChanged is fired). If the SelectBoxFinal event is made cancellable it can be used to control whether the selection should go through.
Related to this, it could be helpful to add an additional MapSelectionChanged event. This would be fired after every layer has changed selection and fired its respective SelectionChanged event. The MapSelectionChangedEvent args could contain a list of layer handles for which the selection changed. This would serve as a replacement for the function the current SelectBoxFinal event provides.
I think that the SelectionChanged event should be raised whenever the selection is changed, not only when there are shapes selected. As you described, currently if the user makes an empty selection box for a certain layer which has selected features, than the selection is cleared (thus changed) but no SelectionChanged will be emitted. Perhaps this can be solved easily by adding a SelectionCleared event, or by adding a flag to the SelectionChanged arguments indicating the selection was cleared. There is also the choice to be made to raise the event once (cleared & new selection combined) or twice (once after the clear call and a second time after the new selection is made).
Thanks for your comments. There’s a lot to consider when it comes to modifying event behavior. It certainly makes sense to me that an event should be raised whether features are selected or deselected.
For the near term, the behavior will at least be a little more consistent, and documented so that it should be more clear to the programmer what to expect.
As I said, I can live with what you proposed as well - so thanks for the consideration!
There is also a lot to say for (code) stability - even if it is inconsistent
