Aristos Queue

QUOTE(Tomi Maila @ Jul 18 2007, 05:10 PM) The ancestor classes do have to be found on disk, but they do not have to be added to the project tree. The ancestors will show up under Dependencies. QUOTE(Gavin Burnell @ Jul 19 2007, 11:28 AM) The application instance ID is only in the type descriptor array not in the flattened string data. Now, if you make that input a LabVIEW Object control, then when you wire up your class control it will be cast to a LabVIEW Object first. Then you flatten that to a string, and recover the 'real' class name from the flattened string, but the type descriptor array refers to the wire type which is a LabVIEW Object and not a wire of your specific class. The next version of LV will have a VI in vi.lib to deal with this to let you get the actual type. For the moment I'm not really coming up with any helpful solutions. QUOTE(Paul_at_Lowell @ Jul 19 2007, 01:12 PM) Oh, I see! The type is always "LabVIEW Object." I missed that. You described that in a previous post... Returning to variants would solve this but leave the wiring probem.... XNodes, huh? I'm not sure what to do about this one.... AH. Here we go... The attached VI will give you the name of the class ON the wire, as opposed to the name of the class OF the wire. http://forums.lavag.org/index.php?act=attach&type=post&id=6422''>http://forums.lavag.org/index.php?act=attach&type=post&id=6422'>http://forums.lavag.org/index.php?act=attach&type=post&id=6422

Does anyone have a standalone DLL that has a function which, given a memory address, returns the byte, word or int at that memory address? It would be useful for a hack I'm contemplating, and I don't feel like coding a DLL for a one-off project.

Try putting all of your calculations into a subVI. On the top level VI, only have the actual controls that make up your user interface. Then the temporaries that you're using for variables don't show up in the Event Structure dialog.

QUOTE(Paul_at_Lowell @ Jul 18 2007, 02:36 PM) *blink* Really??? They should be the same array if they're the same type... oh, wait... the type name. Crud. Yeah, that would skew the result. The data type includes the "name" of the wire in the output array. Argh. I was trying to be helpful. Sorry for the red herring. QUOTE(Tomi Maila @ Jul 18 2007, 03:43 PM) p.s. Aristos Queue, nice to see you here more often again. I guess you are less busy with your projects now Welcome back. I was on vacation. A much needed one. QUOTE I'd really like to see LabVIEW to automatically add the available methods for particular class to the context menu of a class wire. AQ, are we seeing this anytime soon? No. There have been so many usability challenges raised to this idea. I like the idea, and a couple of members of my team have tackled it, but it ends up being unpleasant. Basically, recall the complaints that occur when LV moves the palettes around between versions of LV. Now imagine if the palettes changed around every time you edited your class. The grumbling gets loud. Then there's the constant debate about *which* menu should appear first -- if you popup on a child wire, should you get a single palette with all the methods of child and parent and grand parent? Or should these be separate palettes? Should the parent be on a subpalette or should the child be on a subpalette? All in all, I've decided it is low priority -- if you're creating a class to be reused, when you're done with development you can create a palette by hand and set it to appear in the context menus (using the class' property pages). If you're still developing the class, just use the project tree as the palette -- it's close at hand generally.

QUOTE(Ben @ Jul 18 2007, 01:06 PM) Ben, I think the emoticon that you were wanting was:

QUOTE(xtaldaz @ Jul 18 2007, 11:04 AM) Story: One of our interns made a change to LV's source code that broke the exe. Our chief architect, in a mock scolding, said, "You be careful! That code is older than you are!"

QUOTE(Paul_at_Lowell @ Jul 18 2007, 11:19 AM) Pop up on the Flatten To String node and select the LV 7.x compatibility mode. This gives causes the node to add a type descriptor output. You can then compare the type descriptors for equality. Note, this allows to test for *equality* ... it won't help if you're looking for "this class or any child of this class."

QUOTE(Val Brown @ Jul 17 2007, 02:32 PM) Yes. Because otherwise someone will *find* a way to copyright, trademark or otherwise patent it and then charge you license fees. Fix the US legal system first, then we'll fix the naming conventions. :-(

You're facing the same problem that an array of clusters faces when you want to search for a cluster based on a single field instead of the entire cluster. The only way around it in LV is to write a new Search 1D Array that checks for whatever criteria it is that you're searching for (you can write this generically and then take a VI Server refnum to provide the comparison routine, too). This has been done by many people and I think there are implementations of it on LAVA somewhere.

QUOTE(Michael_Aivaliotis @ Jul 10 2007, 03:44 PM) I used to recommend the rendezvous for this case. But after a while I started noticing that although rendezvous solved the initial problem of synchronizing two VIs, many programs eventually turned out to need more communication between the VIs that went beyond just a "go" signal. So I've just been recommending queues/notifiers right from the start so that the data channel exists if it turns out to be necessary.

QUOTE(John Rouse @ Jul 11 2007, 12:42 PM) I'll be free to talk about NI's use of it at NI Week, but not until then. All I can say is it is pretty extensive for such a new feature. Of the new features I've seen added to LV over the years, the event structure is the only one I can think of with a bigger impact on programming style of our G programmers. NI's overall adoption has been somewhat limited by the lack of support for classes under RT and the embedded targets, something I hope to remedy in the coming years.

QUOTE(Gavin Burnell @ Jul 10 2007, 03:25 PM) In my best Mrs. Cake voice (from Terry Pratchett novels): Ah, lad, ye gots to report ye crash or how canaye fix yon bug?!

Affects both 8.2 and 8.2.1. There is an issue with generic probes of LVClasses. The problem arises only when a parent class uses another class as a data member and you probe a wire of a child class. Assume 3 classes: Parent, Child and Other. Child inherits from Parent. Parent's private data cluster contains an instance of Other. Other's private data cluster contains a numeric. Child's private data contains a numeric. Set the value of Child's numeric to be 10, then probe a Child wire. The 10 will show up in Other's cluster. In this case you simply get misleading information in the probe, which is bad enough. But if Other uses a string instead of a numeric in its private data control, the 10 will be written where the address of the string is supposed to be in memory, leading to a crash (since 10 is not a valid memory address). This issue is known and will be fixed in the next version of LabVIEW. Addendum: I do really want to know how so many of us managed to use classes for 11 months after release before this got found. It hasn't even been reported from customers... my teammate found it randomly while working on something else. It amazes me sometimes just how long a seemingly common bug can go undetected.

Amazon.com has started a very cool site: http://www.mturk.com/mturk/welcome The basic idea is to use human intelligence to augment artificial intelligence. So a search query comes in "find the cheapest pizza joint along the path from my house to home that does carryout". There's no one database to check for this information -- google maps might find all the pizza places, but comparing prices and whether they do carryout requires visiting the pizza restaurant sites. But a human being behind the scenes could answer this question. So Amazon.com has established a brokering system so that you can post a question, for a price, and another person can answer it, and get paid for doing so. The interesting use of this is in beating CAPTCHAs -- a spammer that faces one of those "type in the word you see in this image" that is supposed to block robots can automate the posting of a question to the Amazon.com site and then posting the human's answer back to the original website, thus giving the robot the ability to get past the CAPTCHA. It costs a bit of money, but for some activities (online polls, marketing buzz, etc) there would be financial gain for doing the post, so it may be viable.

QUOTE(Michael_Aivaliotis @ Jul 10 2007, 02:33 AM) ... such as having both VIs obtain a reference to the same named notifier. The VI that needs to be running uses Send Notification to indicate that it is running. The VI that needs to wait until the other is running does a Wait For Notification and thus doesn't proceed until the notification is received. If it happens that the first VI gets up and running first, that's ok, it just means the message is there and waiting for the second VI so it doesn't have to wait.

QUOTE(mateo @ Jun 26 2007, 11:52 AM) You might try placing the "Request Deallocation" primitive on the block diagram of the VI that is too big. Read the documentation before using this primitive. It explains the how and why this prim might help and the time/space tradeoffs you'll encounter.

QUOTE(yen @ Jul 9 2007, 12:43 PM) True. The diagram disable structures do not hold VIs in memory. If you need to hold subVIs in memory without invoking them, use the Static VI Reference node (found in the Programming>>Application Control palette).

Prior to the diagram disable and conditional disable structures in 8.2, you could just drop a case structure and wire a constant to the ? input. This wasn't a complete commenting out -- if you had a broken wire inside the case structure, your VI was still broken, unlike the new diagram/conditional disable structures. But it did guarantee that code would not execute. That trick still works in 8.2, but the new strutures, as I mentioned, do a more thorough commenting out.

QUOTE(lraynal @ Jul 2 2007, 07:26 AM) What are the licensing restrictions on icons on this page? Some of these icons include trademarks, so I can't imagine that these are all free-and-clear for use in other programs. I couldn't find any licensing information on the website anywhere.

QUOTE(MikaelH @ Jun 14 2007, 05:13 PM) In most situations, you can get around the Call By Ref limitation by creating a static VI that just calls the dynamic subVI, and then using Call By Ref to invoke the static VI. Not as nice as being able to do the invocation directly, but it does work. As for the lack of reentrancy on the dynamic dispatch VIs, let me just say that I think that's a serious limitation of the language and some NI software engineer ought to do something about that in a future LV version. By the way, to Jan, Mikael, Tomi, and Jim, I was knee-deep in work for a future LV version when the toolkit released, so I never got a chance to say this formally and publically: Congratulations and thank you. Your tool is a valuable addition to the OO resources of LabVIEW. -- Stephen Mercer -= LabVOOP Lead Engineer =-

QUOTE(Karissap @ Jul 3 2007, 05:37 PM) Please file a bug report against the documentation so this can be noted in a future LV version.

QUOTE(alukindo @ Jul 5 2007, 01:45 AM) Please register your request using the http://digital.ni.com/public.nsf/allkb/EDA7C01C684ACB6286256FF0000238D5' target="_blank">Product Suggestion Center.

QUOTE(ntward @ Jul 7 2007, 04:17 AM) There isn't any "control and indicator" concept in LV. Data enters a VI at controls, and leaves a VI at an indicator. In your case, input says either "open" or "close", the VI executes to do the operation, returns the current state of the valve and then the current state is compared against the original input, and the results of that comparison are displayed in an indicator. This would be fine for calculating the value, but what you're describing is that you need the composite behavior not because of any calculation of value work but instead to provide a nice user interface. <joke>There goes UI, messing with the purity of dataflow again.</joke> There are two possible solutions. The first is to physically stack the input control on top of the output indicator on the front panel. You might put the boolean indicator as a background behind the control. For some user interfaces, this works fine. To some degree, it is my preference, since if the control itself changes color/state to indicate an error, the user may think he/she can no longer use that control. But there are user interfaces where this is desirable, so the second option would be using a property node to set display properties of the control programmatically. You can right click on any control on the front panel and select Create>>Property. Drop the resulting property node on the block diagram and choose the property that you'd like to set.

QUOTE(LV Punk @ Jul 9 2007, 06:17 AM) Hm... you should probably file a bug report on this.

Service Locator also gets involved with online help. If you look up a primitive in the online help, there's a button to show that prim in the palettes. Service Locator brokers the transaction from the html back to LV. Similar for the "open examples" button in the online help.