Aitor Solar

In the wake of JFM words, I wonder if the conditional break affects the for loop performance. NI, in several documents (for example VI Memory Usage) says:

"If you want to add a value to the array with every iteration of the loop, you can see the best performance by using auto-indexing on the edge of a loop. With For Loops, the VI can predetermine the size of the array (based on the value wired to N), and resize the buffer only once."

Now, does adding the conditional break forces LV to resize the buffer, with the added memory allocation? That could be something to keep in mind when using this feature.

Saludos,

Aitor

I find surprising that the Initialize Array function doesn't allow for an array input. It would be really helpful for creating multidimensional arrays where not all elements are the same.

Of course the same can be done with a for loop, but doesn't feel so clean.

Saludos,

Aitor

Anyway, remote panels' properties had some bugs in LV8, better try 8.2 or 8.5 if you can.

Saludos,

Aitor

Maybe the plugin is loading a shared lvlib (I mean shared with other plugins) that has some original elements removed, so when the other ones get loaded... collision. This message from Kennon explains it perfectly:

http://forums.lavag.org/index.php?s=&s...ost&p=12494

Saludos,

Aitor

The "Get Conpane Image" method also provides the help image for the VI.

BTW, the Coerce To Type function seems a conversion tool, probably unfinished. The description says: "Coerce the input to become the datatype associated with type and returns the results at the output terminal". Here you have a VI with the node.

Download File:post-1450-1209563170.vi

Saludos,

Aitor

Umm, is that a skull in the decompose and recompose icons...?

QUOTE(Yen @ Mar 7 2008, 10:52 AM)

Hmm...

Nothing there now, it just returns an error.

It was there, here is the readme listing the bug fixes.

http://lavag.org/old_files/post-1450-1204891492.html'>Download File:post-1450-1204891492.html

Saludos,

Aitor

I have a similar problem. We designed an application for a dual monitor system, both of them 17". Now, we have to install in another system whose second screen is just 8", and the UI must be useful in both screens .

The easiest solution I've found (since a heavy redesign of the UI or the main code is out of question) is to show a reduced image of the FP when the screen is to small to show the actual FP, using the Get Image Scaled method for it. A simple loop gets the image updated. Of course, this way the user can't operate in the small panel, just see it, but is an acceptable drawback since the screen is to small to work with it, anyhow, and he can always move it to the main screen (in that case, the actual FP is shown).

Saludos,

Aitor

Search for autoindexing and shift registers, those will save you a lot of work.

Saludos,

Aitor

QUOTE(guruthilak@yahoo.com @ Feb 11 2008, 12:32 PM)

this piece works very well when i just a have a vi with a case structure with only 2 frame names (True and false) . When i put it in to the application which i have developed (which is having more than 100 states in a state machine) it does not work. It throws the error as "Invalid object reference" or someything similar to that

I haven't found any problem, but didn't try so many cases.

The error is thrown in the "Open VI Object Reference" node, isn't it? Is it possible the frames are located inside another structure, and so the fuction can't find them?

Saludos,

Aitor

Mmm, not sure what you are asking, but:

1) The method to try a password on a VI has a built-in delay to make it unusable for brute force crack.

2) That method doesn't work in the runtime environment (exe files).

Saludos,

Aitor

If you use events, you could set the timeout event to get fired after the desired time of inactivity. Else, you can implement a while loop that checks the amount of time elapsed. Add a queue or notifier to inform this loop it must reset the count when another control has been pressed, etc.

Saludos,

Aitor

QUOTE(rolfk @ Feb 1 2008, 08:51 AM)

Well, I see. It still might be a problem in the future, or the refusal to typecast to a strict typedefed VI refnum is maybe a bug?? Na, I don't think so.

Neither do I, it's done on purpose because the "to more specific class" function doesn't admit a strict VI refnum either. So it seems NI doesn't want us to modify the type of the VI refnum, probably because it's error prone or just because the Call-by-Reference function needs the VI to be reserved, etc.

Anyway, I would prefer the type cast to try anything I connect, even if is not recommended.

Saludos,

Aitor

QUOTE(rolfk @ Jan 29 2008, 07:21 PM)

It works in LabVIEW up to 8.2.1 but fails in LabVIEW 8.5. The typecast function will refuse a refnum connected to it with a broken wire.

I don't think so. In LV8.5 the type cast won't accept a strict VI refnum as the type definition, true, but we are talking about control references and those work well, also in 8.5.

Saludos,

Aitor

QUOTE(Yuri33 @ Jan 28 2008, 11:28 PM)

Is this confirmed to work? You can simply typecast a generic control reference to a strictly typed reference? Will this work at run-time (in LV8.2)?. I would love to change my application back to the way I originally had it (and slay the last global!), but I don't want to put the time in if I'm going to run into the error again at run-time.

Yes, I have tested it in LV8.2 both in the development environment (both methods work) and in a compiled exe (only the typecast method works). But anyway, don't trust my word, better test it with a simple example that includes your specific XControl and compile it.

Saludos,

Aitor

NI has solved the problem (again). In the "to more specific class" don't make the target class strict (so, don't use a reference to the XControl in the FP, but a class specifier constant to the XControl class). Anyway, it seems to me this is still a bug in the runtime engine, though a workaroundable one, either using non-strict references and converting variants to the correct value type, or using a "type cast" to the strict reference instead a "to more specific".

QUOTE(Tomi Maila @ Jan 21 2008, 12:03 AM)

Does this mean you are not interested in complex LabVIEW problems either?

Absolutely. That's why I reduce all LV problems to little easy chunks .

QUOTE(Yuri33 @ Jan 17 2008, 05:49 PM)

Well, in LV8.5 it works fine, just like other control types .

Saludos,

Aitor

QUOTE(Aristos Queue @ Jan 19 2008, 11:16 PM)

Apologies. I should've put a on that. No one but the most lawyeristic among us reads shrinkwrap licenses, even though we all probably should so we'd know what we could and could not do with our softare. It's something I've complained about more than once on LAVA, the complexity of knowing what rights we have with VIs or any other IP generated from any piece of software.

All right, then . And you are correct, licenses are complex and that's why I prefer not to get messed with them. Anyway, about the original question, I handed the code over to NI Spain to see if they find the same behavior.

Saludos,

Aitor

QUOTE(Aristos Queue @ Jan 19 2008, 04:12 AM)

I don't know the answer to that question but you should ... don't you read your shrinkwrap license agreements?

No, not really, I just work with the software determined for each project, licenses are held by another person. BTW, why do you feel obliged to tell me what should I know? It sounds rude, IMHO.

Saludos,

Aitor

QUOTE(crelf @ Jan 17 2008, 09:55 PM)

I know that (you said it in a preivous post): I wanted you to put it here too so that everything to do with your question resides here on LAVA, so that, in future versions of LabVIEW when that xcontrol might be gone, the thread doesn't date. It's not a big deal, so don't worry about it if you don't want to.

Oh, well, but that code belongs to NI, isn't it? Can we post VIs that ship with LV?

Saludos,

Aitor

QUOTE(crelf @ Jan 17 2008, 05:37 PM)

I meant include the xcontrol too.

That XControl is provided with LV, it's located in examples/general (look for something like Dual Thermometer).

Saludos,

Aitor

QUOTE(crelf @ Jan 17 2008, 03:40 PM)

Can you please post the code so we have it here for future reference?

Sure, but it's just the code I posted. Run the VI, the boolean goes to true. Compile it and execute, the boolean will remain false no matter the mode the XControl is (Farenheit or Celsius).

It seems a bug, I'll talk with NI about it.

Saludos,

Aitor

QUOTE(crelf @ Jan 17 2008, 02:36 PM)

Intriguing - is anyone with 8.5 able to try it? I've attached an 8.2 example VI.

It doesn't change to a control (and that's the correct behavior, IMHO).

Saludos

Aitor

Now, though I don't get an error I've found this code fails to read a property when compiled. I have prepared a simple example using the Dual Mode Thermometer that ships with LV, as shown in the capture. This works as a VI, but fails in an EXE (it never returns True).

Saludos,

Aitor

I tested the same code with an XControl of mine and it works. What's the error your exe returns?

Saludos,

Aitor

Maybe I'm missing something, but it wouldn't be much simpler just to chek if the new value is "true" and then do nothing?

Saludos,

Aitor

You can close the FP with an explicit reference to itself, that way wou won't be prompted. I mean:

Hope that helps.

Saludos,

Aitor