Jim Kring

QUOTE(crelf @ Nov 7 2007, 11:11 AM) What you're talking about is akin to dynamic type propagation -- we've discussed having typeless/polymorphic controls/indicators/wire before.

I've done a little bit more experimenting and found another quirk. Please see the attached sample project. Download File:post-17-1194298015.zip 1) Open the "DotNetTest.lvproj" project. 2) Note that there is nothing in the "Dependencies" node of the project. 3) Open the Front Panel of "DotNetTest.vi" 4) Note that "System" appears in the "Dependencies" node of the project. 5) Close the Front Panel of "DotNetTest.vi" 6) Note that "System" disappears from the "Dependencies" node of the project. Comments: "DotNetTest.vi" calls into the "System" .NET assembly (System.dll), which is part of the .NET framework and is in the Global Assembly Cache (C:\WINDOWS\assembly). I do not understand why this appears in the dependencies list as a VI and why it only appears in the dependencies list when the VI is in memory and disappears when the VI is not in memory. And, here's some more info:"rendezvs", "semaphor", and "systemexec" are the names of Code Interface Nodes (CIN) that are called by the Renzezvous, Semaphore, and System Exec VIs. For example, these are the names as they appear in the output of the VI Server Application method "Linker:Read Info From File". Thanks, -Jim

Update... Status: Reported to NI, CAR Number 4EUGI2HE

QUOTE(eaolson @ Oct 30 2007, 02:09 PM) > If MYVI.vi is open, you can't open myvi.vi Actually, that's not true, in this case. Since these VIs are members of seperate classes/libraries, their names are scoped/prefixed with the class name. So, it's perfectly fine to have them in memory together. They simply cannot be stored in the same folder (or inside the same LLB/EXE) on disk. This is the heart of the problem. LabVIEW starts the build process, but fails to detect that there will be a name collision on disk, during the build. The build progresses and then fails. Thanks, -Jim Update: I was just informed by someone at NI that the http://wiki.lavag.org/CAR' Number" title='LabVIEW Wiki article on CAR Number' alt='Wiki article on CAR Number' style="border-bottom: 1px dotted #3366BB; color: #3366BB; cursor:pointer; text-decoration:none;" class="wiki">CAR Number is actually 4ETCH79O -- it ends in a the letter "O" (as in Owl), not the number "0" (zero).

Update... Status: Confirmed by NI R&D, CAR Number 4ETCH790

QUOTE(Aristos Queue @ Oct 29 2007, 06:25 PM) I'm pretty sure that these are the names of the respective LLBs and that these names don't show up anywhere else in LabVIEW. QUOTE(Justin Goeres @ Oct 30 2007, 07:28 AM) ... This interests me because I've seen a dependency called systemexec in some of my projects that I can't trace to anywhere: Is it another instance of the same thing? Yes, I think so. Actually, I've got loads of similar strange dependencies. For example, I have also have a dependency called mscorlib (which no extension) which seems to come from the fact that the code is calling into the mscorlib.dll .NET DLL. And, when I'm calling other .NET DLLs, these show up as root-level dependencies with no file extension.

[status: Reported to NI] Steps to Reproduce 1) Create a project 2) Create two classes, Class1 and Class2 (these should be siblings with LabVIEW object as their parent) 3) In Class1, create a method named "MyMethod.vi" (observe case sensitivilty -- only the M's should be uppercase) 4) In Class2, create a method named "mymethod.vi" (observe case sensitivilty -- all letters should be lowercase) 5) Create a build rule for an EXE that has both "Class1.lvclass:MyMethod.vi" and "Class2.lvclass:mymethod.vi" as startup (top-level) VIs. 6) Build the EXE Observed Results The build will fail with Error 1357: "A LabVIEW file from that path already exists in memory, or exists within a project library already in memory". Expected Results No errors Analysis I believe that the algorithm that LabVIEW uses to detect and avoid VI name collisions, prior to the build, is case sensitive and not catching the fact that "MyMethod.vi" and "mymethod.vi" cannot occupy the same location on disk (on MS Windows, at least). Workaround Ensure that all methods with the same name have the same case. Example Project Download File:post-17-1193708527.zip

[status: Reported to NI] Related to the post, here, I have isolated the steps to reproduce the problem. Steps to Reproduce 1) Open a new project 2) Add a new VI to the project 3) Place "Create Rendezvous.vi" (.\vi.lib\Utility\rendezvs.llb\Create Rendezvous.vi) and "Create Semaphore.vi" (.\vi.lib\Utility\semaphor.llb\Create Semaphore.vi) on the Block Diagram of the VI. 4) Save the VI to some location on disk. 5) Close the VI's front panel (which will unload it from memory). Observed Results Two new items, "rendezvs" and "semaphor", appear in the project's "Dependencies" list. Expected Results I do not expect these new items, "rendezvs" and "semaphor", to be in the Dependencies list. They are not VIs or project libraries. Rather, they are the names of the LLB files where these two VIs are located (respectively).

I have isolated the steps to reproduce this issue and have posted a bug report, here.

[update: Confirmed by NI R&D, CAR Number 4EPEBUCS]

QUOTE(stamatios @ Oct 25 2007, 03:51 PM) Have you tried plugging in the camera?

http://www.danaher.com/news/news_detail.asp?key=287

QUOTE(LV-Vikingr @ Oct 19 2007, 09:58 AM) If you show off your LabVIEW skills (e.g., on LAVA) and let people know that your looking for work, then you'll probably get some interesting offers. Cheers,

I love technology... http://www.msnbc.msn.com/id/21307230/

When a LabVIEW file (VI, CTL, LVProj, LVClass, etc) links to a file that is located beneath a Symbolic Path, LabVIEW stores the link as a path relative to the symbolic path. However, there are several folders beneath LabVIEW, which should definitely be, but are not, symbolic paths. For example: ./resource/ ./examples/ ./help/ ./project/ I would like to make the following request of NI... Please make <labview> (or <application>) a symbolic path. Any file located beneath the LabVIEW installation root, which is not in a more specific (deeper) symbolic path, should be linked to, relative to the LabVIEW installation root. :2cents: -Jim [update: This has been sent to NI, via the Product Suggestion Center]

QUOTE(Yen @ Oct 17 2007, 02:29 PM) Lately, it seems that the LabVIEW upgrade process is just trading problems. Get some new features and bugs fixed, but have deal with the new bugs. Granted, the new features are really nice, but it's pretty frustrating working around the new bugs and "inconveniences" (like waiting several minutes for your project to close or a typedef change to propagate). :headbang:

QUOTE(Yen @ Oct 17 2007, 02:04 PM) This can take several minutes to close the Project Explorer, when you have a large project with lots of LVClasses. The more unsaved changes, the longer it takes (it even takes a long time with no unsaved changes).

QUOTE(Tomi Maila @ Oct 15 2007, 01:11 PM) Yup. Actually, I created a .bat file, but a shortcut works very nicely, too

This will be interesting to those of you who attended NI Week... Wired editor flies into security kerfuffle BTW, I learned how to use LabVIEW when I worked at Lawrence Berkeley Lab while I was in college at Berkeley.

Make sure you save your work, first, as this will kill LabVIEW. taskkill /f /im labview.exe Your mileage may vary.

Yair, Congratulations. You're such an important part of our great LabVIEW community Thanks for all your hard work. -Jim

Subversion 1.5, which is coming out soon will have native support for merge tracking between branches. This is a critical feature if you are planning on doing branched development over any sustained period. Cheers,

QUOTE(crelf @ Oct 9 2007, 04:17 PM) Unfortunately no. Not only is the project proprietary, it has over 3k VIs.

I have a project where ever time I open it, it shows as having changes. The items "rendezvs" and "semaphor" appear in the list of Dependencies, as shown below: QUOTE So, I save the project, close it, and then reopen it... the project then shows unsaved changes, but this time "rendezvs" and "semaphor" are gone. So, I save the project, close it, and then reopen it... the project then shows unsaved changes, but this time "rendezvs" and "semaphor" are back again. And so on. If I try to double-click on these VIs in the Dependencies list, nothing happens. So, what's the deal? Has anyone seen this before?