Announcement

Collapse
No announcement yet.

COM powerbasic apps not working with latest MS Outlook

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • COM powerbasic apps not working with latest MS Outlook

    I wrote a set of Outlook productivity tools in powerbasic (compiled with pb 10) which interact with Outlook via COM.

    These worked fine with outlook thru outlook 2013 on Win 7.

    But when I leapfrogged to the current Outlook 365 on Win 10, the programs no longer work. (My locally installed Outlook is version 2106, build 14131.20360.)

    I generated a fresh INC file for the current Outlook by using the powerbasic COM browser (using the registered library in C:\Program Files (x86)\Microsoft Office\root\Office16\MSOUTL.OLB), and recompiled my program. (By the way, I have the COM browser option set to generate dispatch interface.)

    The newly compiled program still works with older Outlook versions, and still does not work with Outlook 365 (I presume that it would not work with Outlook 2016, based on other forum posters having trouble.)

    The source code from one of my simpler utilities is below. This program just reads the current view name from Outlook. The program is encountering problem with the statement:
    Code:
    LET oOutLookApp = ANYCOM CLSID $CLSID_Outlook_Application
    The above statement takes 30 seconds to execute. I expect the 30 seconds is a time-out, although it does not throw a run-time error.

    But the subsequent statement throws an error 99 (object error) when it executes.
    Code:
    OBJECT CALL oOutLookApp.ActiveExplorer TO myOlExp
    I have no idea if there's an issue with my source code, or if some security mechanism in Windows 10 or Outlook is the problem.

    If anybody has a working example of a powerbasic program interacting with Outlook 365-- or even Outlook 2016-- please share the source code and the INC file.

    Thanks for your help.

    Scott

    Code:
    #COMPILE EXE
    #DIM ALL
    #INCLUDE "MSoutlook-com-scott-generated-dispatch.inc"
    
    FUNCTION PBMAIN () AS LONG
    
    ERRCLEAR
    
    DIM oOutLookApp AS Int__Application
    DIM myOlExp AS Int__Explorer
    DIM myOlview AS view
    DIM vcurrrentview AS VARIANT
    
    LET oOutLookApp = ANYCOM CLSID $CLSID_Outlook_Application
    'the above statement takes 30 seconds to execute. Does not return an error
    'same behavior happens if above statement is
    '        LET oOutLookApp = NEWCOM CLSID $CLSID_Outlook_Application
    
    OBJECT CALL oOutLookApp.ActiveExplorer TO myOlExp
    'the above statement returns error 99, Object Error
    vcurrrentview=""
    
    OBJECT CALL myOlExp.currentview TO myOlview
    OBJECT CALL myOlview.name TO vcurrrentview
    
    msgbox VARIANT$(vcurrrentview)
    
    myOlview=NOTHING
    myOlExp=NOTHING
    oOutLookApp = NOTHING
    
    END FUNCTION
    Last edited by S Stamp; 29 Aug 2021, 10:31 AM.

  • #2
    Just a quick thought,,

    Code:
    LET oOutLookApp = ANYCOM CLSID $CLSID_Outlook_Application
    Give it a shot with "NEWCOM" rather than "ANYCOM"
    AND error check at this point or at least add some kind of display after this statement.

    Program may actually be hanging up on the 'ANYCOM' statement
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      Thanks Michael. The NEWCOM vs ANYCOM did not make a difference. Same behavior with both versions.

      But you are onto something, that the problem is happening with:
      Code:
      LET oOutLookApp = ANYCOM CLSID $CLSID_Outlook_Application
      With extra debug statements, I found that the program was not "freezing". Instead, the "LET oOutLookApp = ..." statement is taking 30 seconds to execute, and does not return an error. But it must be encountering some sort of timeout and not completing the desired action, because the next "OBJECT CALL" statement returns error 99, object error.

      Any other suggestions?

      (I edited the original post to incorporate the more accurate trouble description discovered from these debug activities.)

      Comment


      • #4
        Have you installed 32 bit Outlook? By default 64bit gets installed and i don't think COM is bit agnostic.

        Comment


        • #5
          Thanks Carlo

          The PC I'm using to write and debug the code has 32-bit Outlook installed:

          Microsoft® Outlook® for Microsoft 365 MSO (16.0.14131.20278) 32-bit

          So that's not the cause of my 'current' problem described above. But once I get the program working, I'll want to also use it on my laptop which has 64-bit Outlook.

          If I can get beyond my current 32-bit problem, what's involved in making it work on 64-bit? Do I just need to generate a fresh INC file using the 64-bit version of the resource library? Will the 32-bit powerbasic COM browser even work to generate the INC from the MSOUTL.OLB associated with a 64-bit program?

          Comment


          • #6
            You will need a 64-bit compiler and browser.
            Forum: http://www.jose.it-berater.org/smfforum/index.php

            Comment


            • #7
              > You will need a 64-bit compiler and browser.

              Actually, if I can get the program working with the 32-bit MS Outlook, I think it will be compatible with 64-bit Outlook, knock on wood.

              I also wrote PowerBASIC utilities using COM to interact with MS Word. The programs were compiled using the INC generated from Word 2003 resource library; they still work with Word 365 (32-bit) without any recompiling needed. I just moved my PowerBASIC EXE to a laptop with Word 365 (64-bit), and it works fine too,

              Hopefully the same will hold true for Outlook 64-bit... that is, assuming I can ever get the program working with Outlook 32-bit.

              Comment


              • #8
                A 64-bit process can't load an in-process 32-bit COM server (DLL), and vice versa. A 64-bit process can use a 32-bit out-of-process COM server (EXE). Microsoft has information about process interoperability at https://docs.microsoft.com/en-us/win...teroperability
                Mike Stefanik
                sockettools.com

                Comment


                • #9
                  The programs were compiled using the INC generated from Word 2003 resource library; they still work with Word 365 (32-bit) without any recompiling needed.
                  Thank you.

                  You just made my case for all the times I have cautioned members about reading/writing MS-Office files in their "native" format (e.g., Excel files in XML format, or the format before that (SYLK?)) rather than using the supplied API.

                  Or maybe the XML is now the internal format for MS-Access database files. Whatever, using the API makes your software "version agnostic."

                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    Originally posted by Michael Mattias View Post
                    Or maybe the XML is now the internal format for MS-Access database files.
                    Thankfully, it's not
                    (But .mdb and .accdb are very different formats)


                    Comment

                    Working...
                    X