Aristos Queue

Clarification: It means that the default value of the control is not the same as the default value of the class. It may be an instance of a child class, as Justin suggested, but it can just as easily be a non-default value of the class itself -- so if your private data cluster contains a numeric whose default value is 5, this control may have the numeric with a default value of 6.

QUOTE (mic_k86 @ Feb 19 2009, 09:36 PM) Yes, it is possible... in fact, I had to go out of my way to make it keep acquiring data because that's what I thought you wanted. Guess I misunderstood. I don't have LV available at the moment, so I'll tell you the easiest way in text: Take the VI I gave you and put the data acquisition code inside a Case Structure. Connect the time to the ? terminal. Put your acquisition code in the "Default" case and don't do anything in the "0" case. There's actually a much better way (the way I just told you will have the loop spin as an empty loop polling for a value change) but I can't explain it in text.

Edit >> Find Set the radio button at the top of the dialog to "Objects" Click on the Add primitive and select from the palettes the Stacked Sequence Structure. Set the search scope to the VIs you want to search -- they have to be loaded into memory already. Click "Find" and you'll get a list of all the sequence structures. If there are any password-protected diagrams, you will be prompted for the password before the results from those VIs will be displayed.

QUOTE (ragglefrock @ Feb 18 2009, 11:05 PM) Nor can I, which is why I posted http://forums.lavag.org/Providing-a-template-for-overrides-t13289.html&view=findpost&p=58591' target="_blank">this.

QUOTE (MJE @ Feb 18 2009, 09:40 PM) Ah. I see. Yes... I agree... something like this would be useful for you. Hm... well... Attached VIs are saved in LV8.6... Replace <labview>\resource\Framework\Providers\LVClassLibrary\NewOverride\CLSUIP_CreateOverride.vi with the new version here Download File:post-5877-1235021532.vi (BACKUP YOUR EXISTING VI FIRST!) and save the new "User Scripting For New Override.vi" Download File:post-5877-1235021543.vi in the same directory. You now have a hook to write your own scripting code into the process. The new subVI gets invoked after all the other scripting is already complete, so you can delete what's there and start over or somehow adjust that diagram to suite your needs. I can't help more than that at this point.

QUOTE (MJE @ Feb 18 2009, 01:15 PM) No, there's no way to do this. When LV is asked to create a new Override VI, we *ALREADY* start with the parent VI as the template VI. This gets all of the connector pane, VI properties, and front panel. Then the diagram is wiped except for the FP Terms, a call parent node is dropped, the terms are wired up, and the controls of parent type on the FP are substituted for child type controls, including updating the labels if the parent label text includes the name of the parent. To do what you're asking would require amending that entire process.HAVING SAID THAT... If you have "a common starting point", that suggests you are overriding at too high a level. In other words, you currently have Parent:DoSomething.vi and you are overriding with Child:DoSomething.vi. What I'm suggesting is you consider taking the "variable" portion of Parent:DoSomething.vi and make that another subVI -- call it Parent:DoSomethingCore.vi -- and then override that core VI. Part of why we wipe the entire block diagram is that ideally the child doesn't have any code that is duplicated by the parent. Would that work for you?

CAR 146495

Here you go. Download File:post-5877-1234783260.vi

The Call Parent Node is for VIs that are members of a LabVIEW class that have dynamic dispatching enabled. Dropping the Call Parent Node on the block diagram of a dynamic dispatch VI creates a call to the parent class implementation of that method. The Context Help and the online help for the Call Parent Node go into lots of detail.

QUOTE (menghuihantang @ Feb 15 2009, 11:10 AM) This is not an authoritative answer -- someone else may know a better way. One thing you could do that would work is to create a LV string where the first 4 bytes are the length of the rest of the string and then pass it to the DLL call as a C-style string pointer.

What is the memory layout of a VB string?

QUOTE (shoneill @ Feb 12 2009, 02:22 AM) Yep... that's where I was going next... dynamically load the parent, give it a run-time only ID, now dynamically load the child... and the grandchild... it gets messy quick. Now, there are TONS of applications where you don't need multiple levels of inheritance to be dynamically loaded, so your suggestion has significant merit. But it is still one mitigation, not a general solution.

QUOTE (Darren @ Feb 12 2009, 05:54 PM) Good! These users can finally get some practical advice... I've been feeding them theory for two years, and I think some of them were starting to believe in it.

QUOTE (Darren @ Feb 12 2009, 11:24 AM) Passed? You're lucky I wasn't your grader!!! Congratulations, Mr. CLNCA (Certified LabVIEW No Class Architect).(In full disclosure, I can't razz Darren too much since I am not sure I could pass the CLA, LV classes or not. Remember that G programming is only a hobby for me; I spend most of my time architecting C++. Or, to put it another way, I write in text so you don't have to.) QUOTE If you die of a heart attack while taking a multiple choice test on LabVIEW, are you a CLADaver? Ah. We need more users like this. :-)

QUOTE (shoneill @ Feb 11 2009, 05:03 PM) Actually, no. Some things are logically impossible: A general hash function that never produces collisions. Sorting data faster than O(n*log n). Preventing name collisions among a system where anyone can contribute a name without a central database of names. There are ways to mitigate name collisions, but not prevent them. Hearing the use cases is important because they affect which mitigation schemes might work best. So keep talking... I'm listening.

QUOTE (mic_k86 @ Feb 11 2009, 09:20 PM) In the Dialog palette, you'll find One Button Dialog, Two Button Dialog and Three Button Dialog.

QUOTE (Mark Yedinak @ Feb 11 2009, 06:34 PM) "var" means variable. The way to read this is "declaration of three variables, named ComPort, TC and Mode, all of type Integer".

QUOTE (Daklu @ Feb 11 2009, 12:27 PM) If the namespace is not used anywhere other than load, how do you invoke subVI calls? Suppose you have two copies of X.lvlib, each of which contain Y.vi. When you load the second X.lvlib, according to your scenario, we would put that library in a new namespace Temp:X.lvlib. Now you load Alpha.vi, which calls X.lvlib:Y.vi. It is going to call the original X.lvlib:Y.vi, regardless of which one it was expecting to invoke because that's the one that got the name.The goal of namespaces is *not* merely so that you can have two things of the same name in memory simultaneously. It is actualy so that you can *use* those two items simultaneously, and meaningfully keep straight which one is being used by any given caller. Being able to load a VI isn't much good if you can never invoke it.

QUOTE (menghuihantang @ Feb 11 2009, 04:02 PM) QUOTE function DESKWINRESET(var ComPort, TC, Mode: Integer): Byte Comparing the picture you included against the function prototype, I'm pretty sure that you've got it configured exactly right. I would guess that the problem is more likely with the value of the parameters that you are passing in than with a problem with the types. It's pretty hard to mess up integers.

QUOTE (Daklu @ Feb 11 2009, 02:04 AM) It is coherent. :-) And I think it will provide fodder for contemplation for the next few years. I say that because I don't want you to think the feedback is lost even though nothing may come of it for many years. This would not be the sort of feature that would be rushed into a release.

QUOTE (Daklu @ Feb 10 2009, 06:46 PM) Not necessarily. I replied in more detail in the other thread you spawned.

QUOTE (Daklu @ Feb 10 2009, 06:46 PM) Yes, there is a default app instance. An app instance is simply a LV sandbox for VIs. All VIs always load into a given app instance. QUOTE After doing that, what happens if I then try to load another library with the same name outside a project context? Is another 'default' application instance spawned with a different name? No. There is only one non-project app instance. QUOTE How does Labview deal with this situation: An application is built with a static link to a "Honda" class to provide automobile functionality. Later on another "Honda" class is dynamically linked (since it cannot be statically linked) to provide lawnmower functionality. Does Labview automatically coerce the Honda lawnmower class into a different namespace so it can share the same application instance? Does Labview open it in a separate application instance and automatically provide communication between the two? Does the behavior change when moving from the dev environment to the run-time environment? Nope. You would simply get the Honda.lvclass that was already in memory in that app instance. Your questions strongly hint that R&D has been significantly off track in our work on this problem, at least as far as your situtation is concerned -- it may apply to other users as well. Let me see if I can explain why your questions disturb me... We [R&D] have been almost entirely concerned about *development* time collision of VIs/Libraries. The single biggest challenge that we have focused on "I have a bunch of VIs in my project. I create a source distribution of my VIs. Then I open my source distribution to make sure it was created correctly, and then my source distribution and my original source ends up cross-linked." This seemed to be the primary reason for all the prefixing/renaming that was taking place. Thus in that environment the project is aware of the links of everything that tries to join the project and it throws up a protective dialog if stuff that would create cross-linking tries to join the project. That dialog offers you the chance to open the new items in a separate project, where you could rename the items, put them in a library, or just realize that you didn't want that in the first project in the first place. When you are done developing VIs, we expect you're going to go deploy them somewhere. This may be by building an EXE. This may be downloading them to a target. This may be by building a source distribution and running them in the development environment. But at that point, you are no longer editing the VIs. The presumption has been that when you are now running your VIs that you don't have these concerns about collision because your application is something that has been created. Even if you have a bunch of dynamically loaded VIs/classes, those dynamically loaded components are things that were designed in the context of the application; they know the framework that they are loading into, so there should be zero concerns about collision with the elements of the framework itself. When the components are independently developed by unrelated groups of developers, the dynamically loaded components should be placed in a library to namespace the elements... your Austin development team would have their pieces in a library named "Austin.lvlib", and your Shanghai team would have their pieces in "Shanghai.lvlib", so even if they both wrote a "DAQStuff.lvclass", those are two different qualified names when loaded into the framework. Now, your questions seem to imply that you could have multiple unrelated applications -- the test lab microwave, the cafeteria microwave, etc -- all loading into the same run time environment. Under what conditions does that occur? Why does that even arise as a concern? When is there ever a single labview.exe that is running both of those applications? The presumption is that all those different Microwave classes would never come together for the first time in the run time environment. Long before you ever got to that point, all these classes would have been loaded together in a project in development, and the project would have forced you to sort things out at that point, if the classes were not already in uniquely named libraries. If you really are bringing these classes together for the first time in a run time scenario, it means that your use cases are far away from the common scenario envisioned by R&D. QUOTE The way Labview namespacing is tied to the library name seems like an odd decision since it creates potential implementation obstacles that apparently make name mangling the safer route to take, even if it isn't a completely satisfying solution. Maybe these aren't real issues at all and only exist in my mind... Given that the library is the container for the member VIs/sublibraries, and given that the VIs/sublibraries know they are members of the owning library, choosing the library as the namespace seems very natural to me. QUOTE We had developers attempt to create a hierarchical namespace by nesting LVLibs but that proved to be unworkable. What was their failure here? I'm going to guess that it was something like this: You had two development teams, Alpha and Beta. And since the development efforts of these two teams might sometimes get used together, it was decided that Alpha should use "Alpha.lvlib" namespace and Beta should use "Beta.lvlib" namespace. So Alpha created two different toolkits, Ping and Pong. And when they went to namespace these toolkits, they were frustrated because they realized, darn it, we don't want to have to distribute Ping and Pong both together. But if both Ping.lvclass and Pong.lvclass are in the same owning library, then that implies that they want to distribute together -- libraries, by design, package stuff together. Am I right? National Instruments does not have a single "NI.lvlib" that namespaces everything that NI produces to keep it separate from user developed VIs/libraries. If you look around, you'll notice that a lot of NI libraries have "NI_" as a prefix, and within that library is all the stuff for a particular toolkit. The prefix is not something that we apply during the production of the source distribution... it is the name the library is initially created with. Your suggestion of a "meta" namespace -- one where a library says, "I'm part of the NI namespace", and multiple libraries might claim that, is interesting. It severs the concept of the namespace from the concept of access scope. Currently, if something is inside the namespace then it has the right to access private VIs in that scope. But such a meta scope, which any library might join arbitrarily, obviously couldn't extend the right to access private functions to just any library that said, "Oh me too!" But as a way of providing a common namespace that everything produced by a given set of developers into a unique namespace, it might be useful. It doesn't invalidate the library as namespace -- as I said above, that is a very natural container, and the namespacing there is valuable. But a second form of namespacing -- one that is divorced from reciprocated ownership -- might be worth contemplating.

QUOTE (bsvingen @ Feb 10 2009, 06:37 PM) I've never heard of such a situation in C++, but templates is an area where my knowledge is admittedly weak. So let me ask a couple questions... it might help me say whether the same problem even exists in LV and whether the same (or similar) solution might help. A) What is the performance problem that you are attempting to ameliorate? Is it the overhead of dynamic dispatching? B) What is an example from C++ where you would use templates instead of inheritance to improve performance?

QUOTE (Ton @ Feb 10 2009, 05:02 AM) Oh, I know that the OpenG distribution has a lot of useful features. I'm only addressing the one feature of renaming all your VIs/libraries when publishing. The goal was to make such hoop jumping unnecessary. But your list does raise a related question: Why the heck would you want a random namespace??? I can understand a GUID or a version or somesuch, but random?

QUOTE (Daklu @ Feb 9 2009, 10:59 PM) With exactly identical file names, you can have both your source and distribution in memory at the same time. You load your source in one project and your distrib in another project. They are thus in isolated application instances. LV 8.5 and later will even detect if you try to load your distrib into the same project as your source and will say "this could potentially create cross linking, would you rather open this in a separate project?" Every LV 8.x release has included features designed to eliminate the need for prefixing. If you're still needing it, then clearly there is something that the R&D team does not understand about LabVIEW and how our users are using it, because there's general agreement on the team that the tools exist now (8.6) such that you shouldn't have any reason to keep using prefixes. This should probably move to a new thread, rather than hijack Daklu's original question about how to deal with this, but a detailed list of why, between the project application instance isolation and the library namespacing, prefixing for distribution is still necessary.