Jump to content

Aristos Queue

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Aristos Queue

  1. MartinD: no, nothing wrong with that, but I usually only use that approach when the value is a computed value that needs different data storage. For example, “determinant” of a matrix... sparse matrix and dense matrix have different data storage, and determinant is computed differently for each type. But it works fine in your case, too. It’s nice if some classes have it as a variable (gets stored per object), but other classes it is constant for all objects of the class, so the method can just return a constant and not burden every object with that bit of data.
  2. Honestly, I have no idea if that’s something that is even logically possible. Computing data flow from procedural instructions is one of the holy grails of compiler optimization. Sure, there’s short segments that are easy to translate back, but a general app? Maybe, but I have 19 years of LabVIEW R&D experience with the compiler, and I’d be hard pressed to do it by hand, much less derive a general algorithm for automatic decompilation.
  3. I pro-indicate them (opposite of contraindicate?) because despite some issues over the years, they have some abilities that nothing else in LV replicates, and I've learned where the rough edges are. There are some really sophisticated tools that can be built from these controls (even the Q Controls can't help out while editing). I've built multiple XControls that work just fine in built apps and large projects. YMMV.
  4. Someday, I really would like to take two months off of my main dev job to sit down with the developers of some app that uses all this ref stuff and really tear it apart. I've gone through smaller apps and been able to eliminate most of the references, achieving much better performance -- often with a significant decrease in memory and usually fixing a couple of race conditions along the way! But that's only for small apps, which leaves my theory that the big apps would be better off without the ref aspects as just that: a theory. I don't just need my time... I'd also need the time of the large app's developer(s) to provide the handholding to do the analysis. The work I did with Allen Smith on the AF was this weird moment of downtime for me at NI between two major projects, something that doesn't come around often. Until that next magical gap in my schedule, I'm just going to look at diagrams like the ones above and wince, whispering quietly, "We gotta find a better way..."
  5. PS: ShaunR's new XControl is pretty nifty.
  6. The rusty nails are never-released features that aren't supported. XControls very much are supported and are useful, just not as useful as we all wish they were. Big difference.
  7. @AbdulQuader As Rolf says: Yes. You can trivially build one just by building placeholder subVIs that either do nothing or return dummy data when called, and then fill in those subVIs with real hardware calls later. But more sophisticated simulations are very application specific. Unfortunately, there isn't (and cannot be) a general "HW simulator API". This guide to building a hardware abstraction layer may help you design one for yourself. Or it may not help -- the PDF is one that I've handed around to many users, and it's about 50/50 chance of people either happy it is so helpful or frustrated that it is so unclear. But maybe give it a chance. Good luck.
  8. @CheesyGC what is an example of "dynamically building a project" question? I can think of a few interpretations... dynamically loading modules/plugins or dynamically building the build specs. Both of those are pretty common (the latter is sufficiently common that NI just rolled out new CLI tools to support doing it).
  9. I think the XControl questions should stay. Any CLA should be able to recognize/use/edit an XControl because it is a part of the language, and not an obscure part (like, for example, "Enable Database" on a subVI). They do have real uses. For me, they're the best way to put a UI element together to display a LV class. We are still years away from a general user-base migration to NXG -- I think it is too soon to be making those arguments (as a counterargument, I think CLAs should know what scripting is, even though most scripting functions are not going to migrate to NXG). (The exact number of questions is open to discussion... I'm only opposing a blanket elimination.)
  10. Copy cannot be auto-generated because your object might contain references and the copy routine has to decide whether to share or clone the references. Mikael’s answer is best. Obviously if the parent class doesn’t have a Clone method, then you cannot add one to the child.
  11. Call change to constant afterward if it matters to you (nearly zero effect on generated code since Open VI Ref cannot be constant folded). But (I’m not at machine right now) it would surprise me if that same property weren’t on the constant. You should check To get the conpane of a VI: https://zone.ni.com/reference/en-XX/help/371361R-01/lvscript/vi_connector_pane058datatype/ Or use this method on App refnum if the VI is not in memory (it reads the conpane without loading the VI): https://zone.ni.com/reference/en-XX/help/371361R-01/lvscript/app_getviconpane_datatype/
  12. The method I think you’re looking for is this one: https://zone.ni.com/reference/en-XX/help/371361R-01/lvscript/virefnum_set_conpane/
  13. With our built-in controls, the problem is solved at the moment of selection. If the main part is selected (e.g. the LED part of a Boolean control) then all of the related parts are also selected. If a secondary part is selected (e.g. the label of the Boolean control) then only that part is selected. Thereafter, the rules of the selection list work as normal -- when you drag one item in a selection, all selected items move with it. This is what allows you to select the label of several different controls at once.
  14. LV 2019 augments the right-click menus for class wires/terminals to provide a method list you can drop, which should alleviate this issue. I found a way to make the right-click menu plug-in able to add the graphical palette menus and then built a right-click plug-in that builds the method palette on the fly if the class doesn't already have its own default palette.
  15. That is really weird. I haven't tried to replicate... not sure I'll have time for a while... but there's one odd thing to try... after the "Remove VI" call, try adding a "Wait MS" of about 100 milliseconds. I'm trying to come up with hypotheses that would cause this problem, and the only one I can think of is that the subpanel is opening its own reference to hold the panel in memory and that is (for some unknown reason) flagged to show the Save Changes dialog. I'm torn between hoping this works you around the bug and hoping that it has nothing to do with it.
  16. I got a PSE to work on this for a while this week. We couldn’t replicate the issue. It’s a pretty bad bug — wiping out the whole directory. If you have more explicit steps to reproduce, please consider filing a bug report with NI.
  17. If you open it with Open VI Ref and then close it before calling Close Reference, there shouldn't be a Save Changes dialog. The only way I replicate is if I leave the panel open after the VI finishes running and then the user closes that panel (which is correct behavior). Is that what you're doing?
  18. PS: Did I mention that the design of these things was arcane and bad? Yes? Ok. 'Cause it's true. I have a long list of lessons I hope NXG learns.
  19. XControls work just fine... if you dance with them the way they were intended. *head bang* If you don't want data to be saved, one way is to not put it in the State data. If you only need the data in the facade, add a shift register. But if you need it lots of places, put a global unique ID (GUID) in the XControl's state data, something that never changes after creation, and create an LV-2 style global with a lookup table from the unique ID to the data. You can create GUIDs on any LV OS using: LabVIEW 2017\resource\Framework\Providers\API\mxLvGenerateGuid.vi Changing the state shouldn't cause the VI to need to be saved unless it needs to be saved. So, yes, sure, in the IDE in a directly called VI, yes, changing state dirties the VI. But obviously that doesn't happen in a built app. AND, importantly, it doesn't happen in the IDE for any dynamically loaded VI (unless you are adding the 0x1 flag to track changes, in which case you get what you requested). If you're loading the hosted VI into a subpanel, that means you're working with it by VI Reference. So load it using Open VI Reference (without the flag) and the problem of being prompted to save should go away.
  20. @Yassamina BERKANE The answer is the same as it was in 2006: dequeue and concatenate. A ragged 2D array is not (and never will be) meaningful in LabVIEW. Because the compiler cannot guarantee that you're going to add arrays of all the same size to the queue (you might be doing that, but it cannot be proven from code because refnums can be shared all over the place), any attempt to ask for all the queue elements in one array will have them each wrapped in a cluster. If you dequeue and concatenate, you can build a 2D array yourself.
  21. Likewise -- I never heard of it; seems useful.
  22. I don't know of any hooks. That's not the same as saying they don't exist.
  23. No. Not all, and not any. There are some major bugs -- like the circular dependency bug with LV classes* -- but most of the issues people have with XControls are features, intended parts of the design. It's a bad design. Seemed like a good design when it was put together, and it does some things very well, but it's inflexible. When coupled with some of its loading idiosyncracies, it means that a lot of ultra complex XControls just don't work or require arcane code. But the issues are fundamental to how XControls are structured. Fixing them would not be backwardly compatible -- it essentially means rolling a new YControl (or whatever we name it) feature, and that's not on the docket for LV 20xx at this time. If XControls work for you, then they work. If they do not, they don't. I do not expect any shift in this in LV 20xx. * If loading your class loads an XControl into memory then you should take care that loading the XControl does not load the class into memory. Conversely, if loading an XControl causes a class to load into memory then you should take care that loading the class does not load the XControl. If you ever have an XControl that is circularly linked with any class, various forms of doom will come upon you, from random crashes to infinite hangs. It's a known issue with no way to resolve given the design of the XControls (the classes are just fine).
  24. There's no way my much smaller team will stay ahead of NXG for too long. My job is to make LV 20xx a product that you all want to keep buying and using until the day when you go, "You know, I'd rather use the new shiny." That's started to happen in some customer segments. It'll happen more and more over time. Since buying LV gets you both platforms for the same price, it's simply a question of when does the new platform have enough functionality for your particular work. NI has abandoned the goal of trying to get everyone swapped over as fast as possible and is instead focused on getting each piece of functionality right and moving customers over as they become viable. It's a much MUCH saner strategy.
  25. Ah. Ok. In that case, I believe you. I think it is possible through C#, but not easily.
  • Create New...

Important Information

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