Maybe have the number box bkgd be transparent, and have a panel behind it (or in front of it) that highlights?

...or change the color of the numberbox´background by messages.

Both ideas that I'd thought of, but that are somewhat cumbersome when you have large amounts of number boxes - when you add in the logic for telling when a box is highlighted or not, it starts to get ugly. Plus, neither of those methods would work if you just click on the number box to highlight it.

Would be how it works, but there's a number of problems I have with it - the biggest being the rats nest of cables it ends up producing. Other issues are that there's no way to know when the user deselects a box by clicking (thus highlighting none of the boxes) without also adding in a ubutton or similar covering the background of the whole patch. And, like I'd mentioned earlier, there's apparently no way to tell if the user has selected a number box by clicking on it.

some more ideas...an interesting challenge :)

I don't think there's a way to tell if the user clicked outside a box except using the ubutton or [mousestate], but you can utilize [hover] for some more checking.

It might be nice to have "select hilights box" as a checkbox attribute for numbox and flonum. So it would do the same as mousing does (highlight the box) when you select it programmatically via tab or other means.

You could also have a third outlet which bangs when the numbox is clicked, so you don't have to wait for an actual number output.

Updated example patch with some more features :)

Seejay, those are both veeery interesting concepts - though problematic if I am using scripting names on things for pattr/autopattr purposes. The other problem with the second version is that it can affect named objects that are not number boxes (like toggles or [functions] or what have you).

However, I'm looking more into [hover] and it seems like the third outlet might be handy as well, to unhighlight when the mouse leaves the object.

Perhaps there's a way with Javascript to check if an object with scripting name 'blah' is of class 'flonum'? I'm not well versed enough in Max Java to know how to do that, though.

Whoop, making some progressing on testing if the object hovered is a flonum! Sample incoming in a bit.

Alright, not sure if javascript get copied with copy compressed:

Here's the javascript code just in case:

function highlightnumbox(a) { var b = this.patcher.getnamed(a); if (b.maxclass == "flonum" || b.maxclass == "number") { b.message("bgcolor", ".5", ".7", ".7") } }

function dehighlightnumbox(a) { var b = this.patcher.getnamed(a); if (b.maxclass == "flonum" || b.maxclass == "number") { b.message("bgcolor", "1", "1", "1") } }

Sounds cool, though I don't see a problem with named objects and pattr, why would that be an issue? The names have to be unique, so there shouldn't be any confusion there. I just named them "numbox[1]" etc, but they could be called "frank" or "bob". The number index is handy so that when you duplicate it, it automatically increments the value in the brackets.

I guess [autopattr] might name things that would be problematic, so just name things manually I guess...

I like the javascript idea too, that will eliminate yet more cords! :)

I just had a brief-ish look at your patch, it looked like it was doing something with the number in brackets (IE, numbox[1]). I'm thinking the javascript way is the 'cleanest' though - it doesn't need any extra objects connected directly to the number boxes! Next step is to see if I can both make it Select the number box when you hover (shouldn't be hard, just another message to send), and de-highlight when you tab away. Which I can probably do by having a message connected to the second outlet of the numberbox, which contains the name of the next number box in the chain - won't even need to patch the number boxes together!

Hooray! (And thanks for the help!)