Aristos Queue

QUOTE(Omar Mussa @ Aug 3 2007, 04:00 PM) I fixed the bug that made insert of a Bundle node not find the right terminal for the LVClass. In a future LV version, Bundle will insert correctly when you are on a member VI of the LV class. We're not ever going to have public or protected data on my watch.

QUOTE(eaolson @ Aug 3 2007, 03:33 PM) Advantages of a write accessor: 1) Suppose that you have a cluster that has a wrong value in it. Where did that wrong value get set? You search your entire LV hierarchy for all the bundle/bundle by name nodes, set a conditional custom probe on each one, and run until you find which one is the problem. Compare that with you open the only VI that is ever used to bundle new values into the cluster, set a single conditional probe, and run until you find the problem. 2) A given field of a cluster is supposed to always have a value in some range. Everytime a VI bundles a new value into the cluster, you have to remember to put the range checking code down. Compare that with only a single VI able to bundle new data in, it becomes easy to enforce range checking on values. Advantages of a read accessor: 1) Suppose you have a cluster of data about a person. One of the fields is "age". Your program works great. But the next year you realize that you have to update your entire database to add one to everyone's age. You realize that you were silly to store "age" as a numeric. You change to store a Timestamp and whenever someone asks for age, you subtract from the current date. If you have a raw cluster, you now have to visit every point in the code where they were directly unbundling "age" and change it to call a subVI that unbundles Timestamp and does the subtraction. Had you had an accessor in the first place, you wouldn't have to revise any of the code except the accessor VI. These are the big three: debug, range check, and refactoring. There are other smaller advantages. The debug advantage is so pervasive as to warrant using accessors for all data that will be accessed outside the class itself (and sometimes it pays to use the accesssor method even on VIs that are inside the class). QUOTE So you're creating a Frankenchicken? Yessssssss.... who wants to be Igor? Submit resumes at NI Week! QUOTE(Omar Mussa @ Aug 3 2007, 03:41 PM) And then, it hit me, or rather I hit it ... on accident I right clicked a tad further to the left of a vertical class wire ... let's call it on the left side of the vertical class wire... insert bundle by name and *presto* it actually had the bundler wired correctly. Soooo close to usable. It won't work at all on a horizontal wire as far as I can tell. LV 8.5 hasn't been out for a full day yet, but I already get to post this: This is known and already fixed in a future version of LabVIEW. *sigh*

Users: Recursion? In LV8.5? Did he really say that? Me: Yep. Users: This isn't some VI Server hocus pocus is it? Me: Nope. Users: This is honest-to-goodness-subVI-on-its-own-block-diagram recursion, right? Me: Yep. Users: What's the catch? Me: Well, you've got to use LVclasses to get it. Mwuhahaha! Details? Check out LV8.5, and look at examples\lvoop\Recursion\Demo Recursion.vi Ah. I feel better. I've been wanting to announce that for many months now. Eventually someone will ask why non-LVClass VIs can't have recursion. The answer is, they can, and someday they will. But LVClasses were already positioned to take advantage of some of the early refactoring work needed to make recursion possible. For now, I like to think of recursion as bait, to draw users into trying LVClasses who wouldn't otherwise. :-)

QUOTE(Omar Mussa @ Aug 3 2007, 03:06 PM) Oh. Hey! Look at that! 8.5 is available. (I never know when that's going to happen... R&D hands over the final CD to a figure in shadowy darkness who disappears into the night, and sometime after that everything goes live.) In that case... Perhaps you should check out the new "Cluster, Class & Variant" palette on the block diagram. ;-)

QUOTE(Omar Mussa @ Aug 2 2007, 08:01 PM) We created classes to be able to generate new LV datatypes. One of those requirements is that the new datatype be able to look like a new type and not specifically a LabVIEW class. So the popup palette for a LV class is completely definable through its Properties page. We didn't add a default palette. This is a decision that has been both praised and damned and may be revisited in the future. One of the issues is "Should you show the App Control palette (with the To More Specific prim) or the Cluster palette (with the bundle/unbundle)?" We'll talk about this topic more when we get to your point #5. QUOTE 2) Class inheritance data is not exposed properly to child classes -- there is no protected data. I want to unbundle protected class data -- I should be able to unbundle/bundle (i.e. access) protected properties of a parent class from a child class. Sorry... this is correct behavior and is not subject to review. Create a protected accessor VI to give children access to parent data. All the arguments for why there is no public data apply to why there is no protected data. There are so many programming benefits to channeling access to data through accessors that any weakening of that wall is going to take a pretty compelling use case, which no one has yet proposed. We will be making it substantially easier to create such accessor VIs in upcoming LV versions. QUOTE 3) You can't 'find' dynamic dispatched VIs using a standard LabVIEW search. This means you also can't 'Find All Instances' of your dynamic dispatch VIs. This makes debugging applications a real pain and means you have to be very selective of which VIs you want to make dynamically dispatched. A definite weakness. Something that is on the "must be fixed soon" list. QUOTE 4) (This issue was raised earlier by Jim Kring but I reiterate its usability issue for me) -- you can't drag a class onto a Filepath control. This annoys me a lot -- I really hate having to do this from Windows Explorer. CAR'd for bug fixing. QUOTE 5) The object primatives are not easy to find... there should be a LVOOP pallette. Its really annoying to have to navigate to the 'App Control' pallette to access functions like 'To More Specific Class' and even worse 'Call Parent Method' -- LabVIEW treats objects as second class citizens -- which then translates to the development community treating them as such as well. Yes. There should. (*yells over shoulder* Hey, rest of LV R&D, you see, at least one user agrees with me!! ). Let me highlight part of your quote again: QUOTE LabVIEW treats objects as second class citizens I *sooooo* agree. :-) I have been told that to be a first class citizen, a feature has to have users first. There's a chicken/egg problem here, but I have been slowly assembling a chicken from spare parts. Continuing this odd analogy, perhaps I should start giving out certificates to early adopters. "Congratulations, you're part of the LabVOOP Chicken!" QUOTE These issues seem painfully obvious to me as someone who uses LabVIEW a lot. I think as these issues are handled better, adoption will increase. I look forward to the next round of fixes. Congratulations, you've just identified some, but not nearly all, of the major usability issues with LV classes. I will now dance happily since none of these are *functionality* issues. Functionality for the 8.2 release. Usability comes next. There's only so many hours in the day to work classes into all of LV's nooks and crannies. :-)

QUOTE(bbean @ Aug 3 2007, 10:06 AM) Just a guess, but I would try launching the paletted editor, going to the controls palette, and deleteing the subpalette that references this file.

QUOTE(zoogies @ Jun 25 2007, 04:05 PM) I didn't spend six years developing LabVIEW classes so that you guys could stay at LV7.1. Yes, LV classes should jump out at you as awe inspiring. Unfortunately, it's hard to sell them as awe inspiring (an ongoing problem I'm working on). If you're doing any substantial desktop development (classes don't yet go to the various target platforms) then classes: 1) ... help write more organized VIs 2) ... help make VIs that are easier to debug 3) ... help write VIs that are easer to extend with new features 4) ... help write VIs that are easier to hand off to the next developer 5) ... help write VIs that are easier to reuse The folks who've heard my sales pitch in person know that I mean every one of those claims. Not everyone believes me, but the number of converts is growing. Stability? Yes, there were seven ugly bugs in LV8.2 that are fixed with the 8.2.1 patch. There are still some glitches in LV8.2.1, but it just keeps getting better. I can't promise that LabVIEW classes are the way of the future for LabVIEW development, but they will be if I can convince enough people to try them and to realize the power and potential.

This was reported to R&D (CAR 4C1A37J1) for further investigation.

QUOTE(dsaunders @ Aug 2 2007, 10:52 AM) The drop box can actually over hang the edge and/or bottom of the window (and it can over hang the top of the window in the case of a very large drop menu). That's why it is implemented as a separate window -- it is actually a different window. You have left the front panel any time you are over these components. You get a VI Window Leave because the operating system has a VI Window Leave. I am very surprised to hear that this is new in 8.2. Very surprised because the implementation of the rings/enums has been this (again, to the best of my knowledge) for as long as there have been rings and enums. I would expect this behavior to go back to 6.1 (the introduction of the event structure). The fact that it doesn't replicate says to me that someone fixed a bug. Probably we weren't detecting other cases where we had left the window, leading to various bugs in other VI use cases (such as someone implementing custom popup menus or somesuch by creating temporary windows).

QUOTE(Ben @ Aug 2 2007, 10:22 AM) No. What it should support is a theory that drop boxes are implemented as hovering windows -- just as they are in every other app environment that I know of. The VI Mouse Leave event is correct in that respect ... the mouse is now over a different window. I believe you'll get the same thing with popup menus. QUOTE(Ben @ Aug 2 2007, 10:22 AM) Wouldn't it be just grand if NI opened up the library of all of their XControls? I think we have. When XControls were new in 8.0, there were zero in the palettes and (to the best of my knowledge) that was because none of NIs controls were XControls. I think that remains true for all the core LabVIEW controls. XControls have started showing up in some of the modules and toolkits, but all the ones I've seen are wide open (no password protection).

I don't see a CAR number. Has someone reported this to NI?

QUOTE(PaulG. @ Jul 31 2007, 03:48 PM) At the risk of confusing everyone, I do have many functional globals that are reentrant. That's how I can create separate databases -- the core VI is reentrant and contains the uninitalized shift registers. Then I create a series of wrapper VIs that are not reentrant that will be my entry points. Each wrapper VI is thus a single shift register database.

This was reported to R&D (# 4BUEOEJ1) for further investigation.

QUOTE(Michael_Aivaliotis @ Jul 30 2007, 01:42 AM) Mozilla on my PC has the bug. But Firefox on my Mac-Intex laptop also can't upload. I flip over to Safari when I want to post a file.

QUOTE(abuch06 @ Jul 27 2007, 10:07 AM) Try a different browser. I can't upload images when I'm using Firefox, but I can using MSIE and Safari. I believe Michael is aware of the issue.

QUOTE(Tomi Maila @ Jul 28 2007, 09:31 AM) I believe that you are meant to open and run ExecutionControl.lvclass:controlMainFlow.vi That is the main VI.

Posting an image makes this easier for everyone to diagnose. Do you have a screenshot of your block diagram available?

QUOTE(dcooper @ Jul 24 2007, 10:44 AM) Dcooper, the LAVA site isn't associated with NI and most of the NI folks don't read it. For these types of suggestions, you should go use NI's online http://digital.ni.com/applications/psc.nsf/default?OpenForm' target="_blank">Product Suggestion Center.

QUOTE(rolfk @ Jul 24 2007, 12:21 AM) Nah, just my personal thought on the situation. I'm not privvy to the conversation that lead to the licensing of scripting. It just seems that no one around NI minds when the advanced customers dig stuff out of "LabVIEW's attic", but when it starts showing up among the general user base and creating a support burden, there starts to be grumbling about "never intended that to be opened up."

Yes.

QUOTE(rolfk @ Jul 23 2007, 05:18 PM) True. Which is why licensing got applied to scripting. You probably don't want to promote the publicity of this lest similar protections come to the callback.

QUOTE(Yuri33 @ Jul 22 2007, 10:36 PM) No, and using such callbacks is a trick we go to great lengths to prevent folks from doing.

QUOTE(eaolson @ Jul 19 2007, 09:31 AM) Every application instance has its own application refnum. You can have multiple application refnums for the same LabVIEW.exe on the same machine. For example, if you open two LabVIEW projects, each one has its own application instance, and you can get the app refnum for each of those and then open VIs into those app instances. Your comments about these opening TCP/IP connections apply ... LabVIEW treats communication between two app instances as if it were communication between separate machines. This makes it possible to develop multiple apps on the same machine and have those apps work together at runtime whether they're deployed on the same machine or different machines. If the apps are on the same machine, LV does optimize out some of the communication overhead unless you explicitly open the application refnum using a TCP/IP port number (wire to the port input on the Open Application Reference primitive). Any VI that you open in the host computer's targeted application instance will be deployed on the target when you run that VI. The host's targeted app instance is a proxy for what goes on down on the target.

QUOTE(lraynal @ Jul 20 2007, 02:23 AM) Is that platform independent or just MS Windows?

QUOTE(chrisdavis @ Jul 20 2007, 03:51 PM) Thanks.