Comments resizing themselves. Bad comments


    Mar 13 2006 | 11:17 pm
    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/

    • Mar 14 2006 | 12:58 am
      Peter,
      Have you tried Two-byte Compatible mode in the comment inspector window?
      best,
      john.
    • Mar 14 2006 | 9:52 am
      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/
    • Mar 14 2006 | 8:50 pm
      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
    • Mar 14 2006 | 9:20 pm
      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.
      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
    • Mar 15 2006 | 10:29 am
      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:
      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/
    • Mar 15 2006 | 8:55 pm
      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:
      comment inspector maquette:
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      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
    • Oct 20 2016 | 2:24 pm
      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!)