Having trouble with a scrollbar in a nested [bpatcher]
Hi everybody!
So over the past few weeks, I've put together a searchable dropdown menu using a mix of [jsui] (which implements the menu, a custom scrollbar, more on that in a moment), a text editor, and some other JS to try to intercept clicks over the text editor in order to "open" the menu, and forward text edits to the JS to update the model of visible entries.
To be honest, it worked like a charm, and so I can revert to that working state if needed... but it was becoming a challenge to maintain it, and I've been trying to reduce the amount of my own stuff in this patch. I didn't realize until fairly recently that I could use [bpatcher]'s vertical scrollbars and just nest a jsui within that thing. And this does indeed work
However, the first problem: actually clicking on the dropdown does not work. This is due to the hacky "focus / blur" machinery I added. Because I can't directly intercept or forward mouse events to my [texteditor] control, I use [mousestate] to figure out if I'm clicking over the editor or not, and using these to notify the dropdown jsui whether to open or not.
I was able to solve this by creating a second mousestate polling listener for the bpatcher, and removing the old "blur" notification to instead rely on the new one, which takes the entire dropdown's screen into consideration. This works pretty nicely, although it's a bummer to have a separate mouse state checker.
So the next problem, and this is one I have not solved yet: adjusting the scrollbar in response to onwheel events in [jsui]. Although the [Patcher] documentation (https://docs.cycling74.com/apiref/js/patcher/#scrolloffset, https://docs.cycling74.com/apiref/js/patcher/#scrollorigin) list these properties as being available, in 9.1.2, every effort I've made (`patcher.scrollorigin, patcher.scrolloffset, box.patcher, patcher.parentpatcher, parent.box.parentpatcher, patcher.getattr("scrolloffset"), etc etc`) have all come back as "undefined" or null in the case of getattr/box.getattr. So I'm at a bit of a loss of where these guys are, if they are still present in the runtime. Granted, I probably wasn't super exhaustive in looking for them, but I'm hoping someone else has encountered this.
The scrollbar in the menu does work when the mouse is over the scrollbar itself, but personally I prefer wheel scrolling and touchscrolling to work in both cases, and being able to use meta keys to trigger faster scrolling through large lists would be a nice too.
I'll be pretty excited to share this project, I'm expecting it to be pretty useful for my own compositions. Just really want to nail the UX before putting it out there.
Thanks in advance for any suggestions or advice.
I guess I answered my own question about where scrolloffset/scrollorigin is, it seems it was removed in the 9.0.0 release. https://cycling74.com/releases/max/9.0.0, looking like manipulating scrolling may have been causing some problems.
So, I have it working in my JS-only version, but maybe an alternative to reading/writing the scroll offset will be available at some point. it's almost possible with wind.scrollto() with the window in bpatcher mode, but without being able to read the current scroll offset, it doesn't make a lot of sense.
I may have a solution... returning 0 from hittest (and moving click logic to a separate function with messages from a mousestate) allows me to keep the convenient bits from onclick() while still taking advantage of the native scrollbars behaviour, it seems like it's probably the best of both worlds.
... except, it probably makes onidle() a bit more complicated. but still, progress, maybe.