Aitor Solar

Well, the [0,1,2] array was just an example, obviously consecutive arrays can be generated easier but I was referring to any kind of array. Say you have a boolean array defining different properties of an object. You would like to generate n copies of the default configuration array for n objects in your application and treat them as a 2D array for easy comparison. Sure this woundn't be a essential modification, since is the first time I have encountered this problem in all these years, but still it would be useful in some cases. Saludos, Aitor BTW, when testing if the initialize array function admits a cluster with an array inside (it does) I have discovered that if you take a waveform constant and try to duplicate the cluster elements inside the cluster, LV crashes. Funny.

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) 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) 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) 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) 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) 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) Absolutely. That's why I reduce all LV problems to little easy chunks . QUOTE(Yuri33 @ Jan 17 2008, 05:49 PM) One more thing: the global solution above worked for every control I had except Image controls. According to the NI engineer I worked with, it seems that there is NO way (at least in LV8.2) to store a strictly typed refernce to an Image Control, or even to pass it to a subVI, which to me is really strange. Well, in LV8.5 it works fine, just like other control types . Saludos, Aitor

QUOTE(Aristos Queue @ Jan 19 2008, 11:16 PM) 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) 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) 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) 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) 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) 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