Jump to content

Aristos Queue

Members
  • Content Count

    3,125
  • Joined

  • Last visited

  • Days Won

    172

Everything posted by Aristos Queue

  1. Bobillier: It isn't really meaningful to color a particular instance of an object -- from wire to wire, it isn't necessarily the same object. It's the same as asking to have different color wires for two integers in the diagram or two strings. If the two things really represent different concepts in your system, you might create two different classes, both inheriting from the same parent class. Classes are distinguished on identity, state, and behavior, and there are good arguments for making two things be different data types even when they both have identical APIs. LabVIEW has neve
  2. It would be fine to do... I just didn't bother writing the conversion. The performance differences between a set and linear searching an array are essentially impossible to measure until about 1000 elements on a modern CPU.
  3. @JKSH Thank you very much. Attached, folks, is a revised copy of the .lvllib and its subVIs that will set icons for camel case VI names. Just unzip it to replace the files currently in your 2020 install -- make a backup copy first in case I've done something egregious. Text-Based VI Icon.lvlib.zip Included in the directory is one VI that is *not* part of the library: "Configure Named Icons.vi" If you open it, you can fill in a list of words to abbreviate and list of words to ignore. If you run the VI, these lists will be saved to your LabVIEW config file. The regular
  4. @Darren Command line requires lots of quote marks if there are spaces involved. Not everyone uses a UI.
  5. And if we had something like "Split English CamelCase.vi", someone could also fix the spell checker in VI Analyzer. Just sayin'. 🙂
  6. UPDATE: Solution posted below. In LV2020, if you right-click on VI's panel icon, there's a new menu item: "Set Icon to VI Name". It splits the name at spaces into words and creates a nice text icon. Great! But some places have coding conventions that require no spaces in the name -- it's easier to use git with such files. And in that case, the current code sees the VI name as all one string. I would very much appreciate it if someone with spare time wants to rewrite this VI to handle CamelCase names: vi.lib\LabVIEW Icon API\Set Text Icon\Adjust Text to Fit Rectangle.vi Th
  7. “There was this fence where we pressed our faces and felt the wind turn warm and held to the fence and forgot who we were or where we came from but dreamed of who we might be and where we might go...” -- Opening lines of “R is for Rocket” by Ray Bradbury I spent 20 years building this G language of ours. It’s time for me to go enjoy the fruits of that labor as a user! I will still be employed by NI, but I will be working full time for Blue Origin. As part of the NI “Engineer in Residence” program, I will be on loan to Blue Origin to revise their engine and support test systems. They
  8. I have made public a document detailing an old internal feature of LabVIEW that will be of great interest to those of you deploying Packed Project Libraries. Until recent conversations with a customer, I never considered that this would have much utility. The problem this solves: First, you build a packed project library (PPL) from source. Then, you write a VI that calls that PPL. It works fine. But now you load the caller VI under a different target in your project. The caller VI breaks because it tries to load the PPL, and the PPL refuses because it isn't built for the new target. Packe
  9. A software team can produce the next version of the software with the same staffing as the previous version. There’s no requirement to keep ramping investment other than pay raises. But if the employment environment is sufficiently non-competitive, not giving raises doesn’t lose devs. I presume hardware has similar economics, but I’ve never dug into that. In short, flat R&D can still provide continuous growth in revenue, as seen during 2001 and 2008 downturns at NI.
  10. I have a theory for what a good UI for GIT would look like, and it is a bit different from the existing ones. I think there should be a picture of the current state of the world. You draw a picture of the state you want. Then the tool generates the command line commands that get you from A to B. This serves two purposes: rather than taking an action and then seeing if that did what you want, it puts the UI in charge of figuring out how to get you textually what you're specifying graphically. Second, it shows the user what the commands are that it is executing so that you figure out "oh,
  11. THIS. Absolutely this. Misery loves company: please use GIT!
  12. GIT is that awful, in my opinion. I've screwed up many things years. I try not to use it as much as possible. The reason that GIT has taken over the SCC world is not because of its ease of comprehension or elegance of interface. It is because it is the only tool that can manage the full complexity of massive software teams, parallel releases, compression of features, etc, and the folks who use it daily just deal with it and get used to it.
  13. Glad I could help. I’ve already seen it have some small external impacts on how NI interacts with customers (in both cases, positively). We will have to wait and see whether it turns into anything more substantive.
  14. NI had a massive online event, the company updated the website, our execs have given interviews, and I-don’t-know-how-many employees are on social media. I’m not sure how much louder we can amplify this. All I did is repeat what has been said in other public forums. 🙂 If I happened to use words that got the point across, great. But the content ain’t new!
  15. The core of our business has changed. Fewer users are developing their own test applications; instead, they're buying something off the shelf like TestStand. Fewer users are developing their own data acquisition software; instead, they're buying something off the shelf like FlexLogger. This trend alters significantly the role of LabVIEW (CG and NXG) in the NI ecosystem -- it becomes far less important to support whole application development (though, of course, we still do and will) and far more important to support "just a bit of customization" when the pre-built tools fail. A lot of softwar
  16. It is uncommon enough to do the job -- truly unique is hard to do with the limits imposed on modern logos. Color: The folks who study this said that the blue was a color used all over the place in corporate logos; the green is much rarer. There's really only a handful of colors that are available for corporate logos: red and blue are the big dogs, then green/purple/orange. And black. Yellow doesn't have enough contrast -- as we constantly prove trying to put the LV logo on things, so it has to be boxed into stuff. Yes, you pick a shade of those colors, but your logo will be bucketed anywa
  17. I liked it in theory, but I'm seeing a bunch of warnings online about Stylish having become malware that is shipping private information to third-party. You might want to investigate.
  18. I answered the question you were really asking, which was, “Did you idiots even think before implementing this junk?” If you had wanted an actual explanation of the feature, I’ve seen your posts often enough to know you would have asked directly. You didn’t ask that, so I didn’t answer that. Your response to JeffP strongly suggests that I was right. X__, it is honestly hard to tell in many of your posts whether you want an answer or just want to pick a fight. My goal is to answer customer questions about LabVIEW and its design and to learn enough to fix designs that aren’t working. Plea
  19. Yes. It is an excellent change from CurGen that makes source management far easier for all use cases that we have evaluated.
  20. Place any new items in a separate map and then merge them after the loop finishes.
  21. NI already did: it is called LabVIEW NXG. NI created NXG specifically to address weaknesses in LabVIEW 20xx UI layer. The LabVIEW 20xx editor is antiquated, but its C++ code is very hard to modify. Given that NI's focus for user interfaces is almost entirely in NXG, there is very slim chance of further developments ever in the LabVIEW 20xx control editor. I cannot say "no, never" just as I never promise "yes" on future functionality even when I'm actively working on it, but I will say that it would take significant user encouragement for NI to fund the 20xx control editor ahead of other 20xx p
  22. No. That's not what I said at all.
  23. Nope. Variant attributes and maps use the same — identical — underlying data structure. For reasons I don’t grasp, the C++ compiler adds a couple extra instructions in the maps case only when the keys are strings that aren’t in the variant attributes. Still, the conversion time to/from variant for the value tends to dominate for any real application.
  24. Of your six items, NXG addresses three of them and has improved support for a fourth. The source code control stuff is still in flight -- not sure when the target is for delivery [again, not my department]. Sealed classes is so far down the priority list, it's not even in the backlog I bet. I couldn't get traction for that in LV20xx.
  25. It wasn't removed from NXG. It has not yet been added. There are a sizable number of customers who lobby LV 20xx to remove it entirely, and others who want it left just as prominent as it is today. You can see one place where that discussion has been playing out: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Hide-Run-Continuously-by-default/idi-p/1521886 NXG hasn't decided how to handle it yet, so they haven't added it. It's in the ToDo backlog to add it somewhere.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.