accessing fields in the "ed" struct

Jun 19, 2006 at 1:07pm

accessing fields in the "ed" struct

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

http://music.columbia.edu/~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.)

#26483
Jun 19, 2006 at 1:54pm

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

#79240
Jun 19, 2006 at 3:52pm

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

#79241
Jun 19, 2006 at 4:20pm

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

#79242
Jun 19, 2006 at 6:01pm

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

http://music.columbia.edu/~brad

#79243
Jun 28, 2006 at 4:40pm

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

http://music.columbia.edu/~brad

#79244
Jun 29, 2006 at 12:23pm

‘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

http://www.dspaudio.com/

#79245
Jun 29, 2006 at 1:10pm

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://
http://www.cassiel.com

#79246
Jun 29, 2006 at 1:26pm

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(“#P”)->s_thing;

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

http://www.dspaudio.com/

#79247
Jun 30, 2006 at 2:52pm

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

#79248
Jun 30, 2006 at 3:48pm

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

http://www.dspaudio.com/

#79249
Jul 6, 2006 at 9:54am

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://
http://www.cassiel.com

#79250

You must be logged in to reply to this topic.