Leaderboard

Hi yesterday I noticed an f2 patch for LabVIEW 2010, just thought I'd post it here as nobody else has LabVIEW 2010 patch f2 Details

I have created a new example along the same lines. Instead of fading in, this example overlays a transparent VI on the caller. If the caller does not have an open panel, then it moves up the hierarchy until it finds an open panel and overlays that one. The image is a simple animated gif that spins, showing a time consuming operation is running. I hope this is useful in your UI designs. Download File:post-2411-1241482449.zip -John

Hi all, I just created a new version of Framework "GKY-Paralellism-3Loops V1.0"and want to share with friends here(see attachment) I am not so satisfied with 2 thing in this version: 1) the exit of 3 Loops. when a error happened in one loop, only after user triger a event, the application can exit. I plan to use event to avoid this in next version, but I also want get suggestions about EXIT LOOPS from here. 2) Error handling Loop was not added in this version, cause until now I haven't got good idea about how to handling errors in the Error loop, maybe someone can add this loop so that we can complete the framework together. enjoy and waiting for suggestions! GKY-Paralellism-3Loops-V1.0.zip

I have tried to open the VI in LabVIEW 2010 running with patch f2 and I get the same error, I suggest you raise a CAR with NI that the problem still exists in 2010 and patch f2 Dannyt

Hi Durnek60 There is a similar thread here by Martin too. Cheers -JG

Depending what your end goal is, you can also try these other suggestions:

If you set fit control to pane on the tab control, then only the tab control will resize. Not the contents. One possible solution is to programmatically resize the Image Display control based on the size of the tab control. You would have to put this code in a parallel loop so it always runs and feels smooth to the user.

Hi Techie Attached is a template example I use for teaching, it is taken from NI course example. It may not be the best, but is an implementation that may get you started? Cheers -JG Error Module Top Level VI Example Code Producer Consumer Events Error Display.zip

Hi Farid, here is some code to do it: Image copyright David Vignoni, www.icon-king.com Symbol.vi

Christina tweeted about these cool new DAQmx System Controls that SimonH has exposed in a palette. I really like these - so I have repackaged them so that they can be installed easily using VIPM. Thanks Simon! LabVIEW 8.5+ required. Enjoy! -JG jgcode_rpk_ni_system_style_daqmx_controls-1.0-1.ogp

Since Win2K I have been adding following to application ini files to "fix" my fonts. These match what I have set development environment to use for fonts. MyApplication.ini [MyApplication] FPFont="Arial 14" appFont="Arial 14" dialogFont="Arial 14" systemFont="Arial 14" BDFont="Arial 14" Default Windows System Font. NT4 - MS Sans Serif 2K/XP - Tahoma Vista/7 - Segoe UI

It is a philosophy question, and I doubt there is a right answer. "Favor composition over inheritance" is a battle cry I have heard a lot over the last few years. Composition means I can "plug in" functionality from lots of sources. The trouble, as I see it, is that you end up writing a lot of wrapper functions in order than the outer object can expose the inner objects' APIs as its own. Now, the theory is that the inner object's API can change completely and as long as the new API can still support the old functionality, the outer API doesn't have to change -- you change the implementation of those wrappers, not the outer API. But what I observe is that it is rare to want to change the inner API and not change the outer one. Perhaps you're adding a new option, or you're breaking one atomic function into several individual parts. There's usually a reason you're doing that, and it is rare -- in my experience -- that the reason you're doing it is just so you can have a better internal API. Changes to deeper layer APIs are almost always driven by top-level demands for features. Or, to put it another way, it is rare that the core decides, "I'm going to change how I do things because it will be better." It is much more common for the outermost layer to say, "I need to serve the user differently... but I can't do that unless the core exposes some new functionality." Given that the desire for a new API is almost always driven by the layer closest to the user, when the core changes, the outer layer will want to change anyway, so if there's a tight binding (inheritance) between core and outer layer, so what? Not having that binding doesn't generally seem to save you. Sure you *could* avoid rewriting the outer layer when the core changes, but if the whole point of changing the core is so you *can* rewrite the outer, then you're going to rewrite the outer. Yes, I spend a lot of time changing inheritance trees around -- introducing new middle layer classes, wiping them out again a couple revisions later. I've got one tree of classes I'm working on at the moment where each layer of inheritance is adding one function, and one "concrete" class forking off of the trunk at each level. As I revise each of the concrete classes, they're sliding down the tree, gaining functionality, and I'll probably collapse a lot of the middle layers eventually. I find that the chain of inheritance is useful for navigating my code and I don't see a major drawback to refactoring the tree. Very few classes are persisted to disk, so that's rarely an issue, and in LV, the mutation logic built into the language generally handles everything I need it to.

Daklu, the style of my writing below is fairly terse and occassionally EMPHATIC. I've done this to emphasize key points that I think you've missed in How Things Work. Some customers in the past have felt I'm insulting them writing this way, but it is the only way I know through the limited text medium to highlight the key points. My only other option is to post just the key bits and leave out a lot of the exposition, but that doesn't seem to be as helpful when communicating. So, please, don't think I'm calling you dumb or being disdainful. I'm trying to teach. The problem is that you're almost right. Customers who are completely off-base are easier to teach because they need the whole lesson. Here, I'm just trying to call out key points, but presenting them in their full context to make sure it's clear what fits where. Throughout the post, refer to the graphic at the end of the post as it may clarify what I'm talking about. Dalku wrote: No. If there is, that's a bug that needs to be reported to NI ASAP. Think about what you just asked for... ignore the DVR part for a moment. You just asked for a PARENT object to invoke a CHILD class method. That cannot ever happen. You cannot pass a parent object directly to a function that takes a child object. The parent object in question IS NOT a child -- the parent object does not have the child's private data, nor does it have all the methods that may have been defined on the child class. For this reason, LV will break the wire if you try to wire a parent wire to a child terminal -- the wire is broken because there are zero situations in which this can successfully execute. You CAN pass a child object to a parent terminal. That is because a child IS an instance of the parent -- it has all the necessary data and methods defined to act as a parent object. What you can do is take a child wire, up cast it to a parent wire and make a Parent DVR out of that. Alternatively, you could take a child wire, make a Child DVR wire, and then upcast that to a Parent DVR wire... these two processes produce the idenitical result: a parent DVR that contains child data. Upcast and downcast DO NOT create new objects EXCEPT when they return an error. The point of a cast is to say, "I have an existing object. Please check that it is this type and approve it to go downstream if it passes this test." You use this only when you need to do something for a specific type of object and you do not have the ability to edit the parent and child classes in order to add the appropriate dynamic dispatch VIs to both. Preserve Run-time Class (PRTC) is the same thing. "Allow this object to pass downstream if it passes this test, otherwise create a new object that does pass the test." The test in this case is "Does the object in have the same TYPE AT RUN TIME as the OBJECT (not the wire) on the target object input?" If the left object is the same or a child class of the center object then there is no error. You will ALMOST NEVER WIRE PRTC WITH A CONSTANT FOR THE CENTER TERMINAL. I would say "never" because I can't think of any useful cases, but maybe someone has something out there. If you are wiring the center terminal of PRTC with a constant, something is wrong in your code. You use the PRTC to assert that the left object, which comes from some mystical source, is the right type to fulfill run-time type requirements of dynamic dispatch VIs, automatic downcast static VIs, and the Lock/Unlock of Data Value References. In all three of these cases, there is some input (either the input FPTerm or the left side of the Inplace Elt Struct) that must be passed across to the output (either the output FPTerm or the right side of the Inplace Elt Struct) WITHOUT PASSING THROUGH ANY FUNCTION THAT CHANGES THE OBJECT'S TYPE. You're free to change the object's value, but not its type. Sometimes you pass the object to functions where LV cannot prove that the type is maintained. Easy example -- pass the object into a Global VI and then read the Global VI. You'd never do this, of course, but it demonstrates the problem. LV cannot know that the object you read from the global is the same object you wrote in -- some other VI elsewhere might have written to the global in parallel. But you, as the programmer, know that there are no other writes to the global VI, so you use the PRTC to assert "this is going to be the right object type." You wire the original input (as described above) to the center terminal, and the output of the global to the left terminal, and pass the result to the original output terminal (as described above). Does that make sense?