Using show_topbar in advanced feedback causes imageBuffer to disappear if show_topbar mismatch

[wojtek14a]

While providing show_topbar and imageBuffer parameters in advanced feedback, the buffer is only drew on button when Topbar setting in button config is the same one that is provided in advanced feedback. If there is mismatch, the buffer is not drawn.
All the other parameters are simply ignored, like bgcolor, color, alignment etc. In this case the drawing of topbar is ignored as well but it causes the buffer to disapear.

[Julusian]

Yeah I can see why this is happening.

Because showing/hiding the topbar affects the size of the bitmap that should be produced by the feedback, this is resulting in a disagreement on what the dimensions should be. At the point where it is drawn, the byte length doesn't match the expected dimensions so it gets discarded.

I am questioning if it even makes sense for the show_topbar field to be exposed to feedbacks like this, it is probably only there because it is in the types and is needed for presets, and while it techncially kind of works, there are some edge cases like this.
If we try to handle this case properly, we easily open ourselves up to infinite loops; a feedback changes the topbar state, that means we need to force all feedbacks on the button to invalidate with the new pixel size. that same feedback could easily change its mind now causing the topbar state to then flip back, meaning a new force invalidate. and so on.
Also whenever the topbar state does change, any imagebuffers will be unusable for at least one draw of the button, so it will result in flickering.

---

And to pile onto this, in 4.0/4.1 we are looking to massively overhaul the drawing, which might go as far as to deprecate these 'advanced' feedbacks (replacement for part of their functionality TBD).

I say this simply as I am not sure it is worth the time to put any effort into trying to fix this when it is likely to be intentionally unsupported in the near future.

[krocheck]

@wojtek14a I agree with @Julusian that it may be good to just wait to see how the drawing classes shake out, but if you want to correct for this you are able to read the needed image raster size. Here's the callback event object.

You can reference my implementation in shure-wireless, tracing this call through to internalApi.js and then icons.js