Leaderboard

View File Mark Balla's Icon Editor V2.7>= LV2017 Mark Balla Icon editor V2.7 December 2020 Author: Mark Balla Description: This is a text based vi icon editor The purpose is to help quickly create text base icons. The editor can be used in place of the standard NI icon editor or as a stand alone vi. see instructions. Version 2.7 Updated font table to recognize the standard "Small Font" letters used by the NI icon editor. This will improve the OCR function when importing icons generated by the NI Icon editor. Version 2.6 Added quick drop code to allow the user to switch between NI and custom editor. QD_Swap Icon Editor.vi and support folders will be placed in the LabVIEW quick drop folder ..\National Instruments\LabVIEW 20XX\resource\dialog\QuickDrop To switch LabVIEW to a custom icon editor that uses the lv_icon.vi set a shortcut key to call the QD_Swap Icon Editor.vi. Ctrl-Space Ctrl-<<assigned letter key>> To switch LabVIEW to the NI icon editor that uses the lv_icon.lvlibp use the same shortcut key with the Shift key Ctrl-Space Ctrl-Shift-<<assigned letter key>> Version 2.5 Fixed install bug where lv_icon.lvlibp was not being renamed after LV 2016 2.5 was set to 2017 or later. Instructions: LV 2017 to LV2020 + Ver 2.7 + LV 2010 to LV 2016 Ver 2.4 Install using JKI VI Package Manager LV 2009 Ver 2.3 1:Rename the curret LabVIEW 2009 Icon editor LabVIEW 2009\resource\plugins\lv_Icon.vi to a different name so it will not be overwritten. 2: Place the three files (lv_icon.vi, color templates.bin and the folder lv_icon_Subvis) in the LabVIEW 2009\resource\plugins directory. The next time the icon editor is called LabVIEW will use the lv_icon.vi instead of the standard one. There is a button on the editor that will allow you to use NI's editor (Old editor not the new one) when a text icon is not desired. For LabVIEW 8.2 Use the "MB Icon Editor_V2.3_LV82.zip" file For LabVIEW 8.5 Use the "MB Icon Editor_V2.3_LV85.zip" file For LabVIEW 8.6 Use The "MB Icon Editor_V2.3_LV8.6.zip" file Submitter Mark Balla Submitted 10/19/2009 Category LabVIEW IDE LabVIEW Version 2017 License Type BSD (Most common)  

Love the language but it is hard to disagree with this, I am a synesthetic and dyslexic human who finds it much easier to deal with and faster to program in(except for the amount that it crashes and the multi-hour build times) I have 10-15 years left in my career (hopefully, no climate change depression 🤞) and I fully expect to spend the last 5-10 doing legacy support and converting old LabVIEW apps to something else. I am starting to learn skills that will facilitate this. Closed source will never compete with open souce. Just look at how dotnet has expanded since Microsoft open sourced it and moved it to cross platform.

I did not know. That possibility was not even on my radar. Even though the drumbeat of bad news had been going for a while, most corporations refuse to change direction on a bad decision. NI showed more sentience than I usually expect from massed humans: the sunk cost fallacy is a trap that is very hard to get out of. I figured the very good engineers on NXG would either surge through it and make it fly or we would bankrupt the company trying. That's the pattern established by plenty of other companies. Mixed. I spent 4.5 years directly working on NXG (2011 to 2016) and countless hours in later years working with the NXG team to design a future G. I really wanted it to fly. There is so much good in that IDE, including some amazing things that I just don't see how we ever do in the LabVIEW codebase without just shattering compatibility. But at the same time, I was watching good friends toil on something that the market just wasn't adopting. The software had some problems that were going to take a long time to solve. The issues were all solvable, but the time needed to fix them... that was harder and harder to justify. NXG gave us a GREAT platform for other software: Veristand, FlexLogger, etc. That code is extremely modular and can be repurposed for all sorts of tools. We also learned a heck of a lot by building NXG -- some things that I thought we could never do in LabVIEW now seem possible. NXG gave us a sandbox to learn a whole lot about modern software engineering without putting the delivery schedule for mature software at risk, and those practices [have been|are being] brought back and applied to LabVIEW -- that will decrease cost of maintaining older code. All in all, NXG was valuable -- the expenditure was not a complete loss. I am very sorry to the few customers who did migrate to NXG. We don't have a reverse migration tool, and building one would be absurdly expensive. Leaving those folks stranded is going to hurt -- I hate letting our customers down and just saying, "We have no solution to help you." There aren't many of those folks (that's essentially the problem), but they do exist, and they are basically stuck having to rewrite their NXG apps in some other tool. I can only hope that they pick LabVIEW. I don't know if this will help us or hurt us with customers in the future... on one hand, people may say, "Well, you let us down on NXG, why should we trust you will be there for us on any new products?" On the other hand, this decision was clearly made listening to customer feedback, and it takes a lot of humility to swallow a loss that big, which may make customers trust our judgement more in the future. And, really, there's nothing to compare with the scale of NXG -- an entire computing platform -- so this does seem like something that needs to be judged in isolation. I really like programming in G. I like being able to expand G to make it more powerful. I wanted NXG to succeed because it had the potential to be a better G. It failed. Its failure means more resources for the existing LabVIEW platform, which will directly help our customers in the short run. It leaves open some big questions for the long run. So, in summary: I think it was a decision that had to be made, and I'm happy to work for a company that can learn from new data, then admit a mistake, and then figure out how to correct it.