geekyeggo / sharpdeck Goto Github PK

Hi.

Not sure if I am using the plugin wrong here, or this is a bug.

I have a button, when I press it, it calls a service and changes a value.
When this value is changed, the service will send a callback that triggers an event, that then calls SetStateAsync from a method inside the Action.

I have added Trace.WriteLine that writes out the state I want, but sometimes this is not updated on the button.

If I change the value in the application, without pressing the button, I have not seen this fail (yet).

Similar to HttpPost / HttpGet, it would be nice if it were possible to decorate methods within a controller that intercepted requests from a Property Inspector, and where desired, "returned" a result.

It should be possible to

• Opt of out auto-routing requests from sendToPlugin.
• Specify the event name (two-way)

Missing endpoints from the new v4.1 SDK.

Events Sent

• getSettings
• setGlobalSettings
• getGlobalSettings
• logMessage

Events Received

• didReceiveSettings
• didReceiveGlobalSettings
• propertyInspectorDidAppear
• propertyInspectorDidDisappear

Unless I am mistake, the example on the main page that has:
SharpDeck.StreamDeckClient.Run();

ought to be
SharpDeck.StreamDeckPlugin.Run();

ActionPayload currently supports loading the settings, however this uses JObject; it is possible to convert the settings using the helper method T GetSettings<T>(), however it may be beneficial if there were settings and methods directly within the action.

Considerations

• Should a new StreamDeckAction<TSettings> be added to provide helpers?
• When should the settings be loaded; each event vs manual?
• When should the settings be saved; INotifyPropertyChanged vs manual?

When creating a new release in GitHub, the new version should be published automatically to NuGet.org.

With the introduction of better DI coming in 1.0.2, unit tests should be added to ensure everything is running smoothly.

The example should be updated to better demonstrate the usage of the Property Inspector decorators being introduced in #5. This should include a sample PI, ideally using the recommended JS from the Elgato SDK github.

When a button is pressed repeatedly and faster than LongKeyPressInterval, the implementation of StreamDeckAction triggers falsely OnKeyLongPress.

The flow is as follows:

1. Button is pressed
2. OnKeyDown() puts the EventArgs on the stack and starts Task.Delay()
3. Button is released
4. OnKeyUp() successfully pops the EventArgs from the stack and thus calls OnKeyPress() (the callback for short keypress).
5. Problem: The Task.Delay() is still active and waiting.
6. Button is pressed again. This has to happen with 500ms after the first time that the button was pressed (or <= LongKeyPressInterval)
7. OnKeyDown() puts the EventArgs on the stack
8. Task.Delay() from the first button press finishes and successfully pops an event from the stack. Unfortunately, this is the event from the second button press and not from the first button press. In consequence, the callback OnKeyLongPresss() is getting called.

I think that TryHandleKeyPress() must also cancel Task.Delay() when it successfully popped an item from the stack.

Would be nice if examples included at least one entry into an action's property inspector so we could figure out the rest via elgato's docs.

Using 7.0.0 beta for SD+ support and I can't seem to figure out how to get the property inspector to show some controls.

To better handle deadlocking of async methods, particularly those triggered within the main StreamDeckClient, we should.

• ConfigureAwait(false) on the top level of start.
• Update the event raisers to be async; a QOL improvement for overriding within custom actions.

Steps to replicate bug:

1. Create a Play Action at location [1,1] (ref: action 1).
2. 1. Assign an audio track.
3. Create a 2nd Play Action at location [1,2] (ref: action 2).
4. 1. Assign a different audio track.
5. Remove action 1.
6. Move action 2 to [1,1] (where action 1 was).
7. Play action 2 - Audio track is incorrect.

Pending release