jzoller

Something I haven't seen on this post: money. Depending on the organization, it may be the only language your boss' boss knows, speaks, or cares about. Your NI sales rep should be able to quantify benefits for you there as well. Joe Z. P.S. Orko, that was magnificent

Hi Deirdre, Played a bit with the Generic Container Maps. Interesting stuff (and I'll ask some questions when the NI board comes back for me), but... Big icons. Really, really big icons. Huge. Ginormous. ...You're getting paid off by Viewsonic to sell 36" LCD's, aren't you? :ninja: Joe Z. QUOTE(deirdre @ Aug 15 2007, 03:23 PM)

I'd sign off on that idea too...

Nice find, and a very good demonstration. I can confirm this bug for 6.0.2, 7.0, 7.1, 8.0 and 8.2.1, Some observations: -Replacing the sub-vi graph with a simple data indicator: still bugged. -Replacing the sequence loop with a case statement: still bugged. -Replacing the clusters/arrays with dbls: still bugged. -Replacing the top level sequence loop with other error primitives (flatten/unflatten) and wiring the errors: still bugged. -Replacing the sub-vi value property node with a local: bug goes away. -Routing the error wire in the top level vi around the sequence: bug goes away. -The bug doesn't appear on the first run, but does appear on subsequent runs. Ouch... Looks like a ref to the sub-vi data is being incorrectly retained where the data enters the top level sequence loop. Very nice find! Joe Z. QUOTE(Wolfram @ Aug 6 2007, 09:00 AM)

QUOTE(sm07 @ Jul 26 2007, 02:50 PM) If the global is written only in one place, and only read elsewhere, it might be acceptable. The problem with this implementation is that it limits future flexibility in the program, and programs *always* seem to grow. Bite the bullet and use a better structure. You'll learn the pattern for the structure (worthwhile in and of itself!), and never have to worry about what you (or someone else) will do in the code in the future. Joe Z.

Fantastic! #1 is just what I was looking for. Thanks! Joe Z.

Hi Eugen, I think you are correct, the Read From Text File appears to open files directly in a Read-Only mode. As you said, you can correct this by explicitly opening the file using Open/Create/Replace File with the Read/Write option enabled, then feeding the resulting refnum into the Read From Text File. Not giving the read/write mode option on the Read From Text File primitive seems kinda silly, since the function spits out a refnum. Of course, having hard-to-spot right click options on the primitive seems like a step backwards as well I guess it depends who's using the primitive. Joe Z.

QUOTE(Thang Nguyen @ Jul 19 2007, 04:30 PM) Hi Thang, You should be able to use an untyped cluster refnum to access generic cluster properties. On the front panel palette (8.2.1), drop a control refnum from the Modern, Refnum menu. Then right click on the refnum and Select VI Server Class..., Generic, GObject, Control, Cluster, Cluster. That should at least get you access to the Controls[] list of refnums in any cluster via reference. Something I don't know: is there a way to programmatically determine the original strict type on the refnum once it's been passed to the subvi? Joe Z.

Just for Friday fun... As Stephen pointed out via Darren here, an XControl embedded in a custom probe is always "running", and allows exploration of the data probed after execution finishes. If the probe is for a refnum, the XControl will keep the refnum alive even after execution finishes (as long as the probe is open). This allows modification of the data and properties in anything with a reference from within a relatively simple probe. I could see this being useful for unit or off the cuff testing, given some development. You could even build your own custom editing menus. Does anyone else have a good use for it? Of course, in combination with some rusty nails, some very strange results might be accomplished. Have a good weekend all, Joe Z.

QUOTE(jzoller @ Aug 14 2006, 06:58 AM) Fixed in LV8.2.1. http://zone.ni.com/devzone/cda/tut/p/id/5674 Bug # 40DAF67U

QUOTE(Michael_Aivaliotis @ Aug 29 2006, 10:02 PM) Apologies to Michael for interrupting... just updating. Fixed in 8.2.1. http://zone.ni.com/devzone/cda/tut/p/id/5674 Bug # 40DAF67U Joe Z.

Reported to R&D for investigation, #45EC8SVB

1. Drop a scan from string primitive on the BD. 2. Create a constant format string from the primitive. 3. Type in something useful, like "%s". The output type adapts. 4. Make the label visible on the format string constant. Change the label text, and the output types return to "dbl". Recompiling (in most forms) re-adapts the outputs to the correct types. Strange that changing the label (which is apparently largely cosmetic) changes the apparent functional output type. This problem is a bit worse in 7.1, since not all types of recompile will re-adapt the outputs. Joe Z.

Can anyone tell me if the built in profiler has any output options that can be called programmatically? I've looked around and been unsuccessful in finding where the profiler lives. While it doesn't solve most of my frustrations with the profiler, I was hoping to spruce up the interface a little bit... At least put it in a tree control or something Thank you kindly, Joe Z.

Nest a while loop in another loop structure, feed in a 2d array, autoindex the 2d array on the while loop. Pulling out a row from the right hand edge of the while loop allows you to work in place on that row in the input 2D array just inside the top level structure, not a copy of the row. Confirmed it for LV6.02, 7.1, and 8.20. NI forum post (tbd's example is much clearer than mine). JZ

If anyone has insight into this subject, I would love to see it. Lack of market? Competition with existing products (TestStand)? Licensing issues with existing scripting languages? The idea that everything in LV *must* be in G? There's a scripting package in the works? Unseen technical impossibilites? None of these seem likely enough to actually be the reason. Perhaps NI will enlighten us someday. Joe Z.

The need for moveable control objects is quite common in near-real time, large user base, highly dynamic environments (games ). The tight binding between front panel and code make it a little less common in the LV world. If you haven't seen it before, check out the example in your LabVIEW folder at examples/general/dynamicevents.llb/Dynamically Register For Events.vi for another method of moving controls while running.

Ah, should have known it was found if I had looked hard enough! It's a shame I had to waste time on this that could have been spared by a public, NI published bug list. Thank you for finding it! Next time, I'll check both the 7.0 and 7.1 lists. JZ

Not a critical bug, but it's costing me some redesign time. Maybe this can prevent others from having the same problem. Found in Win2k, LV7.1. In a multicolumn listbox, selecting many (>500) rows at one time consumes the processor and makes LV unresponsive for large (minute+) periods of time. The more rows selected, the longer the processor is consumed for. NI is aware of this issue. Steps to reproduce: 1. Start a new, blank VI. 2. Place a Multicolumn Listbox on the front panel. 3. Change the selection mode on the Multicolumn Listbox to "1 or more". 4. Fill the listbox with > 500 rows via the "ItemNames" property. (mine was 15 elements wide as well) 5. Select the first row (VI running or not, or even in exe form, does not seem to matter). 6. Scroll down to the bottom of the control. 7. Hold down shift, and select the last row. Possible workarounds: -Don't use multicolumn listboxes: this behavior was not seen under single column listboxes. -Only present a small number of rows in the listbox at a time, updating as necessary. Good luck folks, JZ