tinglett+@rchland.ibm.com (Todd Inglett) (04/10/91)
I have been checking into just how difficult it would be to add amessages.FwdHeaders preference to messages that can select headers toexcerpt when a message is to be forwarded (much likemessages.KeyHeaders selects headers to view when reading). I havetracked through the code down to MS_NameReplyFile inams/libs/ms/reply.c. The content of the message appears to beblindly copied in MS_NameReplyFile. How can I get a preferencedown into that code? I don't know ams very well, but I assume that we are nolonger in ATK-land down here. Do I really have to add another argument to nfunctions, or is there some nifty feature I am overlooking? -todd inglett
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (04/10/91)
Well, you've found the right place. In particular, there's the case
that starts with
case AMS_REPLY_FORWARD:
case AMS_REPLY_FORWARD_FMT:
which is where the action really begins. Unfortunately, the headers are
handled differently for the two cases, so you'll need to handle both.
(The difference is whether the forwarded message was already in Andrew
format, or not. In one case, the work is done by EmitBE2Prefix... while
in the other case the headers aren't treated any differently from the
body.)
The good news is that, since you are indeed no longer in ATK-land, the
code you need to read preferences is really quite simple. Just use
getprofile, as in
char *s = getprofile("fwdheaders");
(Note that you don't really want "messages.FwdHeaders" because you want
preferences like *.fwdheaders to affect cui, vui, etc.)
Since that was your only specific question, I'll stop here, except to
say that I don't think this should be too difficult, but won't be
totally trivial either since the headers are currently being just "block
copied" into the forwarded message. Good luck. -- Nathanielghoti+@ANDREW.CMU.EDU (Adam Stoller) (04/10/91)
NSB Writes: > The good news is that, since you are indeed no longer in ATK-land, the > code you need to read preferences is really quite simple. Just use > getprofile, as in > > char *s = getprofile("fwdheaders"); I'm not positive, but I think that the getprofile() function returns a pointer to a centrally allocated string - which can be overwritten by any other call to getprofile - therefore you might want to malloc storage or assume some maximum length array to store the information in, so you don't have to make the call each time you forward a message. (depends on how you view the overhead of the function call with respect to the overhead of a newly malloc'd char * - presumably static and initialized to NULL so you can tell if you've already gotten the information.) --fish
Craig_Everhart@TRANSARC.COM (04/10/91)
Excerpts from internet.info-andrew: 9-Apr-91 Re: Want messages.FwdHeader.. Adam Stoller (794+0) > I'm not positive, but I think that the getprofile() function returns a > pointer to a centrally allocated string - which can be overwritten by > any other call to getprofile I looked at the ``getprofile'' source code. The function returns a pointer to a centrally-allocated string, but it is not overwritten by any other call to getprofile(). In fact, your profile is loaded exactly once, into a permanently-malloc'ed data structure, and subsequent calls to getprofile() will return pointers to parts of that data structure. Thus, you can go ahead and call getprofile() and use its result without worrying about de-allocating it. In fact, you must never deallocate the char* pointers that getprofile() returns to you. Thus, contrary to Adam's fears, you can call getprofile("fwdheaders") once, save the resultant char* result, and use it as many times as you like. (Of course, you should view the returned data as read-only; don't modify it in place or anything.) Craig
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (04/11/91)
I think that in this case Adam was right, which is not surprising, and Craig was wrong, which is considerably more unusual. I think that if the "refreshprofile" routine (or something like that) ever gets called, the storage does indeed get reclaimed. Refreshprofile gets called by "setprofilestring" which is called, at least, by the "Set Options" code in Messages. (Craig probably missed this because setprof.c and profile.c are separate files, and he was probably looking only at the latter.) So, the moral is, if you want to keep it around, it might indeed be prudent to make a copy of anything returned by getprofile. This is what the messageserver typically does -- see ams/libs/ms/init.c for examples. -- Nathaniel
gk5g+@ANDREW.CMU.EDU (Gary Keim) (04/17/91)
Excerpts from misc: 14-Apr-91 Re: Want messages.FwdHeader.. Todd Inglett@rchland.ibm (866+0) > I declared an extern char *ProgramName in reply.c and printed it out and > got a null string. Who sets the program name? (This is getting rather > interesting...) The program name is set at the end of the main routine in andrew/atk/apps/runapp.c. Here is the code: if(application_GetName(app)==NULL){ application_SetName(app,leaf(*argv)); /* just make sure */ im_SetProgramName(leaf(*argv)); } else im_SetProgramName(application_GetName(app)); if(application_ParseArgs(app,argc,argv)){ application_ReadInitFile(app); if(application_Start(app)){ exitCode=application_Run(app); application_Stop(app); } } exit(exitCode); I'm not sure, but at the point you are calling getprofile, I'll assume that you've already gone into application_Run. Correct? I think the problem may be that when you fire up an application via: % runapp -d msgsa -d the application name is set to "runapp". You can test this by adding a preference: runapp.FwdHeaders: "To:From:Date" Gary Keim ATK Group