Hi, first up: Thanks for the plugin! I had something similar, but making the history serialized is really useful!
However after adding SelectionHistory to my project a lot of my shortcuts were not working anymore (especially in ShaderGraph). Additionally there was some other weird behaviour with inputs being executed in wrong context etc.
After some digging I found the issue here:
When using a MulticastDelegate like the one created with Delegate.Combine(processEvent, value); the last return value get's returned to the method invoker. That means that after adding this class GUIUtility.processEvent will always return false. This is of course not intended, as we only want to intercept the event and not hinder any additional processes from happening.
As an easy fix you could just reverse the parameters
Delegate.Combine(value, processEvent);
This way our method gets called, but does not change the output of the original method.
For myself I've switched it to a more explicit implementation that does not rely on delegates, but just wraps the listener and always calls the original handler unless we are intercepting a Mouse4 oder Mouse5 event. It's a lot cleaner imo, but also a bit more code.
Hi, first up: Thanks for the plugin! I had something similar, but making the history serialized is really useful!
However after adding
SelectionHistory
to my project a lot of my shortcuts were not working anymore (especially in ShaderGraph). Additionally there was some other weird behaviour with inputs being executed in wrong context etc. After some digging I found the issue here:https://github.com/garettbass/UnityExtensions.SelectionHistory/blob/11b69815f7156577d41c4d39551001aa304a8588/Editor/SelectionHistory.cs#L139C47-L139C47
When using a MulticastDelegate like the one created with
Delegate.Combine(processEvent, value);
the last return value get's returned to the method invoker. That means that after adding this classGUIUtility.processEvent
will always return false. This is of course not intended, as we only want to intercept the event and not hinder any additional processes from happening. As an easy fix you could just reverse the parametersDelegate.Combine(value, processEvent);
This way our method gets called, but does not change the output of the original method.For myself I've switched it to a more explicit implementation that does not rely on delegates, but just wraps the listener and always calls the original handler unless we are intercepting a Mouse4 oder Mouse5 event. It's a lot cleaner imo, but also a bit more code.