I'd be happy to drag my [numbox] to choose a value, then to select some function by pressing a [key].

Unfortunately, I can't do this second action because the numbox stays "lighted" and waits for a new entry.

I'd be happy to drag my [numbox] to choose a value, then to select some function by pressing a [key].
Unfortunately, I can't do this second action because the numbox stays "lighted" and waits for a new entry.
Is there a way to avoid this ?

num-vs-key

eliminate the delay if you don't want the typing option on the numbox

i had the same problem
this will deselect after 10 seconds
eliminate the delay if you don't want the typing option on the numbox

At 3:51 AM -0700 1/6/08, Derrick Giscloux wrote:

>I'd be happy to drag my [numbox] to choose a value, then to select some function by pressing a [key].

As long as you're willing to hit the Tab key after dragging your number, this sort of does what you want, I think.

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

At 3:51 AM -0700 1/6/08, Derrick Giscloux wrote:
>I'd be happy to drag my [numbox] to choose a value, then to select some function by pressing a [key].

-- 
Chris Muir           | "There are many futures and only one status quo.
cbm@well.com         |  This is why conservatives mostly agree,
http://www.xfade.com |  and radicals always argue." - Brian Eno


Another alternative: ice.key happily ignore the state of the number box and will report keystrokes whether or not your numbox is selected.

It's part of iCE Tools and, as such, commercial.

On 6 janv. 08, at 11:51, Derrick Giscloux wrote:

> I'd be happy to drag my [numbox] to choose a value, then to select 

> Unfortunately, I can't do this second action because the numbox 

> stays "lighted" and waits for a new entry.

You could use rs.numbox instead of the stock numbox object as it does 

On 6 janv. 08, at 11:51, Derrick Giscloux wrote:
> I'd be happy to drag my [numbox] to choose a value, then to select  
> some function by pressing a [key].
> Unfortunately, I can't do this second action because the numbox  
> stays "lighted" and waits for a new entry.
> Is there a way to avoid this ?

You could use rs.numbox instead of the stock numbox object as it does  
not get keyboard focus.
Of course, still Mac only.

-> numbox with locked "drag entry" flag .

So ... Max 5 request ?
-> numbox with locked "drag entry" flag .

That's why I don't use number keys as key-triggers for stuff, as tempting as it is (like a # = channel number or something). So when you're in a number box, you can still type any other key besides numbers, hyphen, period, Tab, or Enter and they will still get recognized (right?) and be usable as triggers. Popping open subpatches via pcontrol is my favorite use of key triggers, since you can control a lot of stuff while not using a mouse, or while seeing a full-screen visualization.

Using the TAB to go through a bunch of number boxes (via select as shown on this thread) is nice too: for example, if you use "f" to pop open a subpatch with a set of frequencies, you could also have it select the first box automatically. So you could hit "f", then type a frequency, then tab through the others and change them too, all without ever seeing the patch, if space is an issue or there are more interesting things to look at ;)

That's why I don't use number keys as key-triggers for stuff, as tempting as it is (like a # = channel number or something). So when you're in a number box, you can still type any other key besides numbers, hyphen, period, Tab, or Enter and they will still get recognized (right?) and be usable as triggers. Popping open subpatches via pcontrol is my favorite use of key triggers, since you can control a lot of stuff while not using a mouse, or while seeing a full-screen visualization. 

Using the TAB to go through a bunch of number boxes (via select as shown on this thread) is nice too: for example, if you use "f" to pop open a subpatch with a set of frequencies, you could also have it select the first box automatically. So you could hit "f", then type a frequency, then tab through the others and change them too, all without ever seeing the patch, if space is an issue or there are more interesting things to look at  ;)

Here's the soluce for my problem.
It is in fact fair simple.

I don't understand why there is a "select" message for numbox BUT NO "unselect" or "deselect" message !! 

I don't understand why there is a "select" message for numbox BUT NO "unselect" or "deselect" message !! 
Sorry, but it is a lacuna.


The asymmetrical focus situation with numbox probably seems strange, but it's one of those things that happens when systems evolve over two decades. It's a legacy thing.

Originally the only way to select/deselect a numbox was with the mouse. E basta. With Max 4, which introduced Inspectors (written as patches) to replace standard Mac Dialog Boxes (which was how options in UI objects were set prior to Max 4), numboxes started being used as something like dialog entry fields, and some programmatical way of changing focus was needed. In that context, the select message did an adequate job.

I actually agree with you, but I think at the time select was added to numbox, a more general solution just wasn't going to happen. Although I'd sort of hoped for something in one of the 4.x releases, maybe with 5.0 we'll get a blur message.

The asymmetrical focus situation with numbox probably seems strange, but it's one of those things that happens when systems evolve over two decades. It's a legacy thing. 

It's an old request. Was a request feature for Max 5. I think it didn't make it to Max 7 either.

It's an old request. Was a request feature for Max 5. I think it didn't make it to Max 7 either.
Any good workaround? Thanks for any tip.
For the record, the original patch:


If making an "unselect" message for [number] is not an option, why not add an inlet to the [key] object, and a "select" message?

My favorite version would be an "auto-unselect" attribute, un-selecting when click-drag is released, and when the enter key is hit after a numeric entry.

Way back in max4 I came up with the incredibly ugly solution below. It would work also when stuff was hidden in a sub patcher. That is not the case now. Maybe a bpatcher?

@jvkr: yes, but scripting has its disadvantages - I was hoping to avoid it.

@Nikolas K: yes, it looks like it's the best solution to date!

Thanks for the tips!
@jvkr: yes, but scripting has its disadvantages - I was hoping to avoid it.
@Nikolas K: yes, it looks like it's the best solution to date!


Nikolas: plus, your solution works in both use cases: a) dragging with the mouse b) clicking, entering a number, and hitting Enter.

As a variation on Nikolas' great discovery, however maybe not good in all situations:

you can build your own numberbox in lcd - but it is a huge deal to get the mousing right.

or connect an incdec to the numberbox and use (as a user) only this to control the numberbox, and the numberbox only as display.

@jkvr: interesting, indeed. Will be a little more cpu hungry, though.

@Roman: yes, but I wanted to avoid lcd or jsui if possible - with incdec, the problem is when you don't want incdec in your ui...

@jkvr: interesting, indeed. Will be a little more cpu hungry, though.
@Roman: yes, but I wanted to avoid lcd or jsui if possible - with incdec, the problem is when you don't want incdec in your ui...
Thanks!


num VS key