post("tsomething"); on windows


    Aug 01 2006 | 2:41 pm
    Hi,
    I'm using the post method with a string containing a tabulation (t), to print something aligned in the Max window. It works fine under mac (MaxMSP 4.6b) but prints bad characters on windows (MaxMSP 4.5.7).
    Best, ej

    • Aug 01 2006 | 4:10 pm
      This also happens from the post() function in the C API.
      The workaround I have adopted is not to use tab characters in my externals.-(
      Even on Mac OS, the tab char doesn't generate a jump to a tab stop, it just generates some empty pixels, about as many as a non-breaking space.
      Wish: it would be nice to have support for tab stops in the Max window.
      -- Peter
      On 1-Aug-2006, at 16:41, Emmanuel Jourdan wrote:
      > I'm using the post method with a string containing a tabulation > (t), to print something aligned in the Max window. It works fine > under mac (MaxMSP 4.6b) but prints bad characters on windows > (MaxMSP 4.5.7).
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Aug 01 2006 | 4:18 pm
    • Aug 01 2006 | 5:12 pm
      On 06-08-01, at 1310, Peter Castine wrote:
      > > Wish: it would be nice to have support for tab stops in the Max > window. > > while we're on the topic of max window wishes, it would be nice to have a separate font setting for the max window, so we can use a monospaced font (and tabs) there, and geneva or whatever the default font is in patcher windows.
      best, r.
    • Aug 01 2006 | 9:11 pm
      On 1-Aug-2006, at 18:18, Emmanuel Jourdan wrote: >> Even on Mac OS, the tab char doesn't generate a jump to a tab >> stop, it just generates some empty pixels, about as many as a non- >> breaking space. > > Surprisingly, the number of space which are generated make the > alignment correct.
      For a second I thought this was the case in your screen shots, but I took a closer look and noticed that the zeros on the nbpoints lines are one pixel off.
      I thought maybe it was my astigmatism acting up, but zooming into a screen shot confirmed my suspicion.
      -- P.
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine | +--> Litter Power & Litter Bundle for Jitter | Universal Binaries under way! |.................................................. Composer | iCE: Essential Tools for Sequencing, Recording Sonic Artist | & Interface Building in Max/MSP Software Developer | Nortron: The Idea Palette | http://www.dspaudio.com/ |.................................................. p@castine.de | http://www.castine.de/ home|chez nous|wir
    • Aug 01 2006 | 9:52 pm
      On 06-08-01, at 1811, Peter Castine wrote: > On 1-Aug-2006, at 18:18, Emmanuel Jourdan wrote: >>> Even on Mac OS, the tab char doesn't generate a jump to a tab >>> stop, it just generates some empty pixels, about as many as a non- >>> breaking space. >> >> Surprisingly, the number of space which are generated make the >> alignment correct. > > For a second I thought this was the case in your screen shots, but > I took a closer look and noticed that the zeros on the nbpoints > lines are one pixel off. > > I thought maybe it was my astigmatism acting up, but zooming into a > screen shot confirmed my suspicion. > these are just lucking out, as it appears as though the tabs are being used as spaces (as shown by the number of boxes in the windows screenshot). switch your max window to a monospaced font, and they should line up properly.
      r.