Conference iosg::all-in-1_v30

	Well I found out a couple of things:

		
	I can use the MAIL TO function to update the mail header but
	I still can't figure out how to get the mail$scl_function dsab
	(where is this documented ?)  to refresh the scroll region.  It appears
	this DSAB doesn't work with oa$scl_fresh and oa$scl_update.


	It appears that this is only a problem from within a CMU.  This seems
	work okay if the address lookup is called from a keystroke (like
	the GOLD M stuff) but this is not acceptable for this application.


	I can return multiple addresses by getting all the addresses
	returning the first one in emaddress and build a script script
	to put the remaining into the to or cc field.  This really seems
	like a poor way to do this.

	Any other ideas ?   Can the mail$scl_function be made to update
	within emhead without exiting ?

	

	John
		
		

	OK, I'm going to take a shot at this, just to prove that I don't know
what I'm talking about.

	You seem to be confusing two different "data sets" in what you're trying
to do.  MAIL$SCL_FUNCTION is a scrolling DSAB used on forms like EMHEAD to
acquire the names of those who will receive mail (or attend meetings, in the
case of TM).  The MAIL TO function is a method of directly adding TOs into the
DAF record of the current message.

	For example, after you've done a few MAIL TOs, try something like:

	FOR CAB$ATTRIBUTES:TO DO GET .%WHOLE

You'll find that they are, indeed there!  Where is "there"?  In the DAF record,
of course.  Which does *not* have a direct correlation (in terms of "write-
through" capabilities) with the scrolling DSAB MAIL$SCL_FUNCTION.  (That'd be
kind of like saying that if, while on the EM IR index form, I get into another
session and move more messages to the READ folder, they will "magically" appear
on the first session's index form.)

	Why not try emulating what's in the Named Data of form EMHEAD?  In
other words, let's suppose the name you want to add is in #NAME.  You might
try something like:

	MAIL TO #NAME
	FOR OA$MAIL_ADD_ADDR WITH .USER EQS #NAME
	GET TO = OA$SEL_BINARY_ADDRESS

	I'm sure someone else can give you more details on this.  
	

	Perhaps I wasn't clear .....

>>
>>You'll find that they are, indeed there!  Where is "there"?  In the DAF record,
>>of course.  Which does *not* have a direct correlation (in terms of "write-
>>through" capabilities) with the scrolling DSAB MAIL$SCL_FUNCTION.  (That'd be
>>kind of like saying that if, while on the EM IR index form, I get into another
>>session and move more messages to the READ folder, they will "magically" appear
>>on the first session's index form.)
>>

	I know that they are there ..... my point is that I should be able
	to do something like an oa$scl_update and an oa$scl_refresh and
	have the scrolling dsab refresh.  I certainly can do this with any
	other index form (which is a scrolling region).  
	Granted, I must refresh the screen but this is NORMAL behavior for 
	scrolling regions.   

	The only way I can get the scrolling region on emhead to update is
	to exit the form and reenter it or have a way to refresh the scrolling
	region.  There is no pratical way to do this when invoking an AMTS.

	Again all I am trying to do is build something similar to the GOLD
	M function but be able to activate it using a .CMU procedure.
	The trick is to get multiple addresses to be returned.

	
	

	I realize that this isn't a thorough test, but I just created a script
consisting of:

	MAIL TO #NAME
	FOR FIRST OA$MAIL_ADD_ADDR WITH .USER EQS #NAME
	GET TO = OA$SEL_BINARY_ADDRESS

	I put a valid name into #NAME, then from the EMHEAD form, I pressed
Gold 7 to get into Command mode and said DO MYSCRIPT.  It seemed to work for me.

	F

    What is desired in .0 is to return multiple address values, of course.
    The code in .4 (and .2) returns a single mail address value to the form
    (roughly and cleverly).

    All you need to do is to add an OA$SCL_DOWN and you're almost done.

    Of course, it would be nice to generalize the code so that it worked on
    both of the address fields on the EMHEAD family of forms.  Given that
    the field names are cleverly named the same as the attribute they
    represent the field name can be used to load the attribute.

    So, your .CMU file could invoke the following script for each address
    to be inserted into the message:

            GET OA$FUNCTION = "MAIL " OA$FIELD_NAME " #MAILADDR"
            FOR FIRST OA$MAIL_ADD_ADDR WITH .USER EQS #MAILADDR
            GET OA$FUNCTION = "GET " OA$FIELD_NAME " = OA$SEL_BINARY_ADDRESS
            OA$SCL_DOWN

    Have fun,
    don

	Thanks for the examples but we're still talking apples and oranges


	.4 and .5 DOES NOT WORK FROM A .CMU


	Here is the logic:


	For the first address entered (actually the last but it doesn't matter)
	simply return #emaddress (or whatever the magic symbol is)

	Otherwise 
	Do the mail to stuff.
	If you run this stuff OUTSIDE the .cmu mail$scl_function dsab is
	updated and you of course see the new address and .4 and .5 
	so nicely showed us.  


	THIS DOES NOT WORK WITHIN A .CMU.    THE ADDRESS IS NOT VISIBLE ON 
	EMHEAD UNTIL YOU RE-INVOKE THE EMHEAD FORM ?

	Once again,  can anyone explain this behavior ?

		
	John

    I suspect that the reason for the non appearance of the information is
    that the dataset is open by the scroll function and doesn't get updated
    automatically.

    I added a 

    GET OA$FUNCTION = "OA$SCL_INIT ,,,MAIL$SCL_FUNCTION:" OA$FIELD_NAME

    at the end of my .CMU and it worked and showed that the logic in .2,
    .4, and .5 actually doubles the addresses.  I suggest just doing the
    MAIL TO/CC and not add to the TO/CC fields on the form.

    My approach was also to not use the #EMDADDRESS symbols but to just
    just plug the results directly into the mail message such that there
    was no difference between the first and subsequent addresses.

    Good luck,
    don

>>    My approach was also to not use the #EMDADDRESS symbols but to just
>>    just plug the results directly into the mail message such that there
>>    was no difference between the first and subsequent addresses.

      Two problems with this.


	When you do the oa$scl_init it put the cursor back at the top
	of the scroll region (even of course if you issue oa$scl_down 
	commands).   If you issue an oa$scl_bottom (after the
	oa$scl_init)  this doesn't put
	the cursor on the line after the last entry.

	Also if you invoke the CMU and don't set emdaddress to something
	other than null, you get a BAD ADDRESS MESSAGE and the address
	that you put in to invoke the CMU is now in the address header
	and has to be manual clear out.  

	How did you get around this ?

	I think I have to return EMDADDRESS but if I do this after the 
	oa$scl_int I get a %OA-F-GETVMFAIL error somewhere in the post
	processing of the cmu file.   

	I was able to get this working with a script script which is built
	on the fly to fill the to or cc information but it really is
	unacceptable in terms of performance.  (It's quite possible that
	this cmu will return 100 names or more).

	
	Did I miss something ?


	John

    Unfortunately, I haven't solved either of those 'features'.
    
    Sorry,
    don

    I'm in a real jam then.  Is there any documentation that would provide
    me some insight to a work around ?
    
    
    john

    I assume that there is a requirement that the sending user see the
    addresses added by the procedure in question.  If this were no the case
    then the earlier attempts would get pretty close.

    It may be that the easiest way to implement what seems to be required
    is to use the CMU to return the first address via the #EMD* symbols and
    create a temporary SCRIPT mode script which contains the desired
    addresses and then invoke it via the SCRIPT function.

    I have tested it this works just fine. My trivial CMU file is after the
    form field.

    I hope that it helps,
    don
    
    $! TEST.CMU		A test CMU procedure
    $!
    $       WRITE OAMAILBOX "OA GET #EMDADDRESS = ""MARGARET""
    $       @DCLMAILBOX:
    $       WRITE OAMAILBOX "OA GET #EMDADDRESSINFO = ""Marg""
    $       @DCLMAILBOX:
    $!
    $       OPEN/WRITE TMP OAUSER:TMP_EMHEAD.SCP
    $       WRITE TMP "MUTH{RETURN}"
    $       WRITE TMP "ME{RETURN}"
    $       CLOSE TMP
    $	    PURGE OAUSER:TMP_EMHEAD.SCP
    $!
    $       WRITE OAMAILBOX "OA SCRIPT TMP_EMHEAD.SCP"
    $       @DCLMAILBOX:
    $!
    $! [End TEST.CMU]

	Don,


	That basically what I've done and it does work okay for a few addresses.
I am concerned when a large number is selected.   The other work around is
to implement a keystroke like {GOLD}s from the emhead menu instead of actually
having them type in an address.  Then I can simple use (mail to) to hammer
in the addresses and not mess with emdadress

	Thanks again for your help

	John

Just one message that the user hardly notices...

script called from the CMU:

	MAIL TO ...
	MAIL TO ...
	MAIL TO ...
	GET #EMDADDRESS = ""
	GET OA$FUNCTION = "FOR CAB$ATTRIBUTES:" OA$FIELD_NAME 
	GET #X = OA$SEL_COUNT
    	GET OA$FUNCTION = "OA$SCL_INIT ,,#X,MAIL$SCL_FUNCTION:" OA$FIELD_NAME 
	SCRIPT Y.SCP

Y.SCP:
{DOWN}

<<Just one message that the user hardly notices...

	It's real noticeable when accessing from slower dialin lines. 

John