Justin Goeres

QUOTE(Ben @ Sep 7 2007, 04:08 AM) You're not http://en.wikiquote.org/wiki/The_Addams_Family' target="_blank">the only one: Girl Scout: Is this made from real lemons? Wednesday: Yes. Girl Scout: I only like all-natural foods and beverages, organically grown, with no preservatives. Are you sure they're real lemons? Pugsley: Yes. Girl Scout: I'll tell you what. I'll buy a cup if you buy a box of my delicious Girl Scout cookies. Do we have a deal? Wednesday: Are they made from real Girl Scouts?

QUOTE(Ben @ Sep 6 2007, 11:08 AM) Are you still talking about your avatar, or are you talking about that speaker system?

QUOTE(orko @ Sep 6 2007, 10:40 AM) That example will also incorrectly match the string ".0.3"

QUOTE(Sparky @ Sep 6 2007, 10:25 AM) There are actually a couple ways to do this. You can use the Match Pattern function, or you could do a full-blown PCRE with the Regular Expression function (that I love so very much). In this case, a Match Pattern is probably good enough. I think this snippet gets you most of what you want: http://forums.lavag.org/index.php?act=attach&type=post&id=6869 To break it down... ^ anchor the match to the beginning of the string (require the number to occur at the front of the string) [+-]? match the '+' or '-' character 0 or 1 times (so strings without a + or - still match) [0-9]* match any digits 0 or more times (so strings that don't have digits in front of the decimal still match) \.? match the literal decimal point ('.') 0 or 1 times (so strings that don't have the decimal at all still match) [0-9]* match any digits 0 or more times (so strings that don't have digits after the decimal still match) $ anchor the match to the end of the string (so any extra characters beyond the number cause a failed match) Now, it turns out this example is not without its problems. For instance, it will still match: An empty string (change the >=0 to a strict >0 to fix that) Various non-numeric strings like "+" or "." or "+." The second item is kind of tough to deal with, although you could run it through a pre-validation step with a regex like [0-9]? to make sure the string contains at least one digit. You could also probably handle it with a cleverly constructed regex and the full-blown Regular Expression function, but that's left as an exercise to the reader .

QUOTE(Sparky @ Sep 6 2007, 09:46 AM) This sounds like a job for http://www.regular-expressions.info/' target="_blank">Regular Expressions!

QUOTE(crelf @ Sep 6 2007, 04:40 AM) I watched all of that! Now I want to dance!

QUOTE(jaegen @ Sep 6 2007, 09:19 AM) I had exactly the same thought the first time I used the Create Accessor dialog. Typically I use the Read/Write semantics to refer to some kind of data transfer (to/from instruments, files, maybe even queues, etc.). When I'm just changing the value of a piece of private class data, I think Get/Set.

QUOTE(bpreis @ Sep 6 2007, 06:47 AM) That's a very good summary of it, yes. I've done some more work and have managed to get LV85 to generate the incorrect information in the Installer Build Spec under a much simpler set of circumstances (starting from completely a blank slate in a brand new project). I'm not certain that this is a truly minimal set of conditions to trigger the bug, but it's got to be fairly close. Summary: LabVIEW 8.5 generates incorrect Installer Build Spec XML data under the following conditions: The project has two classes, one of which is the child of the other. The parent class has a Dynamic Dispatch method which is overridden in the child class. The EXE Build Spec contains a single dynamically loaded VI (manually added to the EXE includes list). In this example, this VI is not actually used by the Main.vi -- it's just manually included in the build. The project contains a .lvlib file with one VI in it. In this example, this .lvlib does not contain any of the files actually used in the EXE or Installer. It contains one VI which is not actually used in the project (it's just in the project file). NOTE: In this test, it was the addition of this .lvlib file which first caused the bug to manifest itself. Screenshots: 1. Project Window & Main VI http://forums.lavag.org/index.php?act=attach&type=post&id=6860 2. EXE Build Spec http://forums.lavag.org/index.php?act=attach&type=post&id=6861 3. Installer Build Spec (Note that this screnshot shows the first evidence of LabVIEW's confusion.) http://forums.lavag.org/index.php?act=attach&type=post&id=6862 If we look in the Installer Build Spec section of the .lvproj file we find that there's mismatched data in the FileInfo[2] properties, and that it matches what we saw in the Installer Build Spec screenshot above: 4. .lvproj Installer Build Spec XML http://forums.lavag.org/index.php?act=attach&type=post&id=6863 Now, the interesting thing is that in the configuration above, the EXE & Installer both build OK, and the Installer also puts all the right files in the right places. However, there's clearly a mistake in the .lvproj XML for the Installer Build Spec, and in my larger project the same kind of file substitution shown above causes the installer to subsitute some files in place of others, breaking the app. It looks like on a small scale, this may be a bug that doesn't have any consequences. In more complicated builds (like my original example) it's catastrophic. Attached to this post is a ZIP file containing the project described above. It also includes incremental archives of the .lvproj as I went along step-by-step. Please note that I actually started with an external supportfile.ini file as part of the project, and several additional member VIs in Class 1.lvclass. After the bug manifested, I removed those files to see if the bug would go away -- it didn't. I don't think those additions/removals are related to what I've seen, but I'd be remiss not to mention them . Example Project File: http://forums.lavag.org/index.php?act=attach&type=post&id=6864 To bpreis -- we can continue this discussion here in the thread, or we can take it offline if you prefer. It's OK with me either way. PM me with your outside email address if you want to take it outside. Thanks!

QUOTE(Randy81 @ Sep 5 2007, 01:21 PM) This sounds (unless I'm misunderstanding) like an ideal use case for the OpenG Variant Configuration File tools: http://forums.lavag.org/index.php?act=attach&type=post&id=6856 The image shows the context help for the VI that reads(/writes) an arbitrary cluster to a file, but the VIs below that in the palette (also indicated by arrows) allow you to read(/write) values from a config file directly to/from front panel controls. EDIT: Jim did a blog post about them here.

QUOTE(jaegen @ Sep 4 2007, 12:09 PM) QFT.

QUOTE(alfa @ Sep 5 2007, 12:01 AM) There's no need to insult me or anyone else. I was just trying to understand what you were saying. And for the record, your reply didn't clear it up at all.

As part of my flailing on this problem, I decided to try to eliminate the possibility that my manual edits to the .lvproj XML were part of the problem. I started with a completely fresh EXE build spec, and a completely fresh Installer Build Spec. Without going into the hairy details of the app in question, I observed the following: The EXE Build Spec still builds the app correctly. The Installer Build Spec Source Files - Destination View window shows the constituent files from the EXE Build Spec correctly. (this is different from before) The actual Installer (Setup.exe, etc.) generated by the build spec still puts files in the wrong places on installation, and results in a broken application. But here's the interesting thing... The 2 files that the installed app (C:\Program Files\...) can't find appear to both be member VIs of classes that are part of a .lvlib file, and both have been replaced on disk by different non-VI support files that were manually included as part of the EXE Build Spec. I still can't be completely certain that my previous hand-editing of the XML isn't part of the problem, but the fact that I started by deleting the old EXE & Installer Build Specs (and verified they were gone from the .lvproj indicates against that. Note that if I manually take the missing VIs from the original EXE build output directory and place them in the correct folders of the installed application, the app launches fine. This isn't terribly surprising -- the compiled app is fine, but the Installer is just putting the wrong things in the wrong places. It's like it's somehow getting references to the wrong files when it's collecting pieces for the installer. Now if I could just bring myself to try to rig up a test project for this from scratch....

QUOTE(gmart @ Sep 4 2007, 08:08 AM) That won't work, however, if the file in question is in an auto-populating project folder -- you can't remove it individually from the project. That's the situation in my case (not the test case I posted), but in other cases your workaround would work. You're right about the file types -- it does not happen with VI files.

QUOTE(bpreis @ Sep 4 2007, 07:24 AM) I'm currently pursuing a line of thought that involves making sure this isn't caused by the manual edits I did to the .lvproj file similar to these. I'm just loathe to believe LV85 could've possibly gotten out the door with the Installer Build Spec functionality completely b0rken, and the fact is that I was screwing around in the XML of the .lvproj... I'll post again when I know more.

This issue has been confirmed with NI. I'm awaiting a CAR on it.

I'm having one of those this-has-to-be-my-fault,-right? moments. LabVIEW 8.5 is creating broken installers from the Installer Build Spec on my machine. See below. First I create an Installer Build Spec from an existing EXE (for what it's worth, the EXE builds fine). It looks like there's a graphical bug with the icons, but no big deal. http://forums.lavag.org/index.php?act=attach&type=post&id=6845 After I create the Build Spec, I click OK to return to the project window. When I reopen the Installer Build Spec the next time, the Source Files - Destination View has the WRONG FILES IN THE WRONG FOLDERS of the built application. http://forums.lavag.org/index.php?act=attach&type=post&id=6846 You might think this is just a graphical bug like I implied above, but you'd be wrong. The installer builds OK (or so it seems). I can even install the built software on a target machine without seeing any errors. However, when I try to run the software after installation, the application cannot find the constituent VIs it needs. http://forums.lavag.org/index.php?act=attach&type=post&id=6847 Furthermore, if I look in the installation directory on the disk, some class subfolders don't have the right files in them!. They have INI or CFG files (externally included to the project) or even other non-class VIs scattered throughout them, presumably in place of the VIs that should be there (that the application can't find on launch above). It seems that the problem is confined to class subfolders, although I haven't tested that rigorously. It should be noted that the project this is happening in is a few hundred VIs, maybe 15-20 LVOOP classes, and has a couple different app/installer build scripts in it. I managed to get one of the installer builds to work by doing weird voodoo like creating it from scratch and never viewing the Source Files pane after creating the build, etc. The exact same voodoo performed on this installer script didn't work. I can't imagine the Installer Build Spec is this completely FUBAR in LV85, but I'm quite sure my eyes aren't deceiving me. I have not tested this on another project file.

QUOTE(yen @ Sep 3 2007, 12:16 PM) Here's a link to http://www.microsoft.com/downloads/details.aspx?familyid=72d6aa49-787d-4118-ba5f-4f30fe913628&displaylang=en' target="_blank">Microsoft's XML Notepad 2007 download page.

QUOTE(alfa @ Sep 3 2007, 12:52 AM) I want to make sure we're talking about the same kind of prostitutes here. Do you mean prostitute as in "a woman who engages in sexual intercourse for money," OR "a person who willingly uses his or her talent or ability in a base and unworthy way, usually for money." Or both? Just trying to make sure we all understand whether you believe half the Romanian communists were having sex for money.

BAH! Jim posted over me while I was tweaking my self-reply! Oh well, I'll leave mine here because I have a screenshot I was able to get LabVIEW to remove the support file from the project by editing the XML of the .lvproj file. It's not that tricky an edit, so it may be a solution for other people, as well. Open the .lvproj file (in this case, Build Spec File Removal Bug.lvproj) in Notepad. Find the section of the XML for your build spec (e.g. <Item Name="My Application" Type="EXE">). In that section, find the lines that correspond to the file you want to remove (highlighted in yellow below). Delete those lines and save the file. When you open the Build Spec in LabVIEW the next time around, your file will have been removed from the build. http://forums.lavag.org/index.php?act=attach&type=post&id=6840 There is an item in the XML for the Build Spec which keeps a count of the total number of source files in the build. It seems that it is not necessary to update this value, nor is it necessary to edit the index numbers of the remaining files. I tested this workaround with two different support files in the build, and was able to manually remove either one (or both) by this method without any problems.

I am on WindowsXP Pro. It appears that once an "Always Included" file has been added to an EXE Build Specification in LabVIEW 8.5, it is impossible to remove that file from the Build Spec later on. This, you will note, makes it impossible to edit your EXE Build Specifications. To illustrate, the following image shows a simple project with an INI file included (the project file is attached below). Open the EXE Build Spec, and note that the file supportfile.ini has been manually included in the build. Remove the file from the build, then click OK. http://forums.lavag.org/index.php?act=attach&type=post&id=6838 Now go back to the Project Window and open the Build Spec again. Note that supportfile.ini is still included.. http://forums.lavag.org/index.php?act=attach&type=post&id=6839 The file is not referenced anywhere in the project. In this particular case, the Main.vi is actually blank, and supportfile.ini is an empty file. Note that you can still keep adding files to your Build Spec with impunity. It's like a Black Hole . Can anyone else confirm this? Does anyone have a suggested workaround? Example Project File:http://forums.lavag.org/index.php?act=attach&type=post&id=6837

QUOTE(from the linked article @ Aug 30 2007, 06:23 AM) I cannot wait for an occasion to drop that into a casual conversation. :gathering:

QUOTE(dsaunders @ Aug 30 2007, 07:55 AM) Been around the world and found That only stupid people are breeding The cretins cloning and feeding And I don't even own a TV ...

QUOTE(crelf @ Aug 29 2007, 10:49 PM) Seconded. I also mouse left-handed, so the drag-it-then-use-the-arrows method is two-handed for me.

QUOTE(Eugen Graf @ Aug 29 2007, 06:04 AM) Confirmed on my machine (LV85): http://forums.lavag.org/index.php?act=attach&type=post&id=6797''>http://forums.lavag.org/index.php?act=attach&type=post&id=6797'>http://forums.lavag.org/index.php?act=attach&type=post&id=6797 Note that the property node on the BD of VISA Configure Serial Port.vi does not immediately appear to exhibit the behavior, but if you delete the VISA resource name output wire it, in fact, has its terminal coming out the wrong way, too.

QUOTE(Eugen Graf @ Aug 29 2007, 04:01 AM) Bizarre. Does that happen with all the new Instr property nodes you drop on the block diagram, too, or just that one (and maybe copies of it)?