Aristos Queue

QUOTE (Neville D @ Sep 22 2008, 11:48 AM) An OS or an FPGA. LV code can be compiled and executed directly on an FPGA card if you have the LV FPGA module.

QUOTE (crelf @ Sep 22 2008, 09:35 AM) The problem with this approach is that you need to turn off "dialog font" and specify exactly some font. You don't want it to switch to whatever font the user is using on their machine because that font may not be the same size as the one you wrote your word wrap code to support.

QUOTE (normandinf @ Sep 19 2008, 07:38 PM) Get Nth Line is something I wrote to make various UI problems solvable. The problem is that it has to mimic the rendering of the text in the current font in order to figure out where word wrapping occurs. The font system is structured in the OS such that there's no way to do it except by actually rendering the font off screen (at least no other mechanism that I could puzzle out). As you observed, this means that for very large blocks of text, you'll have a slow down as if the entire file were drawn on a very large screen. Ugly. So, you'll have to do this: Pick a font. Measure the width of every character in that font in pixels. Then do your own running calculations of where the word wrapping occurs. This should be very fast. It's something that Get Nth Line cannot do because it has to work with all possible fonts. Doing your own running calculation of the word wrapping will allow you to avoid the graphics rendering. And now you know why word processors are such a pain to write and why so many end up so bloated and slow. And you know why MS Word was such an impressive app when it was released. It was able to track font runs very very quickly -- a seriously non-trivial problem, though it seems simple enough when you start on it.

QUOTE (Attila @ Sep 19 2008, 06:21 AM) I'm surprised there was any debate on this question.No. Scripting is not compiled into the runtime engine (lvrt.dll). The editor and the compiler are missing from the runtime engine. You can only do scripting -- if you have the appropriate license or have found a back door -- in the development environment. There is no secret key that will allow you to do scripting in the runtime engine. Not even NI developers can do scripting in the runtime engine. It is a feature of the full development environment only (labview.exe). Any property or method that makes a change to a VI that requires recompilation of the VI will fail in the runtime engine. Many others that require an editor environment will also fail.

QUOTE (Ton @ Sep 16 2008, 11:35 PM) Oh. Guess I'll have to go tell my boss: "Yeah, I heard from the customers. Seems they don't want it. So I'm welding this can shut again. No, I don't have a clue what LV 10.5 will do for a headline feature now, but they clearly don't want this one."

QUOTE (PJM_labview @ Sep 16 2008, 02:56 PM) I know of no way to do this in the run time engine. You'll have to hack something together by scanning the XML.

Why do you want to know the inheritance? If you're working on some sort of editor tool, there are some solutions. If you're wanting something to be part of a built application or deployed VIs, I'm likely to suggest a different architecture is going to be more efficient than any type testing we come up with (even if such facilities were easily available).

QUOTE (Gavin Burnell @ Sep 15 2008, 02:54 PM) This is correct. You're never going to get this VI to work in any case where the class and its full ancestry are not already loaded into memory. You'll have to write something that takes a path in and gives a path out.

QUOTE (PJM_labview @ Sep 15 2008, 01:53 PM) I will say this: Get LV Class Path.vi works in the run time engine. Your question about the content of that VI's a password-protected block diagram I will decline to answer.

QUOTE (Aristos Queue @ Sep 11 2008, 10:42 AM) Regarding the CAR that the wire routed under the string constant... I got an update from one of the developers who works on Diag. Clean Up:This is the expected behavior, with the default settings for auto Horizontal-Compactness. If the user moves the setting for Horizontal compactness to lowest, then the Diagram Clean Up will ensure that the wires will not go under the blocks. Quoting from the Tools>>Options dialog documentation: "Horizontal compactness—Determines how compact to make the block diagram. Higher compactness causes LabVIEW to take longer to clean up the block diagram and can cause LabVIEW to reroute wires under objects. This control is grayed out unless you select Manual tuning. LabVIEW considers labels as part of a block diagram object. " Even though this is a known issue, I am keeping this bug open because I could see that wire-routing in general is pretty bad in the given VI. The excessive bends in wires appear to be related to another known issue caused by shift registers, which we are currently working on.

QUOTE (neB @ Sep 11 2008, 10:06 AM) This has been reported as CAR 125827.

QUOTE (crelf @ Sep 10 2008, 11:10 PM) That one isn't meant to be an option, just a general modification to the algorithm that is always in play.

QUOTE (Norm Kirchner @ Sep 10 2008, 02:24 PM) Actually, it can read minds: http://www.viroadshow.com/2007/02/wheelcha...ly-by-your.html High praise and glory will be given to the user who makes Quick Drop work with the mind-reader collar. That will solve the problem of everyone talking out loud at their cubes. -------------------------------------------- The #1 Tools>>Options setting that I've heard requested is "Keep FPTerminals in conpane-relative positions". I've also heard a general request for "if a wire forks, try to run one branch completely straight and fork the other branch up or down. If you cannot run straight, then try for equidistant up and down on both branches. Only if neither of these constraints can be fulfilled should the branches be imbalanced. Only in the most extreme cases should a wire both fork and bend". See image. http://lavag.org/old_files/monthly_09_2008/post-5877-1221078512.png' target="_blank">

How far back does this bug exist? (XControls were introduced in 8.0 so you might just test that version directly.)

Justin: Did you play with any of the Tools>>Options settings that control this tool? The default setting is to compact the diagram as tight as possible. In general, all of the user written diagrams have a "looser" feel to them. Try increasing the spacing setting and see whether that improves results.

Your predictions do not align with what I've been seeing just in the first month of this tool being available. Worrying about wire alignment, keeping nodes straight, etc, is a real time sink. Yes, it becomes second nature if you work on LV long enough and get tired of messy diagrams, but it is a time consuming activity. Did you see Darren's demo in the NI Week keynote? He dropped a bunch of nodes fast using Quick Drop, didn't care about where he dropped them, wired them up (with some wires running backwards) and then hit the clean up button. I've seen a number of programmers do this. I don't know how widespread it is. I've tried using that strategy myself recently, and the results aren't too bad. It's below my standards for a clean diagram, but not by much. We shall see how this goes in the future, but it would not surprise me to see, over time, LV style end up matching what the code clean up tool creates. As layout quality improves, I think that many programmers will decide to let the tool handle the layout rather than nudging nodes pixel by pixel.

QUOTE (normandinf @ Sep 9 2008, 04:13 PM) That particular cube is for "LabVIEW Object", which is indeed built-in. But for classes in general, you should be able to add to the palette just by selecting the .lvclass file. However, this is not working in LV 8.2, 8.5 or 8.6 (it did work in LV8.2 beta, but broke for some reason in the actual release). No one noticed that until very recently. But the workaround, as has already been mentioned, is easy enough. QUOTE However, if you create a control and put the class cube in (type def or not), you can insert this wrapper control in any palette or save it to user.lib. If you want to insert the block diagram constant into the Functions palette, you can create a VI that has nothing except the constant on its diagram and then add it to the palette as a Merge VI.

QUOTE (crelf @ Aug 28 2008, 01:32 PM) I also know one particular someone who may be replacing the GEH completely in some future LV version. I've got a couple years worth of requests built up. Note: This would definitely *not* be 8.6.1, should such a bugfix release be deemed necessary, nor would it be the immediate next full LV version. But it is on the roadmap.

The presentations have been available for download for some time, but the VIs were stripped out of the presentation when they were converted to PDF for the Web. Here's the VIs... "LabVIEW Classes: The State of the Art" http://forums.ni.com/ni/board/message?boar...hread.id=353748

No.

a) Is there a reason that you need to put the version number in the file name instead of just using the version number in the Library Properties Dialog that gets recorded with the libary (or class or xcontrol)? If you copy the files on disk, you can load both the old version and the new version into memory at the same time, just not in the same project. So if you duplicate your entire hierarchy off, you can change all you want without messing with your original project. b) On the assumption that you do want to actually change the file name, let's address the project "corruption." The links between files are based on name. If you rename something without its caller knowing about that rename then of course the caller cannot find it the next time the caller loads. That's not corrupt, that's just broken. To avoid this, create a project that has all the stuff that you want to use the new name and then rename the library from inside LabVIEW. Every VI will change its reference to point to the new name. Doing the rename in isolation leads to the problems you've been experiencing.

That was great!

QUOTE (Val Brown @ Sep 3 2008, 09:07 AM) http://digital.ni.com/applications/psc.nsf/default?OpenForm' target="_blank">Product Suggestion Center

You are completely correct that merely wiring a bad file reference should not generate this error. This is the dialog that gets displayed when LV attempts something illegal or unexplainable, such as a VI jumping to an undefined memory address. It means you found a place where our compiler failed to generate valid code or the VI itself was somehow corrupted on disk. If this is repeatable, please please please post your situation on ni.com so the AEs can work with you to identify the problem and get it fixed in the next version of LV. We ought to be handling bad file reference more gracefully (ie merely returning an error code cluster).

QUOTE (neB @ Sep 1 2008, 06:44 AM) A library (.lvlib) is a collection of VIs. A class (.lvclass) is a collection of VIs dedicated to the purpose of defining a data type. An XControl (.xctl) is a collection of VIs dedicated to defining a new control. A state chart (.lvsc) is a collection of VIs dedicated to defining a state chart. Anything that is true of a library should be true of all of these types. I am not aware of any exceptions to that statement, but I can only really speak to classes. So, having said that, a VI Template that is a member of a class should work the same as a VI Template that is a member of a library. QUOTE I recently reported what I thought was a bug. A VI created from a template (where the template is a member of a class) using the Open VI >>> Invoke node run mtehod will not run if it has protected or private methods on its diagram. The invoke node returns an error and looking at the VI created from the template shows errors on the class wires. But the emplate does not have a broken run arrow. It looks like the template is being created "outise of the class Library" so its use of bundle, etc are not allowed. I worked around this issue by creating public accessor VIs and I was able to move on, BUT This bug seems to bear witness to the fact the VI itself does not know it should be part of the class library. So maybe what I reported was not a bug? This is a matter of some debate. VI Templates are not the same as Reentrant VIs. A VI Template, when instantiated, is a real, savable, editable VI, one that is disconnected from the template that spawned it. The new VI *does* become a member of the library if the library is unlocked. But allowing it to become a member of the library requires an edit to the library, which cannot happen if the library is password protected and/or locked. And a library is always locked when it is running. So most programmatic instantiations of the VI Template fail to join the library because the library itself is reserved for running at that point. Should we somehow allow templates to be instantiated such that they can still access the internals of the library that spawned them? That seems very wrong -- we would then have privileged VIs that could be saved, meaning any library that exposed a .vit would suddenly have a hole that other users could use to gain access to all the library internals. Perhaps an instantiation only has access during this launch of LV? That would mean a VI that works great unless you save and re-load it, at which point it is broken. Again, that seems strange. This is a case where I would strongly encourage investigation of reentrant VIs instead of VI Templates. Since reentrant VIs now have full front panels (as of LV8.2 I think, but it might be 8.0), the cloning of a front panel that used to require a template can now be done without one. The reentrant clones do have access privileges since they are still connected back to their original reentrant VI.