Does anyone know if there is an event handler that fires when the selection changes in the Rhino layer manager? It does not fire with “LayerTableEvent” and I’ve dug around in Rhino.UI and haven’t found anything.
I can get to the currently selected layers via the LayerTable.GetSelected() method, but I’d like to be able to grab the currently selected layer(s) in real time and I can’t find an Event that will let me do that. Even if there is a generic UI event that triggers when the panel is manipulated, I can selectively expire a downstream output by checking the currently selected layers against a cached list.
There is no event that is triggered when a Layer item is selected in some Layer UI. Unlike objects, layers do not have a selected state, which is (probably) why there is no such event.
But yet there is a GetSelectedLayers() method on the LayerTable that I have implemented successfully, so it seems that the state is inferred somehow… perhaps I could use a mouseclick handler in concert with that method to achieve what I want? I’ll give it a try, despite being wary of loading up my environment with a billion event handlers that are firing nonstop.
GetSelectedLayers was added by popular demand. But like I said, Layers do not have a selected state - items in a list do. And the referenced method doesn’t work on the Mac, so there’s that.
Is there a click listener that responds to clicks in the LayerManager panel? I have successfully implemented a click listener for Rhino.UI.OnMouseDown, but it only responds when clicking in a viewport, not in panels…
The layer list is a window, thus it receives and processes mouse messages. Short of hooking the mouse, I don’t see how your going to get anything useful. And even then, you don’t know where the mouse down “hit” or of any keyboard modifiers were pressed.
Yeah, we’ve been able to get Modifiers in tandem but I was thinking I didn’t need them… basically I was going to maintain a cache of selected layers and then call GetSelectedLaters() every time I get a mouse click and compare it to the cache before deciding whether to expire the component.
By “hooking the mouse”, I assume that you mean at the OS level?
So… just an update, since I worked through the crashes for solving various event cases.
The component uses an unholy matrimony of OS-level Mouse Hook, OS-level key listener, and custom debouncer to avoid using ScheduleSolution (which crashes Rhino).
Had to put a delay on my events because layer deselect happens on mouseup, meaning a mouseup listener doesn’t catch the changed layerstate. ScheduleSolution results in a StackOverflow hard crash, but luckily I solved this problem for layer listening a while back so I just implemented the custom debouncer. You’ll notice that the key listener is used because changing a layer name in the layer panel doesn’t catch the new state (because there’s no mouse click).
I throttle the ExpireSolution in the event handler using a cache so that the component doesn’t fire on every mouse and keypress, only when the selected layers have changed.
All that said, I’m slightly terrified to use this component in a deployed product, I have this sneaking anxiety that using it in a large definition with all my other listeners active is likely to blow up Rhino/GH. I’ll save it for emergency usage only until I can prove it in the wild.
I’ll save it for emergency usage only until I can prove it in the wild.