Just sent an apology to Malc....
Remember how at the end of the schematic post I wrote some stuff about how "releaseMouse" had to be in "mouseLUpCaptured" and not "mouseLUp"?
Great advice, that - I really should have taken it myself, and actually remembered to include the "releaseMouse" command in my code!
Still doesn't explain why it affected some edit boxes and not others - but not giving the mouse control back to Windoze certainly isn't the right way to go about things!
Fixed schematic is in the top post - I also swapped the SHIFT and CTRL modifier keys to match the old SM way that folks are used to.
P.S.) Sorry it's taken a while to sort this - been bed-ridden with a humdinger head-cold all weekend. Still feel like sh*t, but there's only so much boredom I can take! When I feel a bit more like staring at a screen for a few hours, I'll make a start on some little upgrades I have in mind - MIDI learn is top of the list, but I'm open to suggestions.
P.P.S) Billy was asking about the weird way that re-draws work, so here a brief description...
Basically, there's a timer that sets the frame rate for drawing the GUI (using input 100). When the knob value changes, it sets a flag "@redraw_pending" to true. If the flag is true on the next tick, a redraw happens, and the flag is reset to false.
However, if the flag isn't true, the timer stops, so that there aren't a load of useless Ruby events flying around after you've let go of the knob. Next time the knob changes, a redraw happens straight away, and then the ticker gets restarted. "@redraw_running" is just another flag that remembers whether the ticker is active or not.
The rest of the logic is a simply a little test to see if any part of the GUI actually changed, in case the value change is so small that there wouldn't be anything new to see.