accessing fields in the "ed" struct


    Jun 19 2006 | 1:07 pm
    Oh I hope someone can shed some light...
    Here's a double-click function that opens up an Ed window:
    void myobj_dblclick(t_myobj *x)
    {
    struct ed *edit_window;
    edit_window = ed_new((Object *)x);
    ed_settext(edit_window, &x->script[x->current_script],
    x->script_len[x->current_script]);
    post("number of lines: %d", edit_window->e_nlines);
    }
    x->script[] is declared:
    char *script[MAX_SCRIPTS];
    (and the script_len is also set appropriately).
    The text of the script -- about 340 chars -- shows up in the editor window
    fine and dandy, but the e_nlines var is set to 16914848. This looks like
    a pointer, but I tried various disambiguations and got either crashes or
    nonsense.
    Any clues?
    brad
    (PS: What I'm really after is access to the text in the Ed window via the
    e_teh TEHandle, if this is possible.)

    • Jun 19 2006 | 1:54 pm
      A quick search through the kernel code indicates the e_nlines isn't
      actually used by anything. Which would explain why it's bogus. If you
      want to count lines, I think you have to do it manually (the text
      object does it manually, for instance).
      jb
    • Jun 19 2006 | 3:52 pm
      Jeremy --
      Would it be possible to do a quick search also for the e_teh struct member
      also? What I'm trying to do is find a way to read the text of an open
      ed window without closing it. I wasn't having success with e_teh, so I
      tried looking at e_nlines to see if I was doing something wrong.
      brad
    • Jun 19 2006 | 4:20 pm
      Brad,
      I would consider the t_ed object more or less opaque for the time
      being. e_teh isn't being used in recent versions of Max, either. I
      don't believe there is any way to do what you want to do with ed.
      jb
    • Jun 19 2006 | 6:01 pm
      Thanks Jeremy -- saved me from some additional head-bashing.
      This particular nonsense was more a convenience than anything essential.
      I thought it might be fun to keep an ed window open while making mods to
      scripts (a [chuck~] object would be nifty!), but I'd have to be able to
      grab the buffer pointer/handle to do that.
      brad
    • Jun 28 2006 | 4:40 pm
      So I'm still trying to find a way to get at the text of an open Ed
      window. I thought "hey, I'll close it (which will generate an edclose
      call) and then re-open!" hack... hack... hack...
      Here's my message to close an open window:
      void myobject_closeit(t_myobject *x)
      {
      wind_close(x->c_edit->e_wind));
      }
      with the appropriate
      addmess((method)myobject_closeit, "closeit", 0);
      and declarations, etc. c_edit is in fact an ed* pointer, initialized and
      working properly. When I send the [closeit] message, it does indeed close
      the window, and it does generate a good edclose call, but I get the
      marching-depressed-message-box-of-death syndrome (you know, where it
      appears that the [closeit] message never gets undepressed, and each time
      you click it again the text moves down and to the right slightly). I
      forgot what causes this behavior, but the patch actually seems to work ok.
      Is there any way to close or get at the text inside an ed* window
      programmatically?
      brad
    • Jun 29 2006 | 12:23 pm
      'fraid I can't help directly, Brad, but two things arise out of
      yours, one of which is the following
      On 28-Jun-2006, at 18:40, Bradford Garton wrote:
      > but I get the marching-depressed-message-box-of-death syndrome
      > (you know, where it appears that the [closeit] message never gets
      > undepressed, and each time you click it again the text moves down
      > and to the right slightly).
      I've been meaning to bring this up for a while. Maybe somebody
      (possibly me) already has:
      Is this a known problem?
      Or should someone upload a screenshot & bug report?
      It's a cosmetic issue, but if you let things run long enough you can
      have message boxes that appear empty despite having content, which is
      disconcerting.
      So, when Brad rhetorically writes "you know," does anyone know?
      -- P.
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • Jun 29 2006 | 1:10 pm
      On 29 Jun 2006, at 13:23, Peter Castine wrote:
      > Is this a known problem?
      I've got applications that do it - I first noticed it a year or two
      ago. I'm wondering whether it's related to the click on the message
      box causing a patcher window to open (and hence to remove mouse/
      keyboard focus from the one containing the message box).
      -- N.
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com
    • Jun 29 2006 | 1:26 pm
      My other question:
      On 28-Jun-2006, at 18:40, Bradford Garton wrote:
      > addmess((method)myobject_closeit, "closeit", 0);
      I have been trying to write an object that, when banged, will close
      its owning patcher window. The object could, ideally, be triggered by
      a loadbang message.
      I've got:
      typedef struct {
      Object coreObject;
      Patcher* owner;
      } objFilch;
      ----
      main() does the standard Max stuff.
      ----
      void* ArgusNew(void)
      {
      objFilch* me = newobject(gObjectClass);
      if (me == NIL)
      goto punt; // Poor man's exception handling
      me->owner = (Patcher*) gensym("
      // Can access left outlet through me->coreObject.o_outlet
      outlet_new (me, NIL);
      // schnipp...
      punt:
      return me;
      }
      ----
      #define _DELETE_STRATEGY_ 1 // or 2 or 3
      void ArgusBang(
      objFilch* me)
      {
      t_wind* myWind = (t_wind*) me->owner->p_wind;
      // schnipp...
      #if (_DELETE_STRATEGY_ == 1)
      freeobject((Object*) me->owner);
      #elif (_DELETE_STRATEGY_ == 2)
      wind_invis(myWind);
      outlet_anything(me->coreObject.o_outlet, gensym("dispose"), 0, NIL);
      #elif (_DELETE_STRATEGY_ == 3)
      myWind->w_dirty = false; // Usually superfluous
      wind_close(myWind);
      #endif
      }
      ---
      Strategy 2 requires connecting the outlet to a thispatcher object,
      which I can live with. However, the window is drawn once before the
      wind_invis() kicks in, flashing onscreen before disposal. This is way
      ugly.
      Strategies 1 & 3 close effectively on a loadbang message but are bad
      mojo; I get lots of "zgetfn.... corrupt object" error messages some
      time later. When triggered by a bang message, Max dies (crash in
      Thread 0 with a thoroughly corrupt stack).
      Is there a better way than "don't try to close your own window"?
      Thanks,
      Peter
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • Jun 30 2006 | 2:52 pm
      I'm trying to remember the circumstances that caused this before (and how
      to solve it)... I think I hadn't released some resources properly, or
      something.
      brad
      On Thu, 29 Jun 2006, Nick Rothwell wrote:
      >
      > On 29 Jun 2006, at 13:23, Peter Castine wrote:
      >
      >> Is this a known problem?
      >
      > I've got applications that do it - I first noticed it a year or two ago. I'm
      > wondering whether it's related to the click on the message box causing a
      > patcher window to open (and hence to remove mouse/keyboard focus from the one
      > containing the message box).
      >
      > -- N.
      >
      >
      > nick rothwell -- composition, systems, performance -- http://www.cassiel.com
      >
      >
      >
    • Jun 30 2006 | 3:48 pm
      I was about to post a bug report to the main list on the problem that
      I've faced, but when I tried the patch encapsulating my problem on
      4.6 beta, it went away.
      So it looks like someone *did* know about the problem and fixed it.
      -- P.
      On 30-Jun-2006, at 16:52, Bradford Garton wrote:
      > I'm trying to remember the circumstances that caused this before
      > (and how to solve it)... I think I hadn't released some resources
      > properly, or something.
      >
      > brad
      > http://music.columbia.edu/~brad
      >
      >
      > On Thu, 29 Jun 2006, Nick Rothwell wrote:
      >
      >>
      >> On 29 Jun 2006, at 13:23, Peter Castine wrote:
      >>
      >>> Is this a known problem?
      >>
      >> I've got applications that do it - I first noticed it a year or
      >> two ago. I'm wondering whether it's related to the click on the
      >> message box causing a patcher window to open (and hence to remove
      >> mouse/keyboard focus from the one containing the message box).
      >>
      >> -- N.
      >>
      >>
      >> nick rothwell -- composition, systems, performance -- http://
      >> www.cassiel.com
      >>
      >>
      >>
      >
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • Jul 06 2006 | 9:54 am
      On 30 Jun 2006, at 17:48, Peter Castine wrote:
      > So it looks like someone *did* know about the problem and fixed it.
      Indeed, yes: seems to be fixed in 4.6.
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com