Jump to content

Aitor Solar

Members
  • Content Count

    259
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Aitor Solar


  1. 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


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

    post-1450-1209563163.jpg?width=400

    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...? :o

    post-1450-1209566472.jpg?width=400


  3. 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 :wacko: .

    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


  4. 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


  5. 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


  6. 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. :unsure:

    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


  7. 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


  8. 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


  9. 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


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

    Apologies. I should've put a :P 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


  11. 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


  12. 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

×
×
  • Create New...

Important Information

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