Iain Duncan

I'm not clear if this is a bug, or deliberate behaviour, but the help file does not seem to indicate it should be. When one enters text in the textedit box and then clicks any other object (moving focus) the contents of the box are sent out outlet 0. This is happening regardless of the settings of tabmode, bangmode, clickmode, keymode, or output. I don't see anything in the doc page describing the behaviour, and it seems to me to kind of negate the setting of keymode (ie allowing enters in the box without sending them out). Does anyone have any experience or solutions on this? Or can confirm if it's a bug?

I'm not clear if this is a bug, or deliberate behaviour, but the help file does not seem to indicate it should be. When one enters text in t

issue-bug-i-think-with-textedit-object

I have managed a hacky workaround involving sequentially opening a gate, banging the contents, and closing the gate for every send, but it's pretty ugly. So mostly this is a potential bug report I guess. thanks!

textedit is very unintiuitive and almost everything i do with it ends up with a patch which i consider a "workaround".

but i still feel the need to point out that numberboxes or dropfile also send out the entered data when you click outside, and that this behavior is in the majority of the use cases exactly what you want from a GUI (input) object. why it cant be turned off is another question...


textedit is very unintiuitive and almost everything i do with it ends up with a patch which i consider a "workaround".

but i still feel the need to point out that numberboxes or dropfile also send out the entered data when you click outside, and that this behavior is in the majority of the use cases exactly what you want from a GUI (input) object. why it cant be turned off is another question...


Yeah I know what you mean, but it sure is annoying for textedit's purpose. Perhaps it's an unavoidable architectural issue. I think ultimately I'll write an external wrapping it to get to behave right, but for now the hack is working ok. ( An external at least can update it with multiline text and no quotation marks.)

Yeah I know what you mean, but it sure is annoying for textedit's purpose.  Perhaps it's an unavoidable architectural issue. I think ultimately I'll write an external wrapping it to get to behave right, but for now the hack is working ok. ( An external at least can update it with multiline text and no quotation marks.)

Issue (bug, I think... ) with textedit object