Aristos Queue

The number of users who vote for one idea is pretty high. My personal theory is that few people visit regularly. VERY few people have any interest in reviewing the ideas on a regular basis. I've been thinking that when a new idea is posted, it should not be made public -- we should save up a block of ideas and release them once a quarter, or maybe when we hit some target number (say, 50 new ideas). That way people do one visit, scroll through the latest list, and vote for the ones they like. If it is much more infrequent, I think people are more likely to take a moment to scroll through the list. I base this theory on the burst of votes that the 24 ideas that I summarized in an ni.com post -- people saw that post and they went and reviewed the ideas, and they voted. These were clearly people who hadn't seen those ideas before, but many of them had voted for other ideas on the exchange. Thus, I think the problem is one of visibility, not enthusiasm.

Ideally you wouldn't inherit from anything with an Initialize method. You would create an abstract parent class, move all existing methods and data up to that class (except for the Initialize), and your new class would be a sibling class, and thus able to have its own initialize. This is ideal because it maximizes flexibility for future development since each actual concrete class can evolve independently. Sometimes it isn't possible to make this mutation (especially if you need the LV auto-mutation of flattened strings to work for values saved in files or because you don't own the parent class), but if you can, that's probably the best route.

When you can't do that, have a protected InitCore.vi that takes a dyn disp input and a public "Init X.vi" where X is the name of the class that does not have the class input. The descendant class would create its own "Init Y.vi", and it would call InitCore.vi to get the parent segment initialized.

And here's the results:

I posted an experiment on ni.com. It's a unique approach to making extensible options dialogs. I have no idea if the parts of it that don't work can be improved, but Yair asked me to post it publicly -- I built it over the course of yesterday and this morning in response to an experiment he tried on his end, which inspired my attempt. You can read more and get the VIs here:

http://forums.ni.com/t5/LabVIEW/An-experiment-in-creating-compositable-user-interfaces-for/m-p/1262378#U1262378

Ok... I have something that works well enough now. Thanks for the various suggestions. Winner is Hooovahh for best suggestion. Kudos!

I would avoid stacking SPs one over the other, especially because that means that each SP needs to know about the position of controls in the other SPs so it can avoid overlapping them. Instead, each SP could be the size of its content and you set its position dynamically based on the size of the other SPs.

But you already know that...

Except that the goal is interleaving, not just concatenating. And if there's an ordering to the interface, the later plugins can dynamically adapt to the content of the earlier plugins.

Forget about using transparent but rather get the image and put it in a Picture control. Put an image of the control (the one rendered on this layer) in the right position and cache the bounds of the control so when a user clicks you can determine if the clcik get handled here or not. If not, pass (what does THAT mean Ben?) teh click to who ever owns the sub-panel.

That still runs into the question of how to pass the click along... I don't know of any VIs that let me say, "Tell VI that a mouse click just happened *here*. Do whatever it is you would've done had the click actually occurred on you."

[Later] The screen shot also runs into the problem of updating the visual for mouse move, or for things that are continuously updating as the VI executes. Dead end, but thanks for the idea.

I've been thinking about a UI design that would involve stacking multiple -- maybe 4 or 5 -- subpanel controls, one overlapping the other, with the option "Make Panel Transparent" enabled so that you can see one panel through the other.

The problem I'm running into is that mouse clicks are not similarly transparent -- i.e., if I click on the stack of subpanels, the controls in the top panel are live, but the mouse click does not fall through to the panels behind it.

Does anyone have a solution to the problem? Anyone figured out a way to redispatch a mouse click to the next layer down?

Thank you for your reply! I sent a join request to access to the private group! I think this will be very useful. BTW, what do you think about my other questioln? what and why do you choose that?

In general, go with #2 or #3, but each of those has enough advantages/disadvantages that you'll have to look at the behavior of your specific program.

It is so sad that very difficult to find any quotes about application desing.

LVOOP has only been out for 4 years. That might sound like a long time in computer terms, but in terms of writing high level programming design texts, it's very short. Having said that, this December, a revised LVOOP customer education course from NI will be available, which does include lessons on design. In the short term, there are several texts on designing various subsystems you can find by going to ni.com and searching in the search bar for "LVOOP FAQ" and scrolling to the bottom of the FAQ document -- it includes links to a few design papers. There's also good stuff for OO design in the 2010 NI Week presentations (instructions for accessing those are included here).

You're looking at a limitation of classes. If the same class is loaded in two projects, it cannot be edited. Plain and simple as that. It has to do with applying edits from one project to the other in a meaningful order. There are many cases where you can edit a file in one project and another file in the other project and the class, which depends upon both files, has to handle the resolution of those changes, but the order in which the changes are applied matters for how the class finally ends up, and there's no way to resolve the changes.

But that would suggest there is dependencies between the two projects - but the dependencies tree is has no elements in it (no expand button).

And then I read this... jgcode is right... that's very odd... I was assuming that one class used the other and thus they were both loaded in both projects.

Is there a third app instance that you're loading these classes into?

Right click on the class in the project tree and select "why is this library locked".

There's an idea on the Exchange that we're thinking of doing in LV 2011, but we've run into some usability stumbling blocks with exactly how the feature should behave. Please follow the link and read the post from ChethanR about the options that R&D is considering for this feature. None of them seem to be the right thing, yet.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-type-def-from-block-diagram-constant/idc-p/1256064#M7875

GDamnit, I suck

Hey! No taking G's name in vain! No wonder LabVIEW doesn't always work for you!

What Daklu said.

Thanks for the kudos, everyone. Darren and I will take it from here and see how far we get... keep an eye open for the beta program come spring to see if we made the case. :-)

I've given up on posting any significant language advancement ideas on the IE, simply because I know it won't get any kudos and that will give management leverage not to implement it. If I lobby for it on Lava or NI's forums it might get someone's attention at NI and they can rally internal support for it while avoiding the dreaded IE mark of death. That's my hope anyway...

I like to point out to various and sundry constituencies within NI that a teeny tiny handful of customers ever asked for object oriented programming. We never got a field sales engineer reporting "My customers could really use some better encapsulation." But we got tons of requests for the compiler validating the VIs marked as not-top-level in LLBs weren't called outside of the LLB. We never got requests for inheritance, but we have many requests for more code reuse.

R&D is fairly aware that the big changes -- the ones that shift the paradigm of LabVIEW, like the Event Structure or the IPE or OO -- are not common user requests. Putting them on the idea exchange is not a bad thing. That still gives us a place to discuss a new idea in the public forums, and it can provide a one-stop-shop for all the ideas we've considered over time. For example, I don't expect my source code control meta language idea to ever rack up high kudos, but I put it on the Idea Exchange to archive it and to allow the few folks that could envision that idea to comment on it. I probably won't ever work on that idea, but maybe someone on my team will at some point. Anyway, I still like that aspect of the IE, and I hope that the "reach for the stars" and the "hey, I can dream, can't I?" ideas still get posted there.

The NI Example Finder already has a fairly extensive defined set of categories and search terms relevant to LabVIEW, programming, and the hardware LV is typically used with. It also has a mechanism for identifying VIs that are keyed with those search terms, and it can search both local harddrives and the online ni.com repositories. It may have other options for extending its search locations further.

The Example Finder is written entirely in G. I wonder how hard it would be to make it also search for packages?

Just got the email this morning I passed my CLA exam at NI Week 2010.

Congratulations.

If I don't pull the reference out to use it, should I still close it?

Your guess is as good as mine on Project stuff. What does the online help say?

Why does there need to be two node classes?

You will always need two classes for this to work.

There's a difference between function recursion and data recursion. The first is a function that invokes itself. The second is a data structure that is self-similar as you proceed through it. LV added function recursion, but that changes nothing about how you define the data types. The data recursion is what we're working with here. A class -- in *any* programming language -- cannot include itself. Every time you tried to instantiate the object, it would instantiate itself, and then another copy inside that, and another copy inside that and... boom, infinite data allocation. No can do. To do data recursion, you need two data types. If you create such structures using references, you can do it with two types -- the class and a reference to that class: the class contains a reference to itself. When the class allocates, it allocates itself and a NULL reference, which does not immediately allocate further. LV has a restriction to prevent this -- we don't allow the class to ever refer to itself, whether in a reference or directly. It's an overly broad restriction, logically speaking, but it dramatically simplifies a whole lot of parts of the back end systems -- we felt it was an acceptable trade-off, and we recognize there will be many customers who disagree. Regardless, what I'm showing in my Linked List impl is a by value data structure that is recursive. You still need two types. The parent class does not have a recursive definition. The child class includes the parent. Thus, when you instantiate the child, it allocates a parent, but the value does not immediately go any further than that.

Static VI refs...

... do load the referenced VI into memory

... do not need to be closed

... won't do anything if you do call Close on it

So if I don't apply a password to my community and friended components, it's possible for someone to swap in new functionality under the guise of friendship?

Yes. No different than replacing a subVI with another of the same name. What made this different -- and thus, why we made it securable -- is that you're opening up access scope to call into a normally off-limits function.

That is... weird. Try changing the conpane of one of those VIs -- change the input terminal to Dynamic Dispatch Input, save it, then change it back and save it again. See if that gets it out of the list.

(the override script does not apply the new name)

No, it doesn't. That's deliberate, although possibly wrong in retrospect. It's a philosophy question -- what does the label even mean on these terminals? Is it the name of the parameter? If so, it should be the same on all the overrides. The fact that it happens to default to the same as the name of the original parent class notwithstanding. If it is the name of the class, well, for one thing, it is redundant, but it also would mean it should change with each level of inheritance.

Honestly, in retrospect, I think the default names should have been something like "dispatch in" and "dispatch out", but I know a lot of people wouldn't like that for various reasons.