Labview 5.1 ActiveX have to relink all object references with Office 2003

[Hacky]

In older projects we use Labview 5.1.
Our System now is XP and Office 2003.
Some applications use ActiveX to communicate with Excel.
These were built upon Office 97.
1. Now when we try to modify one of these Vi´s containg
Excel activex properties and methods we get broken links.

in best case we have to relink all references in all Vis to resolve
the problem.

in worst case
2. There will be no Office Excel in then Application reference
even if Office 2003 is completely installed.

I can solve this Problem by using Excel.exe as Application Reference
but i assume this is dirty.

Any ideas to handle this problems efficiently?

best regards

[Joe_Guo]

No, you need to re-link the properties/methods. Micosoft make changes during each office upgrade. You'll need to re-link them.

On the other hand, I hope NI can come with a better way to handle ActiveX. It'll be much better if text based approach is used. I used some activeX controls, some of them have hundres properties and methods, it is painful to use the drop and select. Another advantage to use text based syntax is version control. For example, in Excel VBA I can write some code that checks for Excel version and call different methods or properties. It is impossible to in labview because labview retrievs these information base on the reference. Hence, you'll have to build the same application for Excel 97, 2000, 2002(xp), and 2003.

-Joe

[shoneill]

The possibility to use text mode for ActiveX is on the NI wishlist since last year (I put it there). I share your pain, and doing something even trivial takes up immense amounts of screen realestate it's ridiculous.

OK, I'm finished ranting now.

Shane.

[Joe_Guo]

is it possible to add another vote to this wish item on NI's site? If so, what's the address?

-Joe

[Lycangeek]

Sorry to play the newbie but I am trying to get a better understanding of the problems you are talking about.

So when you say a "text based" approach, what exactly do you mean? Could you describe it?

I am also not sure I understand exactly what you mean about the Office version change. We store the GUID of the ActiveX control and so will load in the same version. It would be possible to use the ProgID instead but (a) it isn't required for COM objects to have a ProgID and (b) it breaks the compatibility goal by possibly creating an instance that doesn't support the same COM contracts as the previous one (you can map the ProgId to any CoClass GUID). Help me understand the usage you would want in these cases.

The version based code you mentioned is an interesting puzzle. Our goal is to maintain the polymorphic nature of LV by having the type information (in this case the ActiveX refnum) propagate along the wire and have the node adapt dynamically. You would basically want something like a case structure where the case is selected by the refnum (GUID inside)?

In the .NET side of things, we have put in more dynamic adaptation to changes in the system (version changes in the .NET assemblies) - but we can do that due to .NET's versions and rules of the Fusion system (the .NET code that locates assemblies). In ActiveX it isn't quite as easy, but I want to understand what we could do better.

Message Edited by Lycangeek on 03-31-2005 11:30 AM

[Joe_Guo]

I don't know too much about .Net so I will comment on the ActiveX part only.

Let me explain the version part first. In Excel 97 and 2000, the Open method uses different parameters. Because labview obtains the methods / properties based on the input reference, it can display only one version of the Open command. The application need to be modified for each Excel version.

The text based approach is similar to the formula node in which you can type in the codes and variables.

One of the feature or in-efficiency of the ActiveX implementation in Labview is assigning properties values. It is ok if only few properties are needed, however, some activeX controls implement hundreds of properties or methods. If I need to assign 20 properties, I need to scroll a list and find the properties I need, a lot of times I want remove or add a different property, then again I need to scroll the list and find the needed one. On the other hand in a text based language, say VB, I can type the properties I want, assign values and make changes quickly. I can write a function far faster than in Labview.

Another benefit of using text based approach is version check. Use Excel as an example, I can use the method "App.version" to check the Excel version and use different methods or properties accordingly. By doing this, multiple Excel version can be supported in the same application without re-compiling or re-linking.

Hope this clear things up.

-Joe

[Lycangeek]

Yes, that does make sense.

I know that, like VBA, it runs against the grain of a strongly typed language (such as LV), but I can see the issue you are having. I'm starting a discussion regarding this here in engineering but please don't take this as a commitment to anything - I can't say whether we will be able to address it or not.

But keep letting us know where you have trouble using LabVIEW - we really do listen.

[Joe_Guo]

Thanks, Brian. I have more wish items for labview. Here are only few, I really appreciate it if you can direct to me the wish list website.

- application builder, allow me to remove any files in the installer (installer >> advanced), not just the files I added. Labview automatically includes all required external files (dlls) but sometimes I'd like to remove some of the files.

- drag n drop files from explorer to labview during runtime.

- silent installation. every time I upgrade labview or install labview on a new computer, it takes several hours to install all the required toolkits, etc. I'd like to see a installer which grabs all the installation files under a directory (each toolkit is a subdirectory) and install them in order.

- resizable probes

etc ..

- joe

[Lycangeek]

Do you mean this? http://digital.ni.com/public.nsf/websearch/d2db2f7cbdf025488625687b00020f66?opendocument