Announcement

Collapse
No announcement yet.

What causes COM to change?

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

  • What causes COM to change?

    I have a PB9-DLL I use to call a COM object.
    On all machines, a small PB9 EXE works fine.

    But, on some machines, a NON-PB EXE, the DLL won't create the COM object.

    What outside, affects the ability of the PB-DLL to create an instance of the COM object?
    I can't find how I can get any error info either to tell me more...

    Suggestions?

    Thanks,
    Last edited by Paul MacFarlane; 17 Nov 2008, 02:29 AM.
    Paul

  • #2
    tips...

    Hi Paul,

    1. Check if the COM Dll is registered, that is pretty obvious (use Regsvr32 to
    register).
    2. Use Dependency Walker (freeware tool) to see if all the components are present.

    Maybe other people here can add some more tips but these are the ones that come to mind in pica-second.
    So here we are, this is the end.
    But all that dies, is born again.
    - From The Ashes (In This Moment)

    Comment


    • #3
      DLLs need to initialize the COM library with CoInitialize or CoInitializeEx and uninitialize it with CoUninitialize. The problem is that DLL_PROCESS_ATTACH is not a reliable place to do it, so you will need to write an exported function or procedure for it, e.g.

      Code:
      SUB MyInitialize ALIAS "MyInitialize" () EXPORT
         CoInitialize BYVAL %NULL
      END SUB
      
      SUB MyUninitialize ALIAS "MyUninitialize" () EXPORT
         CoUninitialize
      END SUB
      I'm assuming that you are talking of a standard DLL, not a COM server.
      Forum: http://www.jose.it-berater.org/smfforum/index.php

      Comment


      • #4
        Interesting comment Jose, would it help if the DLL is explicately loaded by the non PB exe a little later in the program. As those functions are part of the PB run time then the PB exe will also be executing them. If the DLL is loaded by the non-PB exe later in its start up via an explicit load rather than automatically does it have a better chance of success?

        Comment


        • #5
          No. The COM library is not initialized globally. What you can try is to call CoInitialize at the very start of the non-PB EXE program that uses the PB DLL, and CoUninitialize at the very end. Not sure if it will work, however. I only use the PB compilers with Windows.
          Forum: http://www.jose.it-berater.org/smfforum/index.php

          Comment


          • #6
            Thanks Guys....

            I'm a little confused though about calling CoInitialize, etc. My DLL is NOT a COM server, it just happens to use COM components....

            I am not using any code in DLL_PROCESS_ATTACH - I don't even have one.

            So, what is confusing to me is what the PB.EXE does when it loads the PB.DLL versus what a NON-PB-EXE does (or doesn't do).

            Under certain conditions the NON-PB-EXE uses the PB-DLL fine. But I can't determine what those conditions are - so I can correct them.

            So, the PB-EXE calls the PB-DLL fine all the time.
            The NON-PB-EXE calls the PB-DLL fine SOME of the time.

            Actually, the call works fine, it's just that the function in the DLL instantiates a COM object and that is unsuccessful in the NON-PB-EXE sometimes.
            Paul

            Comment


            • #7
              My DLL is NOT a COM server, it just happens to use COM components....
              But it can't use COM realiabily if the COM library has not been initialized.

              So, what is confusing to me is what the PB.EXE does when it loads the PB.DLL versus what a NON-PB-EXE does (or doesn't do).
              PB calls CoInitialize at the beginning of PBMAIN and CoUninitialize at the end. This is why I'm suggesting that you try to call CoInitialize at the very start of the non-PB EXE program that uses the PB DLL, and CoUninitialize at the very end.
              Forum: http://www.jose.it-berater.org/smfforum/index.php

              Comment


              • #8
                Thanks Jose...

                I'm starting to understand a little better now....

                So, if I understand, a PB-EXE calls CoInitialize/CoUninitialize regardless of whether it's using COM or not (as in this case because the COM is hidden in a DLL).

                So, can I just add CoInitialize/CoUninitialize calls to my DLL function so I don't have to burden another developer with that step?

                I understand you said it's not reliable to do that in DLL_PROCESS_ATTACH.

                This DLL contains individual unrelated calls. So, unless it's bad to call CoInitialize/CoUninitialize multiple times, maybe that is my best solution.?

                Also, where do I find more info on CoInitialize/CoUninitialize. I don't see it....


                Thanks again for your help and insight - and education....
                Last edited by Paul MacFarlane; 17 Nov 2008, 01:11 PM.
                Paul

                Comment


                • #9
                  Okay Jose....

                  I found the calls to CoInitialise, etc... and it worked !

                  Now, the only remaining question is: Is it bad to call it in pairs within the functions themselves...

                  In other words, do I need to put the requirement on users of the DLL to call CoInitialise/CoUnInitialise or is there a way I can do it for them?

                  Thanks again,
                  Paul
                  Paul

                  Comment


                  • #10
                    Just try it. I never have done it this way, so I can't confirm or deny it with certainty.
                    Forum: http://www.jose.it-berater.org/smfforum/index.php

                    Comment


                    • #11
                      I'm trying it and it seems to work fine...

                      I'll let you know if I get some weird results somehow....

                      Thanks again,
                      Paul
                      Paul

                      Comment

                      Working...
                      X