Comments resizing themselves. Bad comments

Peter Castine's icon

Dear Max Developers,

What is the story with comment boxes resizing themselves?

Recently I have increasingly found that I when I open patchers, the
comment boxes have different sizes from when I saved them. In some
cases multi-line comments are resized to a single line wider than the
current window width. I even have a screen shot where the comment was
resized to wider than the screen.

This is becoming increasingly frustrating when trying to lay out
comment texts neatly.

I have not been able to pin down when or why the resizing takes
place. It seems to be completely arbitrary. I'm also not sure how to
build a patch that "reliably" exhibits this anomaly, because I don't
know when it's going to crop up until I reopen a patch and find the
comment box resized. If I save it then in text format, it's just a
comment box with a ridiculous width. How do you bug-report that?

Max/MSP 4.5.5, Mac OS X.

Thanks,
Peter

-------------- http://www.bek.no/~pcastine/Litter/ -------------
Peter Castine | +--> Litter Power & Litter Bundle for Jitter
|....................................................
p@castine.de | iCE: Sequencing, Recording, and Interface Building
pcastine@gmx.net | for Max/MSP
pcastine@bek.no | http://www.dspaudio.com/ Extremely cool
4-15@kagi.com |....................................................
| home|chez nous|wir|i nostri http://www.castine.de/

Leafcutter John's icon

Peter,

Have you tried Two-byte Compatible mode in the comment inspector window?

best,

john.

Peter Castine's icon

On 14-Mar-2006, at 0:58, Leafcutter John wrote:
> Have you tried Two-byte Compatible mode in the comment inspector
> window?

I have a mixture of 2-byte comp. and plain-vanilla comment boxes. The
problem definitely occurs w/plain-vanilla comment boxes, but I'm not
sure that 2-byte format is immune.

I tend not to use 2-byte format unless I feel compelling need
(usually embedded whitespace). You do have to remember to go in to
the Inspector and flip the toggle, plus storage requirements double
(binary) or triple (text format). The latter is, in today's world, a
cosmetic problem. But I have in the area of 1,000 comments boxes in
the Litter Power Help folder (for instance) and the prospect of
having to open the Inspector for each and every one of them gives me,
as Frankie Mouse said, the screaming heebie-jeebies.

I saw somewhere that there was a change in how Max handles comment
box sizes ca. v4.5.5, presumably an attempt to address some of the
problems with font differences between Mac and XP. It would be
helpful if Someone Who Knows (JKC? DDZ? Xoaz? JB?) could explain how
to avoid unwanted resizing.

-- P.

-------------- http://www.bek.no/~pcastine/Litter/ -------------
Peter Castine | +--> Litter Power & Litter Bundle for Jitter
|....................................................
p@castine.de | iCE: Sequencing, Recording, and Interface Building
pcastine@gmx.net | for Max/MSP
pcastine@bek.no | http://www.dspaudio.com/ Extremely cool
4-15@kagi.com |....................................................
| home|chez nous|wir|i nostri http://www.castine.de/

Stefan Tiedje's icon

Peter Castine wrote:
> This is becoming increasingly frustrating when trying to lay out
> comment texts neatly.

I absolutely agree, I posted this issue some time ago, it was introduced
not too long ago and its very frustrating. Its almost impossible to
create a constant look and feel, especially when information changes.
Even scripting a message box sometimes ignores and sometimes does the
size I define. The same patch behaves differently on different
occasions, it seems it depends what has been or is loaded before.

I could imagine that there are good reasons, to adapt the size to a
given number of lines, but then please add a attribute to
message/comment to be able to choose between "restrict to size" or
"restrict to x number of lines"
Would that be possible? Implementing such a thing might even make
searching for the circumstances of that annoying inconsistent behaviour
obsolete...

I know its almost impossible to find inconsistent bugs, thats why I did
hold back a bug report.

Recently I had a patch which scripted a message box. Just changing a
comment in the same patch would change the behaviour of how the message
box was drawn. Unfortunately I couldn't strip down the patch and still
maintain this strange behaviour.

Stefan

--

[][] [][][] [][] [][][]
[][][][][][][][][][][][][][][]

Stefan Tiedje
Klanggestalter
Electronic Composition
&
Improvisation

/~~~~~
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
___/ ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09

Andrew Pask's icon

Comments retain the linecount. This was introduced in 4.5.something.

Check it out. If you change the linecount line you can see it do its thing.

Max Patch
Copy patch and select New From Clipboard in Max.

If you formatted a comment box with a version of Max which supports this and then opened it on another version which does not, then maybe it could get mucked up. That would be my guess.

-A

Peter Castine's icon

This is getting closer to the heart of the problem.

The problem is cropping up while editing existing files, either
modifying the content of existing comment boxes or creating new one.
The strange thing is that I don't even have to save the patch for
resize-behind-my-back to take place. Usually it happens when I close
a subpatch window, then re-open it. Hey presto! the comment box has a
different size.

I'm finding it very difficult to track this down to a repeatable
sequence of steps, so please bear with me. Usually I'm editing, I
write some text in a comment, close the subpatcher window, open the
subpatch five minutes later, see the change, mutter imprecations, and
fix the size. I think the size then stays fixed, but I'm pretty sure
I've had some stubborn comment boxes that put me through this
rigamarole several times.

I'll try to get this repeatable, if you have any other ideas of
things I can look at, please let me know.

One question about the window linecount message:

Max Patch
Copy patch and select New From Clipboard in Max.

On 14-Mar-2006, at 22:20, Andrew Pask wrote:
> Comments retain the linecount. This was introduced in 4.5.something.
>
> Check it out. If you change the linecount line you can see it do
> its thing.
>
>

The 'window linecount 2' message above is sent to the symbol #P,
which is bound to the current patcher. Does it affect only the
comment box created in the line immediately following, or does this
setting remain in effect for all following comments?

Looking at this from the outside, it would have seemed somehow
cleaner to have linecount information handled by the comment box
object it applies to rather than the parent patcher, but I will take
it as read that there are architectural reasons for why y'all took
the approach you did.

> If you formatted a comment box with a version of Max which supports
> this and then opened it on another version which does not, then
> maybe it could get mucked up. That would be my guess.

Like I said, this is all happening just in closing/reopening patcher
windows, no change in Max version. Yes, save/close/open (possibly
with quit/launch in between) also has this problem, but I'm still not
changing Max versions. I'm not looking forward to additional
difficulties when opening my patches on 4.1.-(

Thanks for the information.

-- Peter

-------------- http://www.bek.no/~pcastine/Litter/ -------------
Peter Castine | +--> Litter Power & Litter Bundle for Jitter
|....................................................
p@castine.de | iCE: Sequencing, Recording, and Interface Building
pcastine@gmx.net | for Max/MSP
pcastine@bek.no | http://www.dspaudio.com/ Extremely cool
4-15@kagi.com |....................................................
| home|chez nous|wir|i nostri http://www.castine.de/

Stefan Tiedje's icon

Andrew Pask wrote:
> Comments retain the linecount. This was introduced in 4.5.something.

could be included into the inspector, which means a message box and a
comment should be able to listen to a scripting command "linecount" This
would be great, strong request!!!

But still there is an issue at least with message boxes: What is the
priority? The size or the line count? I would like to choose the
priority myself, thats why it should be an inspector choice. a checkbox
for linecount and the number of lines, or the size. When I resize the
messagebox I usually do that according to aestethical reasons. That
means I want the size to be the determining parameter. I need to be able
to switch of the linecount.

Old patches should always retain the size and never retain a linecount
of one !!!

As I mentioned before, the idea with defining a linecount instead of a
size is good, but not always wanted.

Suggestions how the message/comment inspectors could look like are attached.

Stefan

message inspector maquette:

Max Patch
Copy patch and select New From Clipboard in Max.

comment inspector maquette:

Max Patch
Copy patch and select New From Clipboard in Max.

--

[][] [][][] [][] [][][]
[][][][][][][][][][][][][][][]

Stefan Tiedje
Klanggestalter
Electronic Composition
&
Improvisation

/~~~~~
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
___/ ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09

Carl Albrecht's icon

Hi!
I have kind of similar problems - but even better:
I have a solution :)

I have a subpatcher that has a comment object displaying different error messages. So the subpatcher pops open and for no reasons I could reproduce the comment-object sometimes resizes...

So either I could make my messages so short they fit in 1 line and stay within the width of the window OR I would have to resize the comment object everytime I display a message, to make sure the message is displayed as desired.

One can do that simply by sending (in my case) "presentation_rect ".

This also helps when you switch platforms often, because I felt that mac was more immune to that irrational behavior than windows...

So if one has MORE THAN 1 LINES to display in comment - or is planning on changing the content of it dynamically - one could make dead sure the width of the commentbox stays as desired :)

Max is great!
(NO IRONY HERE!)