MuShoo

I'm pretty sure there isn't, but is there any way to make a number box or flonum automatically deselect after hitting the enter/return key? I thought this was how it worked in 4.6 but it's been a while so I could be wrong.

The problem is that I use some number keys for a tool change on a waveform~ object, and sometimes users seem to forget/not realize that they have to click elsewhere in the patch after entering data in a numeric input, and then trying to shift tools causes that numeric box to input irrelevant data.

I'm pretty sure there isn't, but is there any way to make a number box or flonum automatically deselect after hitting the enter/return key?  I thought this was how it worked in 4.6 but it's been a while so I could be wrong.

The problem is that I use some number keys for a tool change on a waveform~ object, and sometimes users seem to forget/not realize that they have to click elsewhere in the patch after entering data in a numeric input, and then trying to shift tools causes that numeric box to input irrelevant data.


flonumnumber-box-interface-question

one way you could do this is to use and filter the mouse position info. when lying over the number box so that it responds and then when it doesn't lie over the box deselects it or ignores the click using an "ignoreclick"-type message to a object. check help-files for and (in help-file check the

subpatch). otherwise, you could also probably javascript it. either way, it's not built-in but you can definitely build it. (also, if you want it specifically deseleceted after return/enter key, you could combine key detection using the object with any of the above mentioned methods.)

one way you could do this is to use  and filter the mouse position info. when lying over the number box so that it responds and then when it doesn't lie over the box deselects it or ignores the click using an "ignoreclick"-type message to a  object. check help-files for  and  (in  help-file check the


 subpatch). otherwise, you could also probably javascript it. either way, it's not built-in but you can definitely build it. (also, if you want it specifically deseleceted after return/enter key, you could combine key detection using the  object with any of the above mentioned methods.)

You can select a number box by sending it the message "select", which of

course deselects other number boxes. So one way to do this would be to

trigger such a message to a hidden, dummy number box upon output from the

> I'm pretty sure there isn't, but is there any way to make a number box or

> flonum automatically deselect after hitting the enter/return key? I thought

> this was how it worked in 4.6 but it's been a while so I could be wrong.

> The problem is that I use some number keys for a tool change on a waveform~

> object, and sometimes users seem to forget/not realize that they have to

> click elsewhere in the patch after entering data in a numeric input, and

> then trying to shift tools causes that numeric box to input irrelevant data.

You can select a number box by sending it the message "select", which of
course deselects other number boxes. So one way to do this would be to
trigger such a message to a hidden, dummy number box upon output from the
number boxes that you're actually using.

>
> I'm pretty sure there isn't, but is there any way to make a number box or
> flonum automatically deselect after hitting the enter/return key?  I thought
> this was how it worked in 4.6 but it's been a while so I could be wrong.
>
> The problem is that I use some number keys for a tool change on a waveform~
> object, and sometimes users seem to forget/not realize that they have to
> click elsewhere in the patch after entering data in a numeric input, and
> then trying to shift tools causes that numeric box to input irrelevant data.
>

Both of these are good ideas, but I'm not sure what the use of the [thispatcher] object is, in Raja's idea. And Dan's idea might confuse my users even more, since now whenever they type in a number to switch tools, it's typing to a hidden number box, instead of something they can see.

I've approached the problem from a different angle, and just made the key commands be menu items with command-key links. Holding command+1 doesn't type in a focused numeric box, so that seems to be working! But I like the ideas, I'm sure I'll use them somewhere.

Both of these are good ideas, but I'm not sure what the use of the [thispatcher] object is, in Raja's idea.  And Dan's idea might confuse my users even more, since now whenever they type in a number to switch tools, it's typing to a hidden number box, instead of something they can see.

I've approached the problem from a different angle, and just made the key commands be menu items with command-key links.  Holding command+1 doesn't type in a focused numeric box, so that seems to be working!  But I like the ideas, I'm sure I'll use them somewhere.

I realized after I wrote it, that using thispatcher to "ignoreclick" or "respondtoclick" wouldn't work because they would still be typing numbers into the selected number-box(despite lack of mouse-input).

Daniel's idea is a good one, too, however, any time numbers are being typed into any number box(hidden or otherwise), you lose the ability for object to pick up number-keypresses(so you could probably use the "cantchange" attribute of the hidden number box to achieve this solution).

So your final solution is probably the best and quickest.

However, here's a solution according to your original plan which works so long as your users make sure they mouse outside the area of the number-box when they are done with it and surely, with some additional creative gating you can figure out how to mod this path to deselect the number-box when a return/enter keypress is detected. Just in case(eventually you might run out of key-shortcuts and will actually want the numbered keys), you can use this for future reference:

Daniel's idea is a good one, too, however, any time numbers are being typed into any number box(hidden or otherwise), you lose the ability for  object to pick up number-keypresses(so you could probably use the "cantchange" attribute of the hidden number box to achieve this solution).

oh, and i'm finding that when i paste that into a new patch, i sometimes need to change the mouse-pickup-coordinates in the "if,then,else" objects that refer to the area within the big number box.

This is the very reason I don't use numbers to trigger events, though they certainly are intuitive to use. And shift-# works, but that's awkward. I stick to the row of keys below the numbers, and save the numbers for typing into the boxes.

You know about the right outlet of the number boxes, yes? Use that to hit a "select" to tab thru a series of connected number boxes, just like in most applications. This doesn't solve your original problem of deselecting. If what you want is a "select nothing", one past forum posting spoke of a "create new number box, select it, delete it" method using thispatcher. You could have the tab key trigger that sequence via the right outlet.

This used to bug me a lot when I first switched from PD. I use this subpatch to deal with the problem.

Just connect the output of your numberbox to this abstraction and it will deselect the numberbox whenever it sends output. If you like the stay selected ability sometimes, you could instead connect this patch to the tab outlet and so the numberbox will stay selected until you hit tab.

This used to bug me a lot when I first switched from PD.  I use this subpatch to deal with the problem.

Just connect the output of your numberbox to this abstraction and it will deselect the numberbox whenever it sends output.  If you like the stay selected ability sometimes, you could instead connect this patch to the tab outlet and so the numberbox will stay selected until you hit tab.


Roth, yours seems to work on it's own, but when I connect it to a number box it stops doing anything, and I can't figure out why. I see a bang going into the [b 3] object but the number box doesn't deselect.

Very odd, but an excellent way of doing it (if I could get it to work :/)

Roth, yours seems to work on it's own, but when I connect it to a number box it stops doing anything, and I can't figure out why.  I see a bang going into the [b 3] object but the number box doesn't deselect.

Very odd, but an excellent way of doing it (if I could get it to work :/)


Well, to be honest, I haven't tried that trick since pre-Max5 (I have been putting off adding that abstraction to my new Max5 interfaces as a finishing step I was going to apply this weekend).

I'll try to see if I can figure out what is going on over the next few days, but if someone else has a chance to offer some help before I can figure it out it would be much appreciated.

Perhaps this is a bug, because it works as expected in Max 4.6.3.

•abstraction does not work as intended under Max 5

•manually triggering all three messages vs. triggering with [b 3] seems to work

•disconnecting "script delete numdeselctor" from the [b 3] seems to create a partially working abstraction. [thispatcher] successfully creates the new numberbox and selects it. After that, manually clicking the "script delete numdeselector" will successfully destroy it.

The problem appears to be with the "script delete" message to [thispatcher]. My guess, since the first two messages seem to worok on their own, is that after deleting the new numberbox, Max5 automatically selects the last selected numberbox.

Any word if this is a feature change or a bug?

Perhaps this is a bug, because it works as expected in Max 4.6.3.  

•abstraction does not work as intended under Max 5
•manually triggering all three messages vs. triggering with [b 3] seems to work
•disconnecting "script delete numdeselctor" from the [b 3] seems to create a partially working abstraction.  [thispatcher] successfully creates the new numberbox and selects it.  After that, manually clicking the "script delete numdeselector" will successfully destroy it.

The problem appears to be with the "script delete" message to [thispatcher].  My guess, since the first two messages seem to worok on their own, is that after deleting the new numberbox, Max5 automatically selects the last selected numberbox.

Any word if this is a feature change or a bug?


I made some minor progress on your thing, Roth. It only works if the subpatcher is open, though. Not sure why.

I made some minor progress on your thing, Roth.  It only works if the subpatcher is open, though.  Not sure why.

So it looks like something in the Max 5 drawing system killed this script. It looks like the "select" message will not select numberboxes in closed subpatches. Also, maybe the timing of object generation has changed, but the delete message does seem to need to be differed.

I came up with a JavaScript solution that includes a delay for the delete message and solves the open subpatch problem by creating and deleting the numberbox in the parent patch. As you can see, it accepts both int and bang input so that you can trigger this script with either outlet from a numberbox.

destroyme = this.patcher.newdefault(50, 50, "number");

t =    new Task(destroyIt, this, destroyme);

//scheduling delay in ms, increase if numberboxes do not deselect 

//scheduling delay in ms, incease if numberboxes do not deselect 

So it looks like something in the Max 5 drawing system killed this script. It looks like the "select" message will not select numberboxes in closed subpatches.  Also, maybe the timing of object generation has changed, but the delete message does seem to need to be differed.

I came up with a JavaScript solution that includes a delay for the delete message and solves the open subpatch problem by creating and deleting the numberbox in the parent patch.  As you can see, it accepts both int and bang input so that you can trigger this script with either outlet from a numberbox.

function destroyIt(o)
{
    this.patcher.remove(o);
}

function msg_int(x)
{
    destroyme = this.patcher.newdefault(50, 50, "number");
    destroyme.message("select");

    t =	new Task(destroyIt, this, destroyme);
    //scheduling delay in ms, increase if numberboxes do not deselect                                                                                  
    t.schedule(4);
}

function bang()
{
    destroyme = this.patcher.newdefault(50, 50, "number");
    destroyme.message("select");

    t =new Task(destroyIt, this, destroyme);
    //scheduling delay in ms, incease if numberboxes do not deselect                                                                                   
    t.schedule(4);
}


Flonum/Number box interface question.