›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

SRP_COM vs OI com programming

keemankeeman
in SRP Utilities
We experience OI crashes every now and then.
We read that OI com programming is partly responsible for those crashes.
Is the use of SRP_COM a good practice to avoid crashes?
In our srp_editor, when we use SRP_COM, more services popup then there are service documented on your wiki pages.
Are those extra services documented somewhere?

Regards
Ed Keeman

Comments

  • DonBakkeDonBakke
    I cannot claim that SRP_Com will avoid your crashes since I don't know the nature of your crashes. That said, we wrote SRP_Com to be as robust and feature capable as possible. It does provide functionality that the OI COM support does not (which may or may not be of value to you). We also created it to provide COM functionality to older versions of OI that did not have native COM support. FWIW, I use SRP_Com in all my code, regardless of the OI version, and I have never had it crash. But, to be honest, you'll have to just run your own tests to see how it goes.

    Can you provide a list of those services you are seeing which aren't documented in the Wiki? It is possible these are internal services that are not meant to be exposed, but our service logic would catalog them anyway so that could be why you are seeing them.
  • keemankeeman
    The undocumented services are:
    GETAXOBJECT
    HASERROR
    SET_REF
    I think that GETAXOBJECT = GetActiveXObject.
    In VB I wrote my own com-dll to connect to already running classes, so we can connect to running Excel, Word etc applications. Maybe you can do this also with SRP_COM in the next release :)
    It can connect to an already running class, if the class isn't running it createss one.
    In vb I use GetObject and CreateObject to do the trick.

    Regards,
    Ed Keeman
  • keemankeeman
    About the oi crashes this is what we read
  • BarryStevensBarryStevens
    edited June 2017
    Is srp_com a substitute for OI's Ole.... routines (srp_com seems much easier to implement)
    Is it faster?
  • DonBakkeDonBakke
    About the oi crashes this is what we read
    If I am understanding you correctly, you are experiencing periodic crashes but you actually don't know the reason for them or what OI process is causing them. You are speculating that the OI COM library might be related due to the post you linked to (which is, of course, my own comment on the subject).

    Just a point of clarification, that thread and my references to "COM" was in the context of ActiveX (i.e., OLE, which is a visual wrapper around COM). I have no reason to suspect that the Basic+ COM libraries (i.e., OLECreateInstance, OLECallMethod, OLEGetProperty, OLEPutProperty, etc.) have ever caused OI to crashed when used properly. Therefore, I think you might have gotten confused and are looking for culprits when there are likely to be none.
  • DonBakkeDonBakke
    Is srp_com a substitute for OI's Ole.... routines (srp_com seems much easier to implement)
    Is it faster?
    Yes...and I would like to think our syntax is easier to implement. Is it faster? I don't know. I haven't done any benchmarking to compare.
  • keemankeeman
    Thanks Don,
    You're right, I was suspecting the COM programming to be a reason for unexplained crashes.
    So that leaves all our beautifull SRP conrtrols maybe to be the cause. Have to look in replacing the ALL_OLES switch.
    Regards
    Ed
  • DonBakkeDonBakke
    So that leaves all our beautifull SRP conrtrols maybe to be the cause. Have to look in replacing the ALL_OLES switch.
    Correct, although we are fairly confident that the problem is still internal to OI even though it is our controls that are involved. We have tried to work with various customers to create a reproducible crash scenario. So far, no one has been able to do this. All we seem to know is that the crashes are more common with newer versions of OI (hence, that thread with the recommendation to remove ALL_OLES), and some flavors of Windows Server.

    If we know what conditions can cause the crash, we'll do everything we can to workaround it even if the problem isn't really ours. We just want systems to run without falling over.
  • keemankeeman
    Thanks Don, so I understand that OI crashes are common. Let's see how that goes for OI 10.

    Don't forget to answer about the undocumented Services in SRP_COM and my question about GetObject/CreateObject.
    Regards,
    Ed
  • DonBakkeDonBakke
    It might be a couple more weeks. My primary engineer who developed this utility is on holiday .
  • KevinFournierKevinFournier
    GETAXOBJECT was an attempt to support ActiveX Controls with properties that return objects. It doesn't work, so I didn't document it. HASERRORS returns a 1 if the last SRP_COM call generated a COM error. SET_REF is like SET, but it expects an SRP_COM object handle instead of a value. I'll make a note to document these latter two.

    As for connecting to running applications, that is handled on the side of the COM API in question, thus SRP_COM's CREATE method should be all that is needed. The MS Office Automation objects are always created because you are creating an object that will access Word--you are not creating an instance of Word. The Automation object, once created, then allows you to decide if you are going to access a running instance of Word or generate a new instance. If SRP_COM's CREATE service is not working for you for some reason, let me know and I can investigate.
Sign In or Register to comment.