Justin Goeres

QUOTE(Sparky @ Sep 6 2007, 10:25 AM)

I have not used the 'regular expressions' VI. It looks like that might do the trick. Thanks you very much!

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)

Does anyone know of a string VI that checks a string to see if it is a valid decimal number before sending the string to a convert VI? The string could have one of 4 possibilities for the first character (+, -, Number, Decimal Pt.), and can then have either numbers or a decimal pt. after. It must not have more than one decimal Pt., or Plus/Minus sign. Just thought I would check before I start doing my own. I am using LV 8.2. It would be nice if the string to number conversions had some error output.

This sounds like a job for http://www.regular-expressions.info/' target="_blank">Regular Expressions!

QUOTE(crelf @ Sep 6 2007, 04:40 AM)

Here's where the back-up dancers learned their craft:

I watched all of that! Now I want to dance!

QUOTE(jaegen @ Sep 6 2007, 09:19 AM)

The Create Accessor dialog automatically uses "Read" and "Write" in the VI names - is there any way to make this default to "Get" and "Set" instead?

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)

So if I understand everything,

• You started with an exe build spec, which builds correctly.
  
• Your first pass through the installer builder lets you add files on the source files page, but the icons are all wrong in the project view, while the files all look correct on the destination view.
  
• After closing and reopening the build spec, the source file page has deteriorated further - icons are still messed up in the project view and the destination view now has completely wrong file information
  
• After all this, the installer builds fine and installs fine, but there are files the exe cannot find that happen to belong to classes (and an lvlib?)
  

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)

I'm currently trying to write a configuration dialog for a program of mine. I have a config.ini file and I would like to read the file and load the configuration information into the controls on my front panel. I was thinking of having some kind of table which identifies a configuration key and its corresponding control label. In which case, I would search my front panel display and set the control value using a property node. This seems very inflexible, but it's the best idea I have so far. Any suggestions?

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)

I'll add a "me too". When I wrote the CLAD exam it was on paper - I probably spent more time adding comments to the wording of the questions than actually answering them.

QFT.

QUOTE(alfa @ Sep 5 2007, 12:01 AM)

Looks like low level people (98%) are waiting for a new book:

Prostitution for dummies

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)

One thing you could do is remove the problem file from the project. When you load the build specification again, it will not be present. This is not ideal, but it should get you going without having to manually edit the project file. Also, it seems the problem only affects non-VI files. If you have the same setup with a VI, you will not get the same behavior.

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)

That looks like a pretty major problem. Do you have some code you'd be willing to share - perhaps not the entire project but enough to reproduce what you've seen? Thanks.

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)

By the way, for those working with XML, I would suggest checking out XML Notepad (from Microsoft, I think). It makes dealing with certain aspects of XML very easy, although I wouldn't be surprised if there were more powerful XML viewers\editors around.

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)

Any dictator needs a lot of prostitutes. Low level people want to be part of any system.

My view is: More democracy means less prostitution.

In Romania were more than 4 millions in the communist party, more than 2 millions had prostitute certificate…

I want to make sure we're talking about the same kind of prostitutes here.

Do you mean prostitute as in

1. "a woman who engages in sexual intercourse for money," OR
   
2. "a person who willingly uses his or her talent or ability in a base and unworthy way, usually for money."
   
3. 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 am not here to play laughing homosexuals with you".

I cannot wait for an occasion to drop that into a casual conversation. :gathering:

QUOTE(dsaunders @ Aug 30 2007, 07:55 AM)

So are we at 99.92% now?

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)

I have it on, but I don't snap to it. I do use the alignment tools, but I'm old fashioned, and can move a FP node around with the arrow keys pretty damn quickly.

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)

If you open the BD of the VISA Configure Serial Port.vi and copy the Property node inside them to your BD, then you will get this comic behaviour.

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)

Yes, you are right. But why this auto-wiring problem?

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)?

I use a .NET Invoke node as follows:

http://forums.lavag.org/index.php?act=attach&type=post&id=6785

Obviously this is Windows-only, and it requires the .NET Framework to be installed on the host machine.

QUOTE(alfa @ Aug 27 2007, 11:47 PM)

We apply differential geometry on body's car but not on our face for example. Our look is the reflection of our mind, thoughts...

For example are people who are lying a lot like politicians, informants...Because each lie do an infinitesimal, small change on theirs face after a while they 'look' like liars....(the prostitutes are after me).

If you believe that the prostitutes are after you (they are not), it leads me to question your ability to reliably detect these http://en.wikipedia.org/wiki/Microexpression' target="_blank">microexpressions. What is it that makes you concerned that the prostitutes are after you?

QUOTE(robijn @ Aug 27 2007, 12:11 PM)

I have always disliked the way objects are presented as "the solution for everything".

Do you mean that NI presents LVOOP this way, or that OO in general (in other contexts/languages) is presented this way?

I, for one, don't think NI is guilty of that.