Jump to content

Aristos Queue

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Aristos Queue

  1. A) GUI isn't higher or lower priority than those language features. There are multiple teams working on NXG. B) The GUI generally is not seen as particularly broken. The particular UI for classes is (in my opinion) cumbersome but functional. The priority was getting classes working. There will be UI improvements over time. Honestly, NXG team has more credibility with that than I do in LV20xx. The "new class" experience in LV20xx has been terrible for how long? And we only got it fixed in LV 2020? NXG has shown a far better track record for releasing a language feature and then improving the UI later when they have more usage data about what features people are actually using and how. I am NOT saying you should be using LV NXG right now. In my personal opinion, NXG is still a long way from full-app users moving from 20xx to NXG. But there are a reasonable number of users for whom NXG is sufficiently complete TODAY that they do develop in it. Various people at NI will give you different time estimates for when all LV users should move over. That variance in estimates is not unexpected for a product of NXG size and complexity. As I have said before: The NXG vector direction is good, but vector magnitude is still developing. I know there are several that have ported, and I thought NXG had shared details of at least one large customer app with the community, but I'm not sure... I don't recall what I've seen in customer presentations vs internal presentations. You'd have to talk to someone customer-facing in NXG to get specifics. There are multiple forums on ni.com for these questions.
  2. The plan is to record it. Lots of new technology involved in this, so fingers crossed.
  3. The directions have changed rather radically on many points in response to user feedback. The new component system is completely redesigned twice from customer feedback, and that's another thing I definitely wish LV20xx could backport. They dropped work on interfaces to prioritize scripting because of overwhelming feedback that the scripting tools were higher priority for getting work done in NXG. (Interfaces help some large apps... scripting helped almost every developer either directly or in the tools written for others.) I am not on the NXG team, and yet I can point to decision after decision made directly from customer feedback.
  4. Because the refactoring is so much better. I would make this change in a heartbeat in LV 20xx if I could do it without breaking compatibility. I would differentiate the icons in the project tree, which NXG chooses not to do. Take a look at LV 2020*... interfaces and classes use the same file extension, and it is way better for refactoring hierarchies. BUT we use distinct icons in the project tree and various other places. You can read the details of this decision in the document I published yesterday about interfaces. I even go into detail about where we deliberately do NOT differentiate for end users. * LV2020 Community Edition became available yesterday. Commercial edition will be later in May... we prioritized the CE release for all the quarantined engineers at home.
  5. Official answer from folks at NI: The answer is unfortunately no. We compile our VIs for ARM V7 architecture. Pi Zero is less capable, doesn’t support all instructions.
  6. I'm not sure where you get that. The execution engine is the same engine that LabVIEW 20xx uses. Classes and typedefs are the same things that they've always been. The limitation of gtypes being inside classes is one I've complained about personally... it is entirely a limitation of the UI, not the underlying nature of the entities involved. Yes, both .ctl and .lvclass use the same .gtype file extension. That makes refactoring G code to change between the two a lot simpler. But what the files represent? That hasn't changed. There are still 25 fundamental LabVIEW types, of which LabVIEW class is one (NXG doesn't have sets or maps yet, which bring the total to 27), and a typedef can host any of them (except void).
  7. Without going into anything NI confidential, yes, NI has lost significant sales opportunities because the old fashioned UI of LabVIEW 20xx does not appeal to the next generation of engineers and scientists. Redesigning the UI from the ground up was the primary mission of NXG -- incremental adjustments were considered and rejected early on. NXG's design is very much driven by data from sources such as user testing, customer feedback, and sales numbers. Any issues NXG has had getting off the ground with customers are less from going in the wrong direction and more from having so many parts that have to move in the same direction for it to work. As more parts have come into alignment, the user base is starting to pick up.
  8. This IS fixed in LV 2020, but it got left out of the Upgrade Notes*. I have posted details here: https://forums.ni.com/t5/LabVIEW/LV-2020-Upgrade-Note-Altered-rules-for-named-Bundle-and-Unbundle/td-p/4035624 The fix is very healthy for most apps, but we did find one internal-to-NI app that was dependent on the dumb-luck-that-it-sometimes-works behavior. We had to fix that one up by using the Coerce To Value primitive to set a name of the element in the caller. But going forward, such antics should not be necessary... the adaptation rules of named bundle/unbundle are now well-defined. * My mistake -- apparently my tech writers cannot read my mind; I actually have to hit Submit on bug reports, not just leave them in Draft. *chagrin*
  9. LabVIEW Community Edition 2020 is now available for download. The commercial edition will follow sometime in May. We prioritized the Community release for all the engineers stuck at home under quarantine. LabVIEW 2020 introduces interfaces as a companion feature to LabVIEW classes. I and Allen Smith will be presenting what would have been our NIWeek presentations as a webcast this Friday. Two topics, one time: Intro to Interfaces (Stephen Loftus-Mercer) Interfaces and the Actor Framework (Allen Smith) Friday, May 1 10am, CDT Join here (Microsoft Teams required): LabVIEW 2020: G Interfaces [EDIT] The same link above will let you watch the recording for the next 90 days. After that, NI will find some place to more permanently host the video. Youtube Link If you have any follow up questions, Allen and I are both monitoring a specific forum thread on ni.com for this presentation for the next couple weeks. To start learning about interfaces today, please see the Fundamentals>>LabVIEW Object-Oriented Programming section of the LabVIEW 2020 shipping documentation the shipping examples in examples\Object-Oriented Programming\Basic Interfaces examples\Object-Oriented Programming\Actors and Interfaces If you are someone who already knows about interfaces from other programming languages and want to understand why G interfaces work the way they do, you may be interested in reading LabVIEW Interfaces: The Decisions Behind the Design.
  10. I don't want to just remove the privates completely ... if you're working inside the class, you may need those. But there's an old compromise in the actual palette code... if a library is locked (not just read-only but actually locked) or password-protected, then hide the community and private scope methods. Our theory was that if a class is locked then its internal development is finished and published and any of its friended components are probably also done (or they know that they are friends and can go get that information). Similarly if all children are either non-existent or also locked, then remove the protected scope stuff. I don't know how hard it is to get that info without opening a class library refnum. I sooooo wish that getting a library refnum wasn't a performance death sentence. I had nothing to do with creating that code. In retrospect, I wish I had stuck my nose into that project. I've looked into refactoring it... it's a mess.
  11. You cannot use any reference to the class itself within the class. Technically, we could enable some things, like a DVR of the class within the same class, because the default value is Not A Refnum. But we chose -- consciously -- to make the rule "no references to yourself in your own private data." It's an easier rule to teach, and it has various performance benefits for initialization (that mattered more on the hardware from 13 years ago than they do today). And it has come up very rarely. In fact, I think you're the first person whose asked me specifically about the VI reference case. All the others have a reasonable workaround... need an array of X? Use an array of its parent class (which may be LV Object). Same trick works for most refnums... or you can always cast a refnum as an integer and cast it back when you need to talk to its data. But casting doesn't work on strict VI refs and you cannot use it as its parent class type. I think you're stuck. I can't see a way out of that box.
  12. No. I didn't take the time to do that. Would be cool if it worked though. If you decide to patch it up (there's no passwords on those VIs), I'm happy to ship the revision.
  13. In LV2019, I extended the right-click plug-ins to be able to attach a graphical palette so you can drop items from the menu. Then I added the right-click menu item to populate the palette for classes. And I just found out (thanks, Darren) that LV2020 doesn't update this graphical palette for methods coming from parent interfaces. Haven't even released... already have a patch list. *sigh*
  14. > Admittedly, it has been probably a year since I heard that discussion. About a year... yeah. πŸ™‚NXG's G scripting priority was... shall we say... re-evaluated after the European CLA Summit in 2019. It was kicked up a few notches after some very pointed comments from the user community, confirmed by Americas CLAs later that year. I'm not on that team and haven't kept tabs, but there should be some scripting support soon if it isn't already there.
  15. Bah, Crossulz! You are definitely not invited to the next White Elephant gift exchange. You'd show up with a wrapped present and just announce, "It's socks. Just so you know."
  16. You know how all LV objects are represented as cubes? What do you call just the surface of a cube? πŸ™‚
  17. > I have heard directly from NI that there are no plans to delay the releases that were planned for NI Week being in May. A few are moving a bit earlier even. I'll be flagging LV 2020 on LAVA as soon as it is available (if the NI marketing folks don't beat me to it). I'm maybe perhaps just a little bit excited about this particular release.
  18. That pretty much defeats the purpose of the VI. The whole point of the exercise was to figure out how big to size the VI relative to the monitor so the caller VI could maximally lay out its controls without taking up the whole screen... and if I don't know which monitor it is on, it doesn't work. πŸ™‚ BUT... you made a great point about the run-time engine. You're right that I should have avoided the use of scripting, esp since there's a dead obvious existing VI to use -- the subVI itself! So I eliminated the app reference (HUGE performance savings closing that reference), and the creation of the new VI (no screwing with the Untitled VI count every time this VI runs), and got rid of the close ref of the new VI (another major savings). And now it'll work in a run-time engine, and it is now fast enough that I don't have to worry about caching. Thank you for the suggestion. Saved, as before, in LV 2014. Note: I worked in LV 2020, and I just picked 2014 as the version to save back to... it'll go back earlier if someone needs it, but, honestly, folks, I only get paid if you upgrade! πŸ™‚ Compute Maximum Desktop Bounds.vi
  19. Have it working. @The Q : Darren had the same suggestion you did. Worked just fine. See attached VI, saved in LV 2014. Compute Maximum Desktop Bounds.vi
  20. I'm still working on LabVIEW 20xx full time, and I'm not alone. So it isn't this year. πŸ™‚ But NXG releases full versions more than once per year. Right now, we (NI) aren't publishing a timeline for end of development of LabVIEW 20xx. We have a date we'd like to see, but it'll depend upon NXG code velocity and customer adoption rates. There are already customers who only work in NXG. Each customer will have a different key feature where they say, "Ok, NXG is ready for me." Eventually, it'll be the vast majority of our users. My hope is that we won't ever announce a planned end date. Instead, we will keep announcing how much more awesome NXG is than a few months ago. And, one day, you all will stop asking me for new features and I'll stop wanting to add them into LV 20xx because everything we need is over in NXG, and why would we stay in 20xx when that other platform has prettier graphics, and VIs that can't crosslink paths, and a reasonable componentization system, and Unicode support, and integrated hardware panels, much more impressive FPGA abilities, and Web integration, and... and that's all the stuff it already has today. NXG already is the platform I really want to be able to use for G. Someday, it'll be the platform I can use. On that day, you all won't care that I'm moving away from LV 20xx because you'll be already over there. And on that day, I'll make a choice: to either go join the NXG team (again -- I did develop on it for four years early on) or finally abandon text programming and become a full-time G programmer. The only thing I'll say about the roadmap is this: that day is coming. You tell us when.
  21. Another idea: Does the DLL possibly reach for some external resource, like a database or network connection? If that thing fails, maybe their error handling for the failure is poor, and all the EXEs would see the failure at roughly the same time.
  22. Another possibility is that the DLL creates a separate process to do some work and then communicates with that process... if that process is a single instance that all DLL instances talk to, that would be another way to get a crash like this. Look for another process appearing in your Task Manager right after you start the first copy of the app.
  23. Benoit: I just saw this post while hunting around for a bit of help myself. I looked at your VI. It's not a bug. You aren't ever setting the active element of the array -- the same physical position remains active unless you click with the mouse or use TAB key to move to the next element. To the best of my knowledge, there is no programmatic way to set the active physical slot of the array control other than simulating a mouse click or something exotic like that. The array control is not a particularly good control for UI, in case you hadn't noticed. It was never designed for a interactive front panel. The one in NXG is better.
  24. Does anyone have a picture showing how, given a VI, I can get ... ... the size of the monitor hosting that VI's panel... ... minus the taskbar size (if any) on that monitor... ... in a platform (OS) independent manner? I had a clean-but-annoying way to do this until I discovered that Windows10 has a mode that lets the task bar be replicated onto different monitors (and, worse, those taskbars aren't necessarily the same size). The only trick I can come up with is to maximize the panel momentarily and grab the panel size at that moment, but that creates flicker in the UI. Yes, I am aware of these two properties: They do not suffice. The first one gives all the monitor sizes without accounting for taskbar. The second one only reports taskbar on primary monitor. If I could be sure the taskbar was only ever on the primary monitor, I can figure it out from this info, but discovering taskbars on multiple monitors was an option throws a wrench in that plan.
  • Create New...

Important Information

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