Error 1003 when compiling...

[m3nth]

Using LabVIEW 7.1 with the Application Builder...

When building a particular VI, I get Error 1003 ("The VI is not executable"). The VI will execute when opened normally. The option that seems to cause the error is having the box checked that says, "Disconnect type definitions and remove unused polymorphic VI instance". When the box is not checked, the VI will compile.

The VI in question uses both ActiveX methods for Microsoft Excel, and GOOP (I would imagine one of those is to blame).

The problem is that I have isolated this small VI, but it is really part of a huge application which--I haven't tested this to find out but... I would imagine will be even more bloated if extra uneccessary code is added. If I can't compile this one little VI with that option checked, then everything else won't compile either, so it will have to remain unchecked when compiling the very large application (hence the issue).

I can upload the VI in question if anyone wants to look at it.

[tst]

Try force compiling the VI (ctrl+shift+run).
If this works as I expect it to, the VI will become broken and you can find the source of the problem.
This has worked for me in the past, but I wasn't using GOOP or ActiveX, so I'm not sure it will help.

[m3nth]

Excellent suggestion. Just what exactly is "force compiling"?--I can't find documentation for it.

Now that my VI breaks I just need to figure out why, which I have a feeling might be a headscratcher. Thanks for the info.

[Joe_Guo]

re-select the Excel properties and methods you used in the problem vi. save and compile.

-Joe

[m3nth]

Yeah that's definitely the problem. Actually I have a larger problem than that, but that's the immediate problem.

The immediate problem is that I don't have the right ActiveX properties and methods registered on my machine for the code to run right. The larger problem is that the machine I'm targeting _does_, but I can't compile for it on my machine. *sigh*

This problem is talked about elsewhere, but is the result of Microsoft upgrading the ActiveX interface for more recent versions of Office.

[Joe_Guo]

what are the excel versions on your development and target machines? Sometimes you can build an application with a lower Excel version and it still work with the newer version of Excel.

-Joe

[tst]

---

Just what exactly is "force compiling"?

---

Usually, LV does the compiling OK (I think whenever you run and whenever you save, but I'm not sure. Does anyone know?), but, to do it efficiently, it only compiles changed parts, whereas the app builder compiles everything (which is why it takes longer to build an EXE than to run a VI. Think what it would be like if every time you load your VI, it will take the same amount of time as building an app...). Sometimes, something goes wrong and LV misses a change. When you force compile, LV compiles all the VIs, like the app builder does, and you find the error.

Message Edited by tst on 03-16-2005 10:46 PM

[Joe_Guo]

when I use labview and Excel. I use labview to extract, compute and send data to Excel. All the formatting is done in Excel VBA code. In the code I can then check the target Excel version and prepare the formatting accordingly.

-Joe

[m3nth]

---

@Joe Guo wrote:
what are the excel versions on your development and target machines? Sometimes you can build an application with a lower Excel version and it still work with the newer version of Excel.

-Joe

---

I am developing on a PC with Excel '97 and targeting a PC with Excel '03. When I first ported my code to the Office '03 machine, the ActiveX methods/properties broke that were different so I modified them to make them work on the '03 machine. Since it was just the code in one .llb file, I maintained independent versions of that .llb--one on my machine, one on the Office '03 machine.

The complications are that:
- The Office '03 machine is not local to me
- The Office '03 machine has all the hardware on it and obviously a much newer version of Office
- The Office '03 machine is not typically used for development
- My development PC can't have Excel '97 and '03 installed at the same time
- A third '97 PC is also involved in building the application since our Software Configuration Management department has to independently verify the build.

Ideally, I'd like to be able to drop in the Excel '03 .llb file I use and force it to build the application installation package regardless of whether or not the ActiveX component for Excel '03 is registered on my system--it will be registered on the target system, which is what's important. I talked with NI about this to submit a notice to R&D.

The other thing I am currently looking at is figuring out if I can temporarily unregister the '97 ActiveX components and register the '03 components on a PC so that LabVIEW won't break when it loads the '03 version of the .llb file. I don't have much experience in that department, which would apparently involve the RegSvr32 app.

[m3nth]

---

@Joe Guo wrote:
when I use labview and Excel. I use labview to extract, compute and send data to Excel. All the formatting is done in Excel VBA code. In the code I can then check the target Excel version and prepare the formatting accordingly.

-Joe

---

That's interesting... do you have the VBA code run automatically when the user loads the worksheet in Excel?

When you say "In the code I can then check the target Excel version"--you mean in the VBA code correct?

While the typical use for Excel is probably to export data, I am actually using it to import configuration data since it happens to make importing columnated tables really simple. You can make them look like whatever you want also since the input functions will read all the text and ignore the formatting... makes for a good user interface.