Skip to main content

[archive] Outlook Process

  • October 16, 2006
  • 2 replies
  • 0 views
D

[Migrated content. Thread originally posted on 13 October 2006]

I am hoping that some other users who are automating Outlook might have a suggestion.

I am automating Outlook to send emails. I am not trying to add contacts, etc, just send an email with an attachment, which is working. However, I am finding that depending on how Outlook is configured as far as handling send/receive requests when offline, etc, I am getting errors after sending multiple email requests and then trying to start Outlook. I think the problem is that my Outlook process is staying in memory, after my COBOL program is finished with it. If I manually start Outlook and leave it running, I have no problems. Here is my code:

CREATE APPLICATION OF OUTLOOK HANDLE IN OUTLOOK-HANDLE.
MODIFY OUTLOOK-HANDLE GetNameSpace("MAPI")
GIVING OUTLOOK-NAMESPACE.
MODIFY OUTLOOK-NAMESPACE @LOGON().
MODIFY OUTLOOK-HANDLE
CREATEITEM (olMailItem) GIVING MAIL-HANDLE.
MODIFY MAIL-HANDLE @TO RECIPIENT-ADDRESS.
MODIFY MAIL-HANDLE @SUBJECT EMAIL-SUBJECT.
MODIFY MAIL-HANDLE @BODY EMAIL-MESSAGE.
INQUIRE MAIL-HANDLE Attachments IN ATTACHMENT-HANDLE.
MOVE 0 TO CNTR.
PERFORM VARYING PTR FROM 1 BY 1 UNTIL PTR > 59
IF ATTACHMENT-FILE(PTR) NOT = SPACES
ADD 1 TO CNTR
MODIFY ATTACHMENT-HANDLE @ADD (
ATTACHMENT-FILE(PTR),
olByValue,
CNTR,
ATTACHMENT-NAME(PTR))
END-IF
END-PERFORM.
MODIFY MAIL-HANDLE @SEND().
DESTROY ATTACHMENT-HANDLE.
DESTROY MAIL-HANDLE.
DESTROY OUTLOOK-NAMESPACE.
DESTROY OUTLOOK-HANDLE.

I am destroying the handles in the order I created them. I have also tried adding the Logoff command on the OUTLOOK-NAMESPACE handle and the Quit command on the OUTLOOK-HANDLE and neither seem to destroy this process.

Thanks,
Rebekah

    2 replies

    D

    [Migrated content. Thread originally posted on 13 October 2006]

    I am hoping that some other users who are automating Outlook might have a suggestion.

    I am automating Outlook to send emails. I am not trying to add contacts, etc, just send an email with an attachment, which is working. However, I am finding that depending on how Outlook is configured as far as handling send/receive requests when offline, etc, I am getting errors after sending multiple email requests and then trying to start Outlook. I think the problem is that my Outlook process is staying in memory, after my COBOL program is finished with it. If I manually start Outlook and leave it running, I have no problems. Here is my code:

    CREATE APPLICATION OF OUTLOOK HANDLE IN OUTLOOK-HANDLE.
    MODIFY OUTLOOK-HANDLE GetNameSpace("MAPI")
    GIVING OUTLOOK-NAMESPACE.
    MODIFY OUTLOOK-NAMESPACE @LOGON().
    MODIFY OUTLOOK-HANDLE
    CREATEITEM (olMailItem) GIVING MAIL-HANDLE.
    MODIFY MAIL-HANDLE @TO RECIPIENT-ADDRESS.
    MODIFY MAIL-HANDLE @SUBJECT EMAIL-SUBJECT.
    MODIFY MAIL-HANDLE @BODY EMAIL-MESSAGE.
    INQUIRE MAIL-HANDLE Attachments IN ATTACHMENT-HANDLE.
    MOVE 0 TO CNTR.
    PERFORM VARYING PTR FROM 1 BY 1 UNTIL PTR > 59
    IF ATTACHMENT-FILE(PTR) NOT = SPACES
    ADD 1 TO CNTR
    MODIFY ATTACHMENT-HANDLE @ADD (
    ATTACHMENT-FILE(PTR),
    olByValue,
    CNTR,
    ATTACHMENT-NAME(PTR))
    END-IF
    END-PERFORM.
    MODIFY MAIL-HANDLE @SEND().
    DESTROY ATTACHMENT-HANDLE.
    DESTROY MAIL-HANDLE.
    DESTROY OUTLOOK-NAMESPACE.
    DESTROY OUTLOOK-HANDLE.

    I am destroying the handles in the order I created them. I have also tried adding the Logoff command on the OUTLOOK-NAMESPACE handle and the Quit command on the OUTLOOK-HANDLE and neither seem to destroy this process.

    Thanks,
    Rebekah
    I have also experienced this, and albeit I hate to admit it, I gave up on getting Outlook to shut down. There is a mechanism in there forcing it to stay alive. I have btw the same experience with other programming languages as well, so I think this is an Outlook phenomena.
    D

    [Migrated content. Thread originally posted on 13 October 2006]

    I am hoping that some other users who are automating Outlook might have a suggestion.

    I am automating Outlook to send emails. I am not trying to add contacts, etc, just send an email with an attachment, which is working. However, I am finding that depending on how Outlook is configured as far as handling send/receive requests when offline, etc, I am getting errors after sending multiple email requests and then trying to start Outlook. I think the problem is that my Outlook process is staying in memory, after my COBOL program is finished with it. If I manually start Outlook and leave it running, I have no problems. Here is my code:

    CREATE APPLICATION OF OUTLOOK HANDLE IN OUTLOOK-HANDLE.
    MODIFY OUTLOOK-HANDLE GetNameSpace("MAPI")
    GIVING OUTLOOK-NAMESPACE.
    MODIFY OUTLOOK-NAMESPACE @LOGON().
    MODIFY OUTLOOK-HANDLE
    CREATEITEM (olMailItem) GIVING MAIL-HANDLE.
    MODIFY MAIL-HANDLE @TO RECIPIENT-ADDRESS.
    MODIFY MAIL-HANDLE @SUBJECT EMAIL-SUBJECT.
    MODIFY MAIL-HANDLE @BODY EMAIL-MESSAGE.
    INQUIRE MAIL-HANDLE Attachments IN ATTACHMENT-HANDLE.
    MOVE 0 TO CNTR.
    PERFORM VARYING PTR FROM 1 BY 1 UNTIL PTR > 59
    IF ATTACHMENT-FILE(PTR) NOT = SPACES
    ADD 1 TO CNTR
    MODIFY ATTACHMENT-HANDLE @ADD (
    ATTACHMENT-FILE(PTR),
    olByValue,
    CNTR,
    ATTACHMENT-NAME(PTR))
    END-IF
    END-PERFORM.
    MODIFY MAIL-HANDLE @SEND().
    DESTROY ATTACHMENT-HANDLE.
    DESTROY MAIL-HANDLE.
    DESTROY OUTLOOK-NAMESPACE.
    DESTROY OUTLOOK-HANDLE.

    I am destroying the handles in the order I created them. I have also tried adding the Logoff command on the OUTLOOK-NAMESPACE handle and the Quit command on the OUTLOOK-HANDLE and neither seem to destroy this process.

    Thanks,
    Rebekah
    Ok thanks for your response. I did find on Microsoft's website documentation that Outlook does not like to send multiple attachments via programming when it is not running in the background. So, that along with your response let's me know that I need to tell my users to have their Outlook up and running for best results. Thanks.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement