Sentry Issue

RE: Sentry Issue

Hi Trevor,,
I am thinking aloud now...

I gather some of your users have new 64 bit machines and then it stopped working.
My immediate idea would be a failed COM Registration issue.
Make sure that you register (32 bit regasm) with administrator rights. 

- Plugins are loaded and running in-process. Everything must be 32 bit.
64 bit COM can only work when Marchalling is involved.
For instance you can run an external 64 bit app and access the SoApplication COM instance (marchaling involved) but you cannot instantiate a SuperOfficeDB instance (no marchaling involved)..

- I don't see why porting your VB plugin to VB.Net should solve anything.

- Observe that you could write both the Netserver and the Win plugin part in 1 c# class/dll.
All you need is the [ComVisible(true)] attribute.

To register a .net assembly you need to find a regasm.exe in the .Net universe e.g.

  c:\windows\Microsoft.NET\Framework\v2.0.50727\regasm.exe

For now, this is what springs to mind...

/conrad

RE: Sentry Issue

Hi Conrad,

Thanks for this.  I did try to regsvr32 the file, as it registered successfully, I did not use regassm as I did not think that worked with vb 6.

We could look to try to rewrite it as a C# dll.  In this case do you have to have 2 classes, one for COM and one for Netserver, or does the same code work for both?

Many thanks,

Trevor

RE: Sentry Issue

Hi Trevor,

about porting this to c#: you can combine it all in one class like this:

namespace CombiSaleSentry
{
   [SentryPlugin("sale", "CombiSaleSentryPlugin.Test")]
   [ProgId("CombiSaleSentryPlugin.Test")] // COM identification
   [Guid("A7A8B662-93CF-4086-A8CD-89040CBEE8C1")]
   [ComVisible(true)]
   public class SaleSentryPlugin :
                                ISentryPlugin,
                                SOSentryPlugin.Interop.ISentryPlugin, // COM API
                                SOSentryPlugin.Interop.ISentryPlugin2 // COM API
  {

      // Implement ISentryPlugin methods for netserver...
      // Implement Interop methods for Win cleint.
  }
}

But I still think that this is not necessarily going to solve anything.
/conrad

RE: Sentry Issue

Hi Conrad,

Thanks for this, it may be worth giving it a try.  The strange this is if I rename the dll, SuperOffice Windows will not start, complaining that it cannot find the sentry dll.  So it does C it.  But when it is present on all the 64 bit machines, it just ignores it.  On the 32 bit machines it is fine.

But I will to port it to C and see if this fixes is.

Many thanks,

Trevor

RE: Sentry Issue

I am more and more convinced that you are having a COM registration issue on the 64bit machines.
Make sure it is being registered in the 32bit universe with administrator rights.
(Search the registries perhaps?)
I am not sure how one does this with a VB6 dll.
/conrad

RE: Sentry Issue

Great, thanks Conrad.  I will let you know how I get on.

Trevor

RE: Sentry Issue

Hi Conrad,

Thanks for you help on this, your comments pointed me in the right direction. The problem was not with the dll itself, but the code itself.  I basically look up a custom table to see if the appointment has been approved.  I used to use db.GetADOConnectionString to get the connection string to the database, but I don't know if you remember, some time ago if you used this it changed all dates in SuperOffice to the US format, which is problematic for us in the UK.  So as it was only reading SuperOffice data, I added the connection string manually in the complied dll, to query the SuperOffice database, and this was using {SQL Native Client}.  The new version of Windows do not seen to support this.  I have recomplied the dll using {SQL Server} and the dll is working as it should do.

Thank you for your help on this.

Trevor