exe complains of missing files even though they are included in project

[emherrma]

I am having a very strange issue with my app builder that I have never seen before. Wondering if anyone else has had any experience with it.

I have all the telnet files from vi.lib->addons->internet included (yes, I have purchased the license) in my project. And I am able to build the exe successfully.

But when I launch the exe, the vi that needs to use these files says they are missing? With the full development version, all my linkages are correct. But just not in the exe.

Somehow I cannot get these files compiled properly so that the RTE can see them.

This is my first experience with trying to build an application that has an addon in it. So maybe there are other licensing limitations? I'm totally stumped here. Any help would be appreciated. Thanks.

[ShaunR]

Are you dynamically loading the addons using a path?

If so. You should be aware that when compiled into the exe the path changes so

c:\temp\myfile.vi

becomes

c:\temp\myexecutable.exe\myfile.vi

[emherrma]

I dynamically load the vi using a path. Yes. But that works.

So I have this working

c:\temp\myexecutable.exe which dynamtically loads c:\temp\myexecutable.exe\vis\myfilewithNOtelnetvis.vi

but this does not

c:\temp\myexecutable.exe which dynamically loads c:\temp\myexecutable.exe\vis\myfilewithWITHtelnetvis.vi

I tried to copy all the tenet vis and associated files to c:\temp\myexecutable.exe\vis\support and relink to the new path. But this had a different, but similar issue.

[emherrma]

Neil,

No dice on that either. Thought that might have been it.

Is there a way to determine where the vi is trying to find the files? I see the list of files it cannot find, but no info on where its looking. I think that info would be key to determining what I am doing wrong.

[Mellroth]

I don't get it, why do you call LabVIEW add-on VIs dynamically

These VIs should/could be directly called on the Block Diagram; giving you higher performance, and less complicated code.

For me, the main reasons to call VIs dynamically is either

1. to spawn parallel processes

2. to dynamically load plug-ins

3. to break the hard link to a specific set of VIs at edit time

/J

[Mellroth]

Totally agree with 1 and 2, what do you mean by 3 though?

I should probably have said Proxies (or at least that is how I see them), so that the code I'm developing doesn't need to know where the actual code is situated.

I good example is when you call into folders that are not called by symbolic paths in LabVIEW. By putting a proxy caller under a symbolic path your code can call this code safely from any location, and if the proxy uses relative paths to the actual code it can be moved between platforms/computers/LabVIEW versions.

/J