Ed Dickens

I guess I hadn't thought about how NI would implement it. A co-worker and I were talking about this and how we might be able to do ourselves just parsing the HTML and possibley using the picture control. A smiple HTML only web page might be doable, but with the varied compliance to the HTML standards, not to mention PHP, CGI, ASP, Java, Javascript, etc... and Microsofts version of HTML that Frontpage generates, there's just too many variables to make it fesible in our opinion. You'd think they could license an HTML engine for each platform and come up with a new control that can display everything. Sounds simple enough

I think LabVIEW should have a Web Browser Control. This would allow us to embed any web code directly on a front panel and keep the application compatible across platforms. (read that as No ActiveX needed) If there's a way to do this already, please let me know. Ed

You're right, it's not a big deal because the workaround is easy as you stated. And that is what I ended up doing. How did I run across it? I had a few charts on the panel that after the application was stopped, I wanted to turn on the captions over the chart to act like a dialog to show the status of the test. I

I

Interesting Changing either constant to a control makes it work correctly. It also works correctly in 7.0 and 6.1 with both values being constants. Ed

Greetz All, Last week, I was in on a discussion on the Developer Exchange concerning a bug in the Filter Events. The entire thread with examples can be read at the link below. Filter Event Bug Thread The basics of it is this. If you are using a filter event to modify some data, you shouldn't operate on that data in the filter event case unless you want to use the modified data. It seems that when you write to the filter event terminal on the right side of the structure, it modifies the data that gets operated on in memory even though execution highlighting, probes and front panel indicators display the unfiltered data. So using the attached example with execution highlighting on, right click on the front panel to fire the Mouse Down? event and generate a '2' for the button value. Watch the diagram and you see the left hand Button terminal generate a 2. The 2 is wired to the equal function along with a constant 2, they are compared and the Equal generates a False. An NI App Eng checked into it and has verified it as a bug. He said memory space is being shared where it shouldn't be. The workaround for now is to force the writing to the right Button terminal until after you have operated on the original value. This bug has actually been in the filter events since the event structure was released in LabVIEW 6.1 Ed Download File:post-47-1096290206.vi

The First Call? function by itself can't fire an event. You'd either have to write to a Value Signaling property node or have a Case Structure around your Event Structure to catch the First Call? value. I've used both in the past, but the Dynamic Events is much cleaner in my opinion. You end up with just a While Loop with an Event Structure and just a single VI outside the loop. Plus, if you need to run your init code again, you just need to fire the First Call user event. Ed

So the dynamic events sounded promising to me after I said it, so I made up an example of how it would work. The sub-vi on the left creates and registers the dynamic events. It also can fire the first Run event so it will run right away. The Trigger Error sub-vi watches the error cluster and will fire the error user event when ti sees one. Pushing the code into sub-vis cleaned up the diagram a lot and saves space. (until NI adds these events natively to the event structure ) I've attached the example library if your interested. Ed Download File:post-47-1094056528.llb

I think two needed events for the <This VI> Event Source are First Run, and Error Handler. The First Run could be used for any initialization code you need to do. I've faked this function by wiring a Select function to the Timeout terminal with a 0 and -1 and when the While loop iteration terninal equals 0, it passes in the 0 so it times outs right away, then on the next iteration, it passes in the -1 so it never times out. Of course, if you don't need the Timeout feature for some other reason, you'd need to add a Case structure in the Timeout event case to run different code when the loop count does not equal 0. The Error Handler event would watch a single error cluster and if it contains an error, that case would run any error handling code that have. I know all of these features can be accomplished registering a dynamic event and triggering a user event for them, but it would be nice not to have add all that extra code since these are two things that almost every application needs. Ed

The idea I had for doing this would work like this. You install the tool normally into the oldest version of LabVIEW that the tools supports. Then run the tool and it would copy all the needed files to whatever other versions of LabVIEW you specify. This would allow you to build the tools and distribute them without worrying about licensing since whoever uses it wold have to have the tools to start with. I actually did this with the older versions of the RGTK and the PID toolkits, but they do not work with the latest versions. Ed

Added ver. 3.1 of the Sound and Vibration Toolkit to the document. Ed Download File:post-14-1086360927.rtf

This seems like something that should be easy to do. I just received the latest Control Edition Developer Suite. The normal process for getting the latest versions of the toolkits installed is a real hassle. Most of them won

While checking to see if the 7.0 bug I found with this VI was fixed in 7.1, I ran across an odd behavior that wasn't there in 7.0. (That bug was fixed) When configuring the VI, if you select either Number or Boolean in the Variable Properties before typing anything the Text with Variables box, the first character you type will switch the Variable Properties back to Text. Subsequent variables entered will not change the Variable Properties back to Text. I don

I also sent this to NI support and it's a known issue that should be fixed in 7.1. The current workaround is to do what I described above. Ed

I've just run across a possible bug in the Build Text Express VI. Drop the VI and at first configure an input to accept a numeric by selecting Number under the Variables Properties section, and check the