Hello there,

I am using [entry] as a text-input object, and I noticed that if the patch is Locked, I am writing within [entry] , and i hit CTRL+A, the patch unlocks!! and every object is selected (including entry, that, for some reason goes back to default color when that happens)

That seems to be a bit invasive, a shortcut not designed to unlock a patch shouldn't unlock a patch.

Does anybody know how to prevent this?

I am on PD-Extended under OSX.

Thank you!

That also happens in my Linux Pd-extended 43.4-1~raring .

In short, it looks like the [entry] textarea widget seems not to recognize "select all" text by Ctrl-a keypress.

More specifically, it looks like the [entry] textarea widget is not intercepting and keeping the Ctrl-a key event the intuitive way you expect, but rather the [entry] enclosing canvas window is getting Ctrl-a, which causes "select all" in the canvas window. That would require adding the Ctrl-a "select all" behavior to the [entry] object's code. That sounds like a feature request (or independent FOSS project) for a future Pd release.

I've never liked this, either. Hit ctrl+1 will also bring the patch back to Edit Mode. I personally think that if Edit Mode is turned off, then you should be able to edit the patch in any way unless it's explicitly turned on. But I get the feeling some people think that is a feature, not a bug.

Perhaps it could be a feature request to disable Edit Mode as part of Perf Mode.

@Maelstorm said:

I've never liked this, either. Hit ctrl+1 will also bring the patch back to Edit Mode.

This just looks like a bug in the textarea implementation, that fails to destroy the Ctrl-a event after receiving it (regardless of whether the textarea does anything with it). Or at least a bug in the enclosing window that fails to identify the target of the keypress event as the textarea, and then do nothing. Probably both bugs, while the textarea should destroy the event instead of bubbling it up the GUI container hierarchy and the containing window should ignore the event (or just continue bubbling it) because the event was targeting the textarea.

Generally in GUI design, and specifically in Tcl/Tk design, if the textarea widget doesn't consume Ctrl-a key events for some functionality, the widget will just destroy that event rather than bubble it up, if the cursor focus is in the textarea. It is highly unconventional for the textarea to ignore the event and bubble it up to its container.

Semantically, you are telling the textarea where you have an active cursor to "select all" or whatever Ctrl-a means. If it doesn't do that, it should do nothing. You are not indicating its enclosing scope as the message target when you press Ctrl-a, so you are not telling the enclosing scope anything. Only when the enclosing scope is where the action is performed that is requested of the enclosed scope would the enclosed scope bubble the event to the enclosing scope. Such as when both enclosed and enclosing scope must act, to keep their states consistent with each other, or for the enclosing scope to pass the message (that the textarea received the Ctrl-a) to other enclosed scopes, so they can maintain their own states' consistency with the originally targeted textarea. That is why the key event contains the original target object, the textarea, even in any case where that event is passed around the event hierarchy.

I agree with Matthew, but even if the ctrl+a is passed to the patcher, I agree with Maelstrom in that it should not unlock the patcher.

Who should we approach to request one and/or the other as to be fixed/added? (I never submitted a bug or feature request in PD)

thank you for your responses.

I found bugs.puredata.info and will open a ticket for entry not consuming CTRL+A.

thanks

ticket: http://sourceforge.net/p/pure-data/bugs/1102/

Maelstrom, Matthew, I am encountering this problem again and I was wondering

Could there be any way to filter out CMD+A completely while using PureData?

as in when the patch is open CMD+A / CTRL+A would not do anything. Or, alternatively, that CMD / CTRL alone would not do anything inside puredata.

Thank you

I would guess that you could write a few lines of Tcl to consume the keypress (by its code) in a Tcl plugin like the Triple-Click interceptor example. Unless that callback can't destroy the last copy of the keypress event, so elsewhere continues to process it. But it should probably be a fast Tcl coding session to see that it can't destroy the event.