Brad Garton

Here's a double-click function that opens up an Ed 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);

(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 

(PS: What I'm really after is access to the text in the Ed window via the 

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);
}

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.

(PS:  What I'm really after is access to the text in the Ed window via the 
e_teh TEHandle, if this is possible.)


accessing-fields-in-the-ed-struct

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 

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).

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.

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.

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.

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.

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.

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.

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:

    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 

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...

void myobject_closeit(t_myobject *x)
{
 	wind_close(x->c_edit->e_wind));
}

 	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?

'fraid I can't help directly, Brad, but two things arise out of 

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 

I've been meaning to bring this up for a while. Maybe somebody 

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 

So, when Brad rhetorically writes "you know," does anyone know?

Peter Castine +--> Litter Power & Litter Bundle for Jitter

iCE: Sequencing, Recording & |home | chez nous|

Interface Building for |bei uns | i nostri|

'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:

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.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter

On 29 Jun 2006, at 13:23, Peter Castine wrote:

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).

nick rothwell -- composition, systems, performance -- 

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).

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


>     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 

goto punt; // Poor man's exception handling

// Can access left outlet through me->coreObject.o_outlet

t_wind* myWind = (t_wind*) me->owner->p_wind;

outlet_anything(me->coreObject.o_outlet, gensym("dispose"), 0, NIL);

myWind->w_dirty = false;    // Usually superfluous

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 

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"?

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.

typedef struct {
   Object    coreObject;
   Patcher*  owner;
   } objFilch;

void* ArgusNew(void)
   {
   objFilch* me = newobject(gObjectClass);

   if (me == NIL)
     goto punt;       // Poor man's exception handling

   // Can access left outlet through me->coreObject.o_outlet
   outlet_new (me, NIL);

#define _DELETE_STRATEGY_ 1  // or 2 or 3

   {
   t_wind*  myWind = (t_wind*) me->owner->p_wind;

   wind_invis(myWind);
   outlet_anything(me->coreObject.o_outlet, gensym("dispose"), 0, NIL);

   myWind->w_dirty = false;	// Usually superfluous
   wind_close(myWind);

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).

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 

On Thu, 29 Jun 2006, Nick Rothwell wrote:

> On 29 Jun 2006, at 13:23, Peter Castine wrote:

> 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 

> nick rothwell -- composition, systems, performance -- 

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.

>
> 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
>
>
>


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 

So it looks like someone *did* know about the problem and fixed it.

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 

> On Thu, 29 Jun 2006, Nick Rothwell wrote:

>> On 29 Jun 2006, at 13:23, Peter Castine wrote:

>> 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).

>> nick rothwell -- composition, systems, performance -- 

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.

> 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
>>
>>
>>
>

On 30 Jun 2006, at 17:48, Peter Castine wrote:

> So it looks like someone *did* know about the problem and fixed it.

accessing fields in the "ed" struct