Chris Vik

This constantly catches me out. I accidentally delete some part of my [codebox] code and hit CTRL-Z to undo, only for it to start undoing events in the actual patcher. Is there actually no undo function inside of [codebox] at all?

Additionally - I find the [codebox] interface object behaviour counter-intuitive to the Max paradigm. Currently it lets you select text while the patcher is locked. You can't edit it, which makes sense, but this behaviour also catches me out, where I position the text cursor and start typing, then realise the patcher is locked. Also, you have to click on the very top or bottom dark grey line to move it.

For me, a more intuitive behaviour would be:

- Prevent text from being highlighted or the cursor from being placed while the patcher is locked

- Once the patcher is unlocked, the [codebox] object can be moved by click-dragging 

- Enable [codebox] editing by double-clicking on the white space, which additionally enables text selection and cursor placement

- While editing, undo works only for the [codebox] object

- Click once anywhere out of the [codebox] to disable editing; disabling undo for the [codebox], and re-enabling undo for the patcher

I feel that these changes would mirror how the rest of Max works and make using [codebox] a much better experience.

For me, a more intuitive behaviour would be:
 - Prevent text from being highlighted or the cursor from being placed while the patcher is locked
 - Once the patcher is unlocked, the [codebox] object can be moved by click-dragging anywhere on the interface object
 - Enable [codebox] editing by double-clicking on the white space, which additionally enables text selection and cursor placement
 - While editing, undo works only for the [codebox] object
 - Click once anywhere out of the [codebox] to disable editing; disabling undo for the [codebox], and re-enabling undo for the patcher

I feel that these changes would mirror how the rest of Max works and make using [codebox] a much better experience.


undo-and-interface-behaviour-suggestions-for-codebox

I don't think [codebox] is really meant to be used extensively as an editor. Something like Sublime or Text Wrangler is better.

That said, 'undo' is linked to the currently selected input field. If you are editing the argument of any object, including [codebox], selecting 'undo' will undo the text within the object field. If you click on the patcher background and select 'undo', it will undo the last patcher event. This is true for most objects in Max.

I can understand preventing text highlighting in [codebox] while the patcher is locked - just for the sake of clarity. That has confused me at times. However, unlocking the patcher by double-clicking the codebox background would deviate from the Max 'paradigm'. Double clicking all other locked objects either does nothing or opens something.

• double-clicking a locked [codebox] background opens the Code console in a separate small window, much like double-clicking [print] opens the Max Console.

• a more visible indicator within edit mode that [codebox] ready for editing... maybe a border highlight or glow.

• inline error messages that are readable with a mouseover on the error. Often times, the error message is aligned so far to the right so I have to expand the window to near full size just to read it.

• recovery that includes unsaved [codebox] content. Currently, a Max crash means losing any coding the was done after the last save.

Also.. beware of a current bug.. command-clicking the border of [codebox] crashes Max (on Mac). Not sure if control-click does the same in Windows. The lack of crash recovery inside [codebox] makes this particularly nasty.

I don't think [codebox] is really meant to be used extensively as an editor.   Something like Sublime or Text Wrangler is better.   

That said, 'undo' is linked to the currently selected input field. If you are editing the argument of any object, including [codebox],  selecting 'undo' will undo the text within the object field.  If you click on the patcher background and select 'undo', it will undo the last patcher event.   This is true for most objects in Max.

I can understand preventing text highlighting in [codebox] while the patcher is locked - just for the sake of clarity.  That has confused me at times.  However,  unlocking the patcher by double-clicking the codebox background would deviate from the Max 'paradigm'.    Double clicking all other locked objects either does nothing or opens something.    

• double-clicking a locked [codebox] background opens the Code console in a separate small window, much like double-clicking [print] opens the Max Console.
• a more visible indicator within edit mode that [codebox] ready for editing...  maybe a border highlight or glow.
• inline error messages that are readable with a mouseover on the error.   Often times, the error message is aligned so far to the right so I have to expand the window to near full size just to read it.
• recovery that includes unsaved [codebox] content.  Currently, a Max crash means losing any coding the was done after the last save.

Also.. beware of a current bug..   command-clicking the border of [codebox] crashes Max (on Mac).  Not sure if control-click does the same in Windows.   The lack of crash recovery inside [codebox] makes this particularly nasty.


Ah! You're totally right about the undo state - I never even realised, but I subconsciously deselect objects before I undo - that's an interesting one.

Actually - when I say "double-clicking", I meant only while the patch is unlocked.

On all the other Max objects, with the patch unlocked, if you click on the object once, you've selected it, and it's meant to be moved around the patch. Click on the object again, and bringo! - you're editing the object. That's why I find [codebox] so weird - it doesn't seem to fit in to the work-flow as nicely as I think it could.

I really like you're suggestion of being able to open up an editing window. I suppose this would be like any sub patcher, [js], etc. object.

As far as an edit indicator - the [codebox] already seems to have a soft green glow for me when it's in an active edit state - though it would be far more obvious if it was the whole title bar of the [codebox] that glowed instead - it's quite hard to see with default colours.

The ctrl-click issue you mention doesn't seem to effect Max 7.1.0 for Windows 10.

Actually - I can see why I got confused about the undo function now. This is definitely a bug. I'll have to do more tests, but so far I can confirm that I can't undo [codebox] edits while in edit mode in my [jit.gl.pix] WHILE the [codebox] is selected.

It seems to work as you described, Metamax, in [jit.gen], but certainly is not the case for me in [jit.gl.pix].

Another confusing behaviour by [gen~] is that you can edit a patch while it's in "read-only" mode.

I've lost so many edits by accidentally making changes and CTRL-Sing to save, only to have the [gen~] as it was previously when I re-open it.

Why can you edit the patch in read-only mode?

Another confusing behaviour by [gen~] is that you can edit a patch while it's in "read-only" mode.
I've lost so many edits by accidentally making changes and CTRL-Sing to save, only to have the [gen~] as it was previously when I re-open it.

Why can you edit the patch in read-only mode?


Undo and interface behaviour suggestions for [codebox]