"Strings and Value[]"-Array

[ichsw]

Hi everybody,

I have a problem with a ring-control in my labview program.

The ring has many items (65536) and non-sequential values.

I need to find the actual index of the ring array and set a new calculated index afterwards.

As I couldn't find a way to get the actual index directly, I started a for loop and compared every "Strings[]"-array element with the "Ringtext.Text"-property. So far, so good.

But when I want to set a new index to the ring, I need to use the "Set Value"-property.

Here comes the problem: Every time I use the "String and Value[]"-property to get the index corresponding value, labview needs about 10 seconds to build it. Why is that? Labview doesn't have problems building the "Strings[]"-Array.

Is there a way to handle the ring index seperatly I couldn't find?

Can the "Strings and Values[]" operation be accelerated?

Thank you for your time and your ideas.

Best,

ichsw

[Mellroth]

  On 11/14/2012 at 12:29 PM, ichsw said:

...The ring has many items (65536) and non-sequential values...

...labview needs about 10 seconds to build it. Why is that?...

I think you really should consider another approach; the Ring control is a UI element, and is not intended for data storage.

Without knowing the exact layout of your system, I would recommend that you use a LV2 global or something similar to hold your values instead.

/J

[ichsw]

Got you...I know about the seperation of data and view (mvc) in object oriented programming. But I thought labview does this itself with the controls and indicators. When I use the LV2 solution, I have to synchronize the gui and the data elements all the time, right?

I think, it's a good idea to describe why I need the index handling. Maybe you can suggest an approach that doesn't use the ring arrays.

I want to change the standard behavior of a ring, so it can be incremented/decremented with the up/down-keys and does not overflow and underflow. Therefor I have to filter the key event and check if the increment/decrement is allowed.

Remeber that the values are non-sequential.

I figure it's not a good idea to change the behavior of a standard labview element, but I really need to implement this function.

What about creating a whole new control? Does anyone has experience with that?

Any ideas welcome.

Best,

ichsw

[asbo]

Yes, you would have to synchronize your LV2 with your FP control/indicator. Likely the biggest slowdown you're facing is that operating on controls/indicators can only work in the UI thread, while most code can work (often in parallel) in various other threads.

I vaguely recall someone posting about doing something like that before; at least related to not wrapping. An XControl would provide the encapsulation you need, I think, but XControls are not necessarily for the faint of heart.

Are the value non-sequential AND non-contiguous, or just non-sequential? If it's the former, play with values in the unassigned spaces between values and see how it handles coercion.

neil does beg a good question, however - seems like an awful lot to dig through for a user. Maybe it could be broken down into three or four separate rings and selected in stages (e.g., the Add A Vehicle pane on advanceautoparts.com)

[Mellroth]

Like Neil and asbo already explained, it was the usability of a 65000 element Ring control that bothered me the most.

I really thought you just used the ring control to have an easy lookup between non sequential values.

Some ideas if you still want the user to go through all these key presses;

* Put your sting-value pairs in an array of clusters, and keep track of the current index. When user presses the Up/Down Keys, move index accordingly and update UI

* create an xControl and store the string-values array within the xControl data

If possible, I really think you should post an example showing how this should work.

Question; do you want to be able to find a specific value given a string, or do you want to get the string that is associated with a given value.

/J

PS. The thread I believe asbo is relating to is this;

http://lavag.org/top...8757#entry98757

This deals with preventing roll-over from min to max or vice versa.

[ichsw]

Thank you everybody for your help...

...but I don't have time to experiment any further because of that "little" feature.

I would have tried the xControl approach to implement my own control behavior, but I don't use the professional version of labview.

In general I would prefer a seperation of data and view, but it's too much work to change the main concept of the program I was ordered to adapt.

That's my solution:

I used the "Strings and Values[]"-property with every ring that doesn't have too much elements.

For the critical rings I build my own "Values[]"-array once at the beginning of the program. With the help of the "Strings[]"-property I can search the index and with the generated "Value[]"-array I can get the corresponding value.

Not nice, but it works.

Thank you for your time, again.

Best,

ichsw

[Aristos Queue]

When LV builds just the string array, you get the copy of the array stored by the ring control itself -- no copy is made unless/until you modify the array downstream. Since you are only searching the array, no copy gets made, so it seems fast. When you ask for the array of strings and values, we have to build you a whole new data structure including copying each individual string so that the new data structure is independent of the one in the ring (that's how dataflow works; it is not a bug or something for LV to fix someday). So you see a massive penalty hit.

You can maintain this data structure yourself, as various people have pointed out, in diagram local storage, like a shift register on your event loop (I wouldn't use an LV2-style global unless you really need this information elsewhere in your program and not just on the local diagram). Then, yes, when you make a change to one data structure, you make the same change to the other data structure.