Leaderboard

> is this functionality exported in any way that we can take advantage of it in classes? Not currently. Those are marks on properties of C++ classes. The LV classes have no such designation. Not a bad suggestion. I'm guessing this would be a property you would set on the Property Folder, not on the VIs themselves. It would be up to you to still recolor the icons of the VIs if they were being used somewhere directly instead of through the property node. We could do it on the VIs, I suppose, but at that point, I'd want a much broader feature for deprecating VIs generally that had nothing to do with classes. Hmm... would you ever want to deprecate only the read or only the write half of a property? If that's a use case, it might be better to be on the VIs themselves. Anyway, think about it, and then throw it on the Idea Exchange. It's a worthy suggestion but not one I've contemplated before. I'll ping Mr. Mike on this topic... he is the member of my team that owns the property node interfaces.

I have permission from AQ to say this: Aristos Queue has no idea what he's talking about. It's possible to deprecate properties, but we have it hidden. This was built so some of our APIs could be deprecated with the potential of releasing it in the future. When you deprecate a LabVIEW Class Property it will remove the item from the property menu and is supposed to turn the property node reddish pink (it doesn't because of a bug I just discovered). I don't remember the behavior of deprecated overridden properties. The deprecation applies to the LabVIEW Class Property Definition Folder itself (i.e. the property itself), not the individual methods. I'm not against turning it on in the future, but I think it'd need to have significant public support before I get off my lazy butt it gets approved. Uhhhhh...you mean like this? Seriously, this is what it looks like if you know how to show it.

Just have the property start returning random values. Developers will realize it's unreliable and just stop using it.

Exactly. I agree, selecting pull-down menu takes time, but as I get used to it over time it goes faster and faster. Also you just need to do this like two or three times a hour after adding new controls / indicator (as I write programs). I frequently use CAD application too, but I always liked the way LabVIEW does not automatically snap in position. actually it does make some things easier for me (on large VIs with many wires). Best solution might lie in between (like turn on / off snap positions by hot-key). I disagree if it comes to mixing everything up, since this would make a VI even more unreadable. How about adding a tool where you can design your own control / indicator symbol of a cluster / class or any complex type? ...(That would possibly make things even more complex......) I agree, flipping between BD and FP is not a solution. In my opinion, if you even need to switch between BD and FP, your VI got to large and you should consider using SubVIs. But using large icons does not solve this problem too, since they also do not show all information about your type. So what I usually do is using the help window while programming large solutions on classes or other object related projects (It will tell you more as you could possibly show on any icon). sense of humor at the end? Let me say just this: Thanks for adding large icons, they helped me a lot when I started programming in LabVIEW. Thanks for letting me choose between large and small icons, I really appreciate this. Whether my VI benefit from small icons or not depends on my particular VI and my specific way of programming. I suppose a bad programmers VI will be unreadable no matter which icon he or she uses, am I right? If you want to know something about your VIs readability, just open a VI you wrote one or two years ago! Just got thinking: Maybe we are running in circles on LabVIEW, like when you are beginner, you use large icons, at some point you switch to small icons and when you are professional you might switch back to large icons... I'm pretty shure there has been a similar singularity here on LavaG.

Uhh... that's a block diagram. Why do you *care* where they connect? I remember posts on the dark side suggesting matching the general location of a terminal on the bd, fp, and connector pane was "good style." I tried it for a while but it got to be a pain rearranging all my wires and block diagram if I changed a conpane terminal connection. I'll try to put fp controls in the same general location as the conpane terminals, but I don't worry about matching the block diagram terminals. I'll put them wherever they need to be to make a clear block diagram. Personally I think most style debates are much ado about nothing. The goal is code clarity, not style for the sake of style. There are lots of ways to write clear code and communicate intent. We're "advanced" developers, right? I'll leave the style gestapo for the dark side. (Not suggesting anyone here is being part of the style gestapo... writing this brought back memories of numerous style debates with developers.)

I tend to following both of these practices, though occasionally I'll break the top/bottom rule if the input isn't used some ways into the VI, somewhere off the first screen of the BD. This tends to happen with CLN- or property-node-heavy code. I used to think this way, but I abandon it not long after starting LabVIEW. The front panel is for matching the conpane, the BD is to organize whatever makes the most sense. Sometimes that ends up matching the conpane, but usually only in simple VIs.

It's Friday, so what the heck? Without taking up that much more space (in most cases) than the icon view you can give me some really useful information and capabilities on the BD. Certainly clears up the FP/BD relationship. I would use this in a lot of subVIs and totally bag the FP. Drop an indicator, choose the Control view and forget about probes.

You could also make a picture out of 1x1 free labels as pixels...

Pretty good point, but not completely correct. I just tested your VI with my target VI running and found that the Delete and Paste methods don't work. We are able to update Free Labels when their VIs are running. I guess I'll just have to limit myself to things I can represent in text. One avenue I can explore is to float VIs over the block diagram.

The easiest way to count the button presses is to use the Event Structure, like this: Every time the button gets pressed, the value in the shift register gets incremented by one. Look at some example files (use Help >> Find Examples... in the menus) of usages of the Event Structure. You probably also want to combine this with a basic state machine pattern. You essentially have 3 states: "Draw the two colors", "wait for button to be pressed", "Evaluate results". You can code that up like this: In the "Wait For Buttons" case, put the Event Structure. In each case, you decide which frame you want to happen next. Sometimes it will be a fixed constant, sometimes there will be some decision about which frame to go to next. This is the state machine pattern and there are lots of good examples of it, also, in the Example Finder. Good luck.

Dear CLAs, The call for submissions had been posted at the CLA Community: https://decibel.ni.com/content/docs/DOC-19083 Please check it out and start thinking what you are going to present at the summit. Thanks, Fab

Can't kudo it because it was declined. I see it was pretty popular there and is also popular here on Lava. When I started using LabVIEW I used icons. Once I gained a lot of experience I switched to the more popular small terminals. Later still I switched back to icons influenced greatly by your arguments in the link you provided. There just are not enough controls on any of my diagrams to worry much about the space savings. As for straight wires I just gave up long ago. You can't wire the small terminals to the inputs of a multiply prim without bends for example so it makes no difference in that regard. It is impossible to code in LabVIEW without wire bends so I just quit worrying about it. I do try to limit the number of bends to two at most. Since it is just not possible to avoid wire bends with or without icons that argument doesn't go very far. The only things I know of that you can wire a vertically compressed stack of small control terminals to without wire bends is another stack of indicators or bundle/unbundle by name. You can't wire them straight to adjacent subVI terminals except in one ironic situation. If you deselect view subVI as icon and drag down the nodes so it looks like a bundle by name or more accurately like an express VI. How many people knew you have the option NOT to view a VI as an icon? Does anyone do that? As for quickly identifying if it is a control or a VI, well they just look like controls and I can immediately tell by where they are located. You just get used to a particular style after a while I guess and anything else just looks weird and wrong. There are two situations where I regularly show small terminals. If there is a reason I need to put the terminal in a loop or something or if it is not on the connector pane then I do not show it as an icon. I don't know where I picked that up and just realized that's what I do.

Yup. But my style is to have control labels to the left, indicators to the right and for them to be stacked closely to lessen wire bends.Of course. I don't suffer as much from the "obj" problem

I greatly prefer the icons (as James knows) because: 1) They are easy to see. I am very focused on the interface and I want the terminals to stand out. 2) They sometimes contain additional information, and I consider them more aesthetically pleasing. 3) Saving space is not a concern because of the way I design my applications. A class method (and very nearly all my VIs are methods in classes) usually has the terminals for the owning class, error terminals, and maybe an additional input or output (occasionally a couple of each). I have plenty of room for these on the block diagram, and I want them to be highly visible.

That has got to be among the most subtle settings I've (n)ever seen! I thought it might be new, but it was there in LV 8.6 as well! I am very dissapointed in myself for missing that So, we can use the native Format into String and Scan from String functions with a single format specifier string to create and convert a timestamp to an ISO-8601 UTC compliant string. Please excuse me now while I search eBay for a slightly used tantō...