EA 16.1 64 Bit Touble with "AddWindow" Method

[Squeegee]

Hello all,
we're migrating to EA 16.1 64 Bit version and therefore also have to migrate the Addins we have.
Generally Addins work meanwhile but we have trouble with function "AddWindow".

Our Addin is based on .NET Framework 4.8.1

Here a code extract:

Code: [Select]

if (buttonWindow == null)
{
    buttonWindow = (TheButtonWindow)pRepository.AddWindow("ButtonWindow", "ButtonWindowProgId");
    var test = pRepository.GetLastError();
    buttonWindow.currentRepository = pRepository;
    buttonWindow.designer = this;
}

where "TheButtonWindow" is defined like follows:

Code: [Select]

    [ProgId("ButtonWindowProgId")]
    public partial class TheButtonWindow : UserControl
    {...}

So far we used EA15.2 and this code worked pretty good, although we didn't expect much, we did a "GetLastError()" which returned:

Failed to create control, error code (298)


Does anyone know what this error code means? Any ideas?

Thanks for every hint

[Geert Bellekens]

I'm not sure what the problem is you are facing.
All I can say is that for my add-ins I don't have that problem.

What I had to do was make another installer for the 64 bit edition.
That installers registers all classes for 64 bit. That might actually be the problem. That you didn't register your control class for 64 bit in your installer.

Geert

[Squeegee]

We do not use installers as we want to deliver the addins via a package manager (chocolatey). Therefore we figured out this post:
https://stackoverflow.com/questions/37193356/registering-net-com-dlls-without-admin-rights-regasm
We create a reg file following this procedure and then on bottom add the "normal" Sparx registry entries:

[HKEY_CURRENT_USER\SOFTWARE\Sparx Systems\EAAddins64\AddInName]
@="Namespace.MainClass"

So far this seems to work pretty good. What do you mean with "register all classes for 64 Bit"?

Edit: We do this crazy registry thing as then we don't need Admin rights for installation.

[Geert Bellekens]

Since you are trying to instantiate a usercontrol based on it's name, it should be registered (the system needs to know where the ddl is that defines this dll)
If you are doing that for 64 bit, it should be registered for 64 bit.

Geert

[Squeegee]

We figured it out
The hint with the registration of Control class itself was the correct one - thanks Geert!

Just to give others a idea if they read the post:

There were two problems:

1. Instead of making all classes COM visible (Project Properties --> Application --> Assembly Information --> Make assembly COM-Visible) we decided to make this explicitly in the code by adding 

Code: [Select]

[ComVisible(true)] on top of the addins main class -> Well... should've been obvious to do the same for Control Class 
2. After doing this and redoing this cracy reg-file creation and patching it, the Control class was part of the registry file --> And therefore obviously registered

And... it worked 

Many thanks for the help Geert