jzoller

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.

I don

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

Only NI could do better by statically linking a scripting

language into the LabVIEW runtime. Indeed, I wonder

why NI has not done so: LabVIEW has been rather

stagnant, as a language (I'm not talking the libraries,

drivers, or development environment here), so

adding a scripting language would be a quick means

of getting with the times.

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.

Someone asked if it was possible.

Actually it was a request from info-labview where the requirements were for raw display of multiple arrays wth indeterminate sizes, with the ability to compare side by side with large data sets. Evidently screen real estate was limited and they wanted a way to move the data sets around to compare against each other. Other than that I don't know much about the usefulness of this, but I've been fooled in the past thinking that I would never use a tool until that one fateful day...

Cheers!

Joe (orko)

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.

Yes. I already reported this in LV7.0. I guess it still exists in 7.1... :thumbdown:

See my post:

http://forums.lavausergroup.org/index.php?showtopic=142

2616[/snapback]

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