Jump to content

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


Recommended Posts

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.

post-28044-0-43232700-1351265329_thumb.j

Link to comment

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.

Link to comment

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.

Link to comment

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

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

  • Like 1
Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.