Using Automation objects - Late Binding

gurleen

Hi,

There are a number of posts on using Automation objects but no one discusses if there is a way to dynamically bind a variable to the Automation object.

By default it looks like when we create an Automation Object , the variable binds itself to the GUID of the Automation Object. So if I want to use "Windows Script Host Object Model" , my variable will be bound to the GUID for the current version of the "Windows Script Host Object Model" class. The problem arises when the end user has a different version of the Automation Object( like a different OS version). In this case the C/AL code will not recognise the Automation object and throw an error.

Is there a way to have late binding ( i.e. the variable binds itself to the name of the automation object rathen than the GUID) ?


Thanks

kriki

No, I don't think it is possible.
But it is strange, because I also use some automation for Outlook. I created it with an older version of Outlook and now I have a newer version. The subtype of my variable shows "Unknown Automation Server.Application" but the C/AL compiles and works fine.

gurleen

Hi,
Are you still on the same machine?
If you are on the same machine then the GUID for the older version may still in the registry pointing to the older DLL.

Have you tried to run the application on a different machine that does not have the older DLL ?
***********************************************************


What I want to do is to get a value from registry. I can use the "Windows Script Host Object Model" to get the value from the registry. My development environment is Win XP and I am afraid that if the end customer uses any other OS the code might crash? Do you think I should be OK with using "Windows Script Host Object Model”?

Another approach I can take is to create my own DLL in C# and give it a permanent GUID but then I am unnecessarily introducing a DLL just for getting one value out of the registry.

Thanks

Miklos_Hollender

I think you should actually test it on different machines, because I heard the rumour that on end-user machines it automatically can handle DLL's of lower (although not higher) version numbers than on your development box, although I'm not sure.