[RBASE-L] - problem with email option with report

[jbainc]

I am using the below code to send emails to my customers – when I have the |EMAIL_SHOW_DIALOG ON the program encloses the |EMAIL_TO_LIST .vemailname with ‘ – if I remove then the email is successfully transmitted – if I do not the email is not send.  If I set the dialog off – the email is not send – I have a |EMAIL_BCC_LIST em...@npbcgas.net in every case is received.  Is there a work around to eliminate the ‘ from the output.   Thanks J        set var vcustidenfm = 1887   drop cursor c1   DECLARE c1 CURSOR FOR SELECT EMAIL FROM VWEMAILCUST where CUSTIDEN = .VCUSTIDENFM   OPEN c1   clear var vemailname   set v vemailname text   set v vcount integer =  0   FETCH c1 INTO vemail IND v1   WHILE sqlcode <>100 THEN    if vcount = 0 then      set v vemailname = .vemail    else      set v vemailname = (.vemailname + ',' + .vemail)    endif      set v vcount = (.vcount + 1)   FETCH c1 INTO vemail IND v1   ENDWHILE   DROP CURSOR c1       label emailsetup         set v vSUBJECT = (FirstName & MiddleName & LastName & '-A-' & FullNameX & 'CUSTOMER CONFIRMATION' ) from A1Customer +         where custiden = .vcustidenFM         set v vfullnamexem = (CTXT(.VCUSTIDENFM))         set v vfullnamexpdf = ('c:\pdf_files\' +.vfullnamexem + '.pdf')         SET V VBODY TEXT = EmailMsgTxt FROM A3EmailMgs WHERE EmailMgsIden = 3        PRINT A1EmailCustomer WHERE custiden = .vcustidenFM +         OPTION PDF|FILENAME .vfullnamexpdf |EMAIL ON |EMAIL_TO_LIST .vemailname +         |EMAIL_BCC_LIST em...@npbcgas.net |EMAIL_REPLY n...@npbcgas.net +         |EMAIL_HOST mail.npbcgas.net |EMAIL_USERID off...@npbcgas.net |EMAIL_PASSWORD npbc +         |EMAIL_FROM_NAME NPBC OFFICE |EMAIL_FROM_ADDRESS off...@npbcgas.net +         |EMAIL_SUBJECT .VSUBJECT +         |EMAIL_BODY &vbody +         |EMAIL_ATTACHMENTS .VFULLNAMEXPDF +         |EMAIL_DELETE_AFTER_SEND Off +         |EMAIL_SHOW_DIALOG ON         update a1Email set EmailVerify = 'S' where custiden = .vcustidenFM RETURN     -----Original Message----- From: karentel...@cs.com Sent: Aug 10, 2010 9:55 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: converting forms from DOS to 7.6 Oh goodness knows I certainly don't convert the DOS forms and then leave them like that!   UGLY!   For sure there's a bit of cleanup involved after converting, but lasso-ing everything and changing attributes is so easy to do.   And I do convert all external eeps into internal code, and as I do so I check the code to see what can be changed, and what must be changed.  Sometimes I look at a multi-table DOS form and say "that needs to be a tabbed form".  In that case I will usually create a new form with my tabs on it, convert the DOS form to another new form and copy and paste the fields onto the tabs.   Most of the time the eep code will work fine.  You watch out for keymaps, you watch out for form lookups within the code or form expressions.  But if you were creating a form from scratch you would have to look at the DOS code for this info anyway, so no time savings starting from scratch. But the main reason I do this is to make sure I don't "lose" anything.  So just want to reiterate for anyone starting a form from scratch, that you must first carefully look at every single field on that DOS form to see what eeps are run on entry and exit, and whether there are popup menus on the field.  Also look at the table properties to find what eeps are run on entry, exit, save, leave section... If you convert those capabilities are brought over.  Yes you may need to change them, but you won't miss bringing it over.  They are easy to miss if you start from scratch. Karen I guess we agree to disagree. In my experience, converting old DOS forms is just delaying the eventual re-coding of the form to use the new tools. For example, the way lookups were handled on DOS forms and the way they are handles in the 7.X and newer versions is markedly different. The entire approach to the operation of the form has changed radically since the DOS days, EEPS are now stored within the form rather than externally, the new commands such as SELECT instead of COMPUTE give you SQL compatibility. The advent of the PROPERTY construct alone with the countless (and I truly mean countless) options, that give you incredible flexibility, would make a re-write (rather than conversion) worth it. I now also make extensive use of temporary tables and views created on the fly, something that I just did not do in the DOS days...I don't believe you could. In the DOS days I built applications using the Application Builder; now, all my application run from custom forms. Last but not least, when converting forms, you bring the dated look and feel of the DOS forms. Even the look and feel of 6.5 windows was a dated hybrid look; the look of the newer versions is truly compatible with the more up-to-date Windows look. I can honestly say that I have spent more time changing the look of converted forms than it would have taken to re-code the form in the first place. With availability of the form wizard, the simple forms can be re-coded in a matter of minutes, and the more complicated forms definitely benefit from the new tools available. J Blaustein 12 Herrick Drive Lawrence, NY 11559-1420 516-371-3445