Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Today
  3. You found the solution! Actually, the Facade vi runs transparent by default. If I unselect 'Window runs transparently' in the Custom Window Appearance dialog, it works as expected. No workarounds using tab controls/background images necessary
  4. I think I've come across something similar with named clusters and am not sure what the behaviour should be (but with events). The behaviour is difficult to describe but I'll have a go. I have this setup. I'm not sure how the name "Data" is chosen for the scaler type name, but it's the name of the event terminal on the VIM so that makes sense if you have to call it something. Deleting the Uint32 wire and wiring the cluster works sort of as expected with the ""Data" changing to "String" (i.e. one of the cluster elements). Popping up on the event data terminal reveals both cluster elements (String and UInt32). So far so good. Deleting the cluster wire and reattaching the Uint32 however doesn't change the event data terminal (remains as "String")and the VI is broken. BUT, popping up on the terminal shows the correct data type in the menu, which can be selected, and the VI is once again not broken. Note also that replacing the VIM yields the correct event data terminal type (called "Data"). OK. Not really a problem, but unexpected. So. Reattaching the cluster we get back to the second image (event data terminal is "String") as before. Now I change the cluster element name from "String" to "Value". But the event data terminal doesn't change, it remains as "String". The VI is not broken and popping up on it reveals the previous items "String" and "Uin32". The name change hasn't propagated nor can it be selected from the popup menu. It is recoverable, though although I'm not sure what would happen if I tried to generate the event with a string named "Value". Deleting the cluster wire and reattaching causes it to appear in the menu popup (broken VI with "String" as the event data terminal) so selecting it brings us back to a functioning VI. However. If instead of just deleting the wire, the VIM is replaced completely, then everything changes as I would expect (the "String" event data terminal changes to "Value" and the VI is unbroken with the correct popup menu entries). Arguably just a another example of "left handed scissors" but the cluster name selection and propagation strikes me as another manifestation of what drjdpowell is describing. srevent.vim
  5. Yesterday
  6. Just because you refactor something doesn't make it a "new feature". And just because something is buggy, doesn't mean the the bug-fixed feature is different. The history is laid out in the thread I linked including discussion about the ""Type Enabled Structure" (which, although buggy; appeared in LV 2016, IIRC) and some thoughts on addressing our requests for usage by JeffK (including polymorphic VIs). Even the file extension has remained the same (shouldn't it now be MVI?). I would accept it as being a "newly supported feature" from 2017 onwards, though. It wasn't a joke but now you just seem to be gaslighting us. Malleable VIs are clearly the productionised implementation of VI Macros and I doubt "Malleable VIs" would exist without us discovering VIMs and discussing it here (they'd been around since about 8.2). That's not to be dismissive of all the work that has gone into getting them working properly - which is undoubtably immense - but some of us are just getting round to using the "Malleable VIs" in anger and of course the first thing we will do is go back to the code that we wrote for VIMs to find out any new limitations and what's been fixed.
  7. Not exactly LabVIEW related, but an interesting related read anyway. How Diablo was reverse engineered.
  8. Major differences: One was an off-the-cuff prototype that frequently crashed, couldn't nest properly, had no well-defined recompile semantics (so you couldn't trust that if you made a change the callers saw it), and didn't integrate with any of the rest of LabVIEW features except by accident (and, in the case of polyVIs, that accidental interaction was a bug). The other is an actual feature. I don't think we retained any of the original code. Comparing them, especially in the context of complaining about loss of functionality, spreads disinformation to anyone who doesn't know the background history. If you meant it as a joke, you forgot your </joke> tags. I did not find your semantic antics amusing.
  9. I do not think that XControls draw their pane, that would become quite the pain when placing them on different front panels with different colors. What I would do is place a single page tab control on the facade (hide the tabs) and put your other controls on it. Control the background color using the FGColor property of the Tab control.
  10. That looks right to me. I don't know why it wouldn't work.
  11. Good point... I'm not sure. It's implemented like this: If this is incorrect, how can I get the reference to the actual clone?
  12. This reminded me of this idea exchange thread: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Offline-Distribution-for-Real-Time-Application/idi-p/1415250 Sure, the fact that the offline installers idea was marked as in development due to SystemLink is probably just because someone though it might accidentally be a solution for that too, but in general it seems to me that NI is designing more and more "left-handed scissors features" 😞 (SystemLink Cloud is by the way is so crippled compared to the stand-alone solution that you cannot use it for trending data for different customers (Access control on tag groups is not available, only on applications for example). To get enough access control you have to create your own SystemLink servers for each customer and get those online yourself (no cloud hosting of those at the click of a button from NI). And if you need to do regular analysis on the incoming data in SystemLink you cannot insert a set of VIs to do that, no - you need Diadem or resort to python (because "Diadem is much more powerful than LabVIEW" (!))...)
  13. Are you sure you are referencing the right clone of your facade vi? A common error I've seen is to get a reference to the master copy of a reentrant vi and not to the actual clone in use. How are you getting your reference.
  14. Thanks, but that's not quite what I meant. I would like to change the color of the XControl based on the state of it. E.g. If True -> Set color green, if False -> Set color red. If I understood you correctly, by setting a transparent pane color, I just get the color of the frontpanel on which the XControl is placed. It looks like the pane color of XControls is a static property, not writable at runtime. However, I could not find any documentation on this restriction...
  15. Yes. It's a distinction without a difference. GregSands found it, the community investigated it and malleable VIs were the productionisation of it.
  16. I don't really think the metaphor matches. Left handed scissors are obviously intended for we 10% and are marked as such. In your examples, its not clear who xctrls and ppls were designed for, nor what "using as intended" actually means. In contrast: left- and right-handed knives. They do this fun thing where they just steadily slide outward and make all your cuts super weird if you're using the wrong hand, but they still kinda cut so its very non-obvious. Its funny to watch, and its not really marked unless you look carefully at the edge, and you also have to know that you were supposed to look and check the edge in the first place, which many many people do not. And then if the knife slides off the edge of what you're cutting, you might just cut right into your hand. This seems like a more fitting analogy to xcontrols, myself
  17. Good find! @Jim Kring happy to assist in any way I can when you're looking into this bug.
  18. Labview exists for decades. It had thousands of releases. When was the last time NI left debug symbols by mistake? How to recognize a release with debug symbols left: - Nowadays Visual Studio keeps the symbols in a PDB file - so probably lvrt.pdb, but it might also have different name - depends on whether the DLL is renamed after build. - Previously, up to around year 2000, debug symbols were stored in the EXE/DLL - so lvrt.dll file size would be extraordinarily large, circa 2x-3x the normal size - Most compilers can also generate MAP file - it doesn't store as much as full debug symbols do, but has all global variables and functions named - which is still way more than nothing
  19. @ShaunR: Were you referring to VI Macros when you mentioned LV 2009?
  20. Last week
  21. Malleable VIs didn't exist in 2009. They were new in 2017.
  22. Funny thing... most people use winding can openers wrong, even when they're designed for the correct hand. The intended use of the winding can openers is to open the outside of the can, not the inner edge. If used the intended way, there are way fewer problems with the cans. The usability of can openers is a fascinating metaphor all on its own. 🙂 https://www.insider.com/right-way-to-use-a-can-opener-2018-8
  23. Part of these is the Macintosh legacy. You could make a case that Microsoft is at fault as they had to invent differences to the Mac, either for the sake of being different or maybe also to not give to much fodder for a court case about plagiarizsme.
  24. As a lefty, don't even get me started on can openers.
  25. Both of those technlogies are half-way houses to the real requirements. I think that's why they are left-handed scissors (when the requirement was a guillotine). LLBs are far better than PPLs, they just don't have namespacing and how does NI actually create new controls? I like the term, though. I wouldn't knowingly buy left handed scissors and if I accidently did, I'm more likely use them purely as a prank. Perhaps extend the notion. A left-hand drive car where one drives on the left side of the road - can't see what's on-coming when you overtake but when something does; it's a disaster. Just never overtake.
  26. At the risk of sounding petty: I am using Windows, so the first thing that comes to mind are the GUI Conventions: LabVIEW Undo is ctrl+z, LabVIEW Redo is ctrl+shift+z, while Window's Redo is ctrl+y. There are many more such (minor) design choices. The application should use the OS conventions, not force its own way. And, as an ambidextrous person, Scissors should be designed for both hands.
  27. Lately, I've been using a phrase "oh, that's a left-handed scissors feature." I've found it to be a useful concept, so I'm posting it here to the LV community generally. When software engineers create software, we aim to create software that is usable by our customers. To use the colloquialism: the software should delight the user. We sometimes miss. But just because the software isn't designed as the user expects does not mean that it wasn't designed somehow. Often, I find myself fighting my tools (Visual Studio, Perforce, web browser, operating system, etc.) because it just isn't doing what I expect, and I'm constantly working around some issue. I've realized that sometimes, if I stop and think about how the software is designed, I can use the system the way it was intended, not the way I want to use it. I'm still not happy, but I'm working a lot less and hurting less. I've begun referring to such designs as "left-handed scissors". Sure, 90% of humans are right-handed, and, since there's only one pair of scissors, the scissors should have been designed to be right-handed. Or the system should let you configure left-or-right. Something should be different! But it isn't different. So as a user, I have a choice -- to hold the scissors in my right hand and try cutting or to hold the scissors in my left-hand and try cutting. I can fight the system and stress my hands and make the software work, damnit, using my right-hand, or I can use the left-hand. Using my left hand, I'm still having to work harder than I'd like, but at least the edges aren't digging into my fingers. There are features in LabVIEW that are left-handed scissors. We -- LabVIEW R&D -- should have done something different. You know that; we know that (now). But the decision was made, and there hasn't been developer bandwidth to fix it. And it sucks. But it can suck a lot or it can suck a little, depending upon whether or not you acknowledge that it was designed for the wrong hand. Packed project libraries are left-handed scissors. XControls are left-handed scissors. There's others, but those are the two big ones that I most commonly have to help customers with. Both are great features if you use them as intended. But no one wants to use them as intended... we all want to use them in ways that they just don't want to be used. They can do the job that we want them to do, just not in the way we want them to do it. In the case of XControls, you have less pain if you just accept the frustrating event model that they're predicated on. In the case of packed project libraries, you have less pain if you just accept the limitations of their dependency paths and design build specs accordingly. I'm not going into either of those statements in this post... I and others have talked about both in various other forums. My point here is to coin a phrase that I've found useful. And if you hear me talking about left-handed scissors, now you know my intended meaning. 🙂
  28. Hi everyone, I was forced to insert google (or equivalent) maps in a project and, for some time, I used Mohammad Garousi version (that I found the most complete version freely available on the web). It uses the GMap.NET dlls. After some time I noticed a recurring random issue at dll level, after which a red cross appears in the .net container without any chance to correct or avoid the error. After some time I decided to create a new map container that might solve the issue. I decided to use a picture instead of the .net container. I was able to add new functions too, like creating a route, customize its behavior (such as changing the route color to spectrum), or add another image moving with map position or zoom change and so over. The result is attached below. This is a full-working example that can be studied or modified at will, but still a demo and not a library or final release. User can move map dragging it inside the picture, can zoom with the slider and so on. Coordinates and cursor positions are updated live any time the cursor is in the picture area. You can draw a route enabling the draw button. Remember to set it off when drawing is over. You can add a third party image (the default one is a drone image) in the picture 0,0 position. You can easily customize the default position acting on the block diagram code. Any time you set the image button to on, the image will be placed to the 0,0 position, recalculating its latitude-longitude coordinates. You can dynamically change map representation, route color or zoom. I hope this example can be useful for those who need a more stable GIS representation. If any issues are discovered, please contact me. Bye Flavio LabGIS.rar
  29. It looks like the issue is putting nested VIMs in a class. See https://forums.jki.net/topic/2641-vi-calling-vim-fails-to-build-fixed-in-vipm-2017f1/ and https://forums.ni.com/t5/LabVIEW/VI-Package-Manager-Fails-to-Build-with-Malleable-VIs-VIMs/td-p/3871468. @Jim Kring If you are still looking for a simple reproducing case of this bug, here is one.
  1. Load more activity
×
×
  • Create New...

Important Information

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