Adam Murray

In Max 4, bang would dump out whatever was in the textedit at the time. Very useful for monitoring the contents of textedit as the user types:

In Max 5 it just outputs the value from the last time the text was "entered" (via tab or clicking elsewhere in the patch). I based some of my GUIs on this continuous monitoring behavior and I can't find a way to get them to work in Max 5.

Can this be changed to work like it used to?

Also, this is probably asking too much, but in Max 4 it used to be possible to enter the text with tab/enter key and keep focus inside the textedit. I often want to keep focus. Any chance of providing a way to do this again? Maybe a "keeps focus" option in the inspector?

textedit-bug-bang-doesnt-output-current-text

Quote: Adam Murray wrote on Mon, 28 April 2008 00:27

----------------------------------------------------

> I based some of my GUIs on this continuous monitoring behavior and I can't find a way to get them to work in Max 5.

PS - I know I can watch the 2nd outlet to see what keys are being pressed, but I just want the current value of the text without having to deal with special cases like the backspace key. That's textedit's job...

Quote: Adam Murray wrote on Mon, 28 April 2008 00:27
----------------------------------------------------
>  I based some of my GUIs on this continuous monitoring behavior and I can't find a way to get them to work in Max 5.

PS - I know I can watch the 2nd outlet to see what keys are being pressed, but I just want the current value of the text without having to deal with special cases like the backspace key. That's textedit's job...


Investigated this more tonight. The textedit help file says "bang sends typed or stored text", and the reference manual also claims this is the behavior. But it's not sending the typed text on bang, only the stored text.

It gets stranger. The reference manual says the "enter" message "Outputs the current text and takes the editing focus away from the object." But it doesn't take editing focus away. And in this patch the output lags one character behind:

I was able to fix the one character lag with a [delay], but my instinct tells me I should not rely on this behavior:

My goal is to get the current text immediately after a certain character are typed. I'd prefer to not lose focus but I can live with that.

Should I resort to [delay] hackery or can I expect some improvements to textedit in an upcoming incremental update?

BTW I'm seeing these behaviors on Max 5.0.1 on OS X 10.5.2

Thanks for the clear example patches. I'm not sure when this will be looked at, but i've written it up. I'd stick to workarounds for now.

Thanks for the clear example patches.  I'm not sure when this will be looked at, but i've written it up.  I'd stick to workarounds for now.

Quote: ben@cycling74.com wrote on Thu, 31 July 2008 10:08

> Thanks for the clear example patches. I'm not sure when this will be looked at, but i've written it up. I'd stick to workarounds for now.

Thanks Ben, that's fine. Please note that when I pointed out:

> reference manual says the "enter" message "Outputs the current text and takes the editing focus away from the object." But it doesn't take editing focus away.

I don't want it to take editing focus away. If I currently have focus on [textedit] and I'm typing text when an "enter" message arrives, it would be disruptive to lose focus. My suggestion is the manual should simply remove the text "and takes the editing focus away from the object" for consistency with the actual behavior.

The real issues are bang doesn't work as advertised, and the one character lag behavior with "enter". The [delay] workaround is good enough.

In bigger patches that are using more CPU, you may find [delay 1] does not work. If that happens then increase the delay. [delay 30] seems to work well in my bigger patches.

Quote: ben@cycling74.com wrote on Thu, 31 July 2008 10:08
----------------------------------------------------
> Thanks for the clear example patches.  I'm not sure when this will be looked at, but i've written it up.  I'd stick to workarounds for now.

> reference manual says the "enter" message "Outputs the current text and takes the editing focus away from the object." But it doesn't take editing focus away. 

Francois: 
In bigger patches that are using more CPU, you may find [delay 1] does not work. If that happens then increase the delay. [delay 30] seems to work well in my bigger patches.


First, the bug you pointed out with bang -> textedit will be fixed in our next release.

Second, the "enter" message was not supposed to be documented. Don't use it. It is mostly just the same as bang.

Third, I don't think polling textedit with a metro is a good idea since polling needlessly wastes CPU cycles. I'd stick to connecting the second outlet of textedit -> "trigger bang" -> deferlow -> first inlet of textedit. For this case I'd recommend deferlow instead of delay since there is no need to move the message to the scheduler thread.

The reason for the one character lag is that the textedit value is updated after the key notification is sent out the second outlet. This is by design and won't be changing -- using deferlow for this application will be the recommended practice.

First, the bug you pointed out with bang -> textedit will be fixed in our next release.  

Second, the "enter" message was not supposed to be documented.  Don't use it.  It is mostly just the same as bang. 

Third, I don't think polling textedit with a metro is a good idea since polling needlessly wastes CPU cycles.  I'd stick to connecting the second outlet of textedit -> "trigger bang" -> deferlow -> first inlet of textedit.  For this case I'd recommend deferlow instead of delay since there is no need to move the message to the scheduler thread.

The reason for the one character lag is that the textedit value is updated after the key notification is sent out the second outlet.  This is by design and won't be changing -- using deferlow for this application will be the recommended practice. 

Quote: Rob Sussman wrote on Thu, 31 July 2008 12:28

> First, the bug you pointed out with bang -> textedit will be fixed in our next release.

> Second, the "enter" message was not supposed to be documented. Don't use it. It is mostly just the same as bang.

> Third, I don't think polling textedit with a metro is a good idea since polling needlessly wastes CPU cycles. I'd stick to connecting the second outlet of textedit -> "trigger bang" -> deferlow -> first inlet of textedit. For this case I'd recommend deferlow instead of delay since there is no need to move the message to the scheduler thread.

Yeah, that was just a demonstration of the issue, I don't normally do the polling. When I first reported this issue back on version 5.0.0 or 5.0.1, I swear I tried deferlow and it didn't help. Maybe I am misremembering, but I believe delay -> enter was the only thing that seemed to work back then. This might be related to needing higher delay times for the workaround to consistently fix the issue in CPU-intensive patches. I haven't revisited these problems in 5.0.4 so I'm not sure if this is true anymore.

"second outlet of textedit -> "trigger bang" -> deferlow -> first inlet of textedit" sounds perfect for my needs. I'll try it out when the next version releases.

Quote: Rob Sussman wrote on Thu, 31 July 2008 12:28
----------------------------------------------------
> Hi Adam,
>
> First, the bug you pointed out with bang -> textedit will be fixed in our next release.  

> Second, the "enter" message was not supposed to be documented.  Don't use it.  It is mostly just the same as bang. 

> Third, I don't think polling textedit with a metro is a good idea since polling needlessly wastes CPU cycles.  I'd stick to connecting the second outlet of textedit -> "trigger bang" -> deferlow -> first inlet of textedit.  For this case I'd recommend deferlow instead of delay since there is no need to move the message to the scheduler thread.

> In bigger patches that are using more CPU, you may find [delay 1] does not work. If that happens then increase the delay. [delay 30] seems to work well in my bigger patches.

> I'd stick to connecting the second outlet of textedit -> "trigger bang" -> deferlow -> first inlet of textedit

Rob, 
> I'd stick to connecting the second outlet of textedit -> "trigger bang" -> deferlow -> first inlet of textedit

Thanks for pointing that out. You are correct. It is not reliable to use deferlow as I suggested. Using a delay seems more reliable but it is also not guaranteed to work.

For max 5.0.5 textedit will grow a fourth outlet to fix this. It will send "textchanged" when the text is changed (while the user types or otherwise). You will be able to use this to trigger the output during typing without a deferlow or delay.

Hopefully this will allow you to reliably do what you want...

Thanks for pointing that out.  You are correct.  It is not reliable to use deferlow as I suggested.  Using a delay seems more reliable but it is also not guaranteed to work.  

For max 5.0.5 textedit will grow a fourth outlet to fix this.  It will send "textchanged" when the text is changed (while the user types or otherwise).  You will be able to use this to trigger the output during typing without a deferlow or delay.  

> For max 5.0.5 textedit will grow a fourth outlet to fix this.

Nice... hope 5.0.5 is coming soon !
Thanks again...


Quote: Rob Sussman wrote on Fri, 01 August 2008 10:49

> For max 5.0.5 textedit will grow a fourth outlet to fix this. It will send "textchanged" when the text is changed (while the user types or otherwise). You will be able to use this to trigger the output during typing without a deferlow or delay. 

> Hopefully this will allow you to reliably do what you want...

One thing I want to do is dump the currently displayed textedit value when a certain key is pressed, like '.' The dumped text should include the '.' character just pressed.

I'm not sure how this fourth outlet is going to help, will I use a combination of the second and fourth outlet?

Quote: Rob Sussman wrote on Fri, 01 August 2008 10:49
----------------------------------------------------
> For max 5.0.5 textedit will grow a fourth outlet to fix this.  It will send "textchanged" when the text is changed (while the user types or otherwise).  You will be able to use this to trigger the output during typing without a deferlow or delay.  
>
> Hopefully this will allow you to reliably do what you want...

I'm not sure how this fourth outlet is going to help, will I use a combination of the second and fourth outlet?


you should just be able to route the ascii value that you want to use as your trigger to bang textedit. in the meantime, this is a workaround, using the colon, ':', as the triggering symbol:

you should just be able to route the ascii value that you want to use as your trigger to bang textedit.  in the meantime, this is a workaround, using the colon, ':', as the triggering symbol:

Here is a patcher that will only work in the Max 5.0.5 and later, but will give you an idea of what you can do.

Because the new value of the text is not available at the time the ascii value is sent from the second outlet you have to have some logic that will bang out the next change of the text after the ascii character that you are looking for. The patch below does this by opening a gate and then closing it after the next bang comes through.

Here is a patcher that will only work in the Max 5.0.5 and later, but will give you an idea of what you can do. 

Because the new value of the text is not available at the time the ascii value is sent from the second outlet you have to have some logic that will bang out the next change of the text after the ascii character that you are looking for.  The patch below does this by opening a gate and then closing it after the next bang comes through. 

Textedit Bug: bang doesn't output current text