Jump to content

Aitor Solar

Members
  • Content Count

    259
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Aitor Solar

  1. 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 fun
  2. 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
  3. 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
  4. Anyway, remote panels' properties had some bugs in LV8, better try 8.2 or 8.5 if you can. Saludos, Aitor
  5. 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
  6. 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...?
  7. 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
  8. 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
  9. Search for autoindexing and shift registers, those will save you a lot of work. Saludos, Aitor
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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(Yur
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. QUOTE(crelf @ Jan 17 2008, 02:36 PM) It doesn't change to a control (and that's the correct behavior, IMHO). Saludos Aitor
  23. 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
  24. I tested the same code with an XControl of mine and it works. What's the error your exe returns? Saludos, Aitor
  25. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.