
paul_cardinale
Members-
Posts
70 -
Joined
-
Last visited
-
Days Won
10
paul_cardinale last won the day on May 17 2021
paul_cardinale had the most liked content!
Profile Information
-
Gender
Male
-
Location
California
LabVIEW Information
-
Version
LabVIEW 2018
-
Since
1990
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
paul_cardinale's Achievements
-
After a lot of digging, I found the bug (in my code). It wasn't happening just when one Y Control depended on another, but whenever two different types of Y Control were both in memory. The fix is attached. I've also done a bit of cleanup (including closing a dangling VI ref), and some minor improvements of the help. It's backward compatible; no need to rebuild anything, just run the new installer. Y Controls - Version 2.0.3.0 Source.zip Y Controls Support - Version 2.0.3.0 Installer.zip
-
I've discovered a bug. It appears to be a bug in LabVIEW. Here is what I believe is happening: Hiding inside each instance of a Y Control is an instance of "C: ... \LabVIEW xxxx\resource\plugins\Y Control\Ability Manager\Y Control Ability Manager.XCTL". When LabVIEW loads an instance of a Y Control that depends* upon another Y Control, there are 2 instances of "Y Control Ability Manager.XCTL" that need to be initialized: One for the outer Y Control and one for the inner Y Control. The "Init" ability of the Xctl for the inner Y Control gets called first, and it works OK. However when the "Init" ability is called for the outer Y Control, it is passed the wrong refnum: Instead of getting the refnum to the instance of the Xctl in the outer Y Control, it gets a refnum to the instance of the Xctl in the inner Y Control. *In my case this happens because I have a Y Control calls a dialog VI that contains a reference to a VI that has a Y Control.
-
-
Here is the fixed version (also a bit of cleanup and some tweaks to the help. Unfortunately you will have to recreate your Y Controls (but if you really need to keep any that you made with V2.0.1.0 or V2.0.0.0, contact me and I'll help you. Y Controls Support - Version 2.0.2.0 Installer.zip Y Controls - Version 2.0.2.0 Source.zip
-
Hold off on using those. New bugs have been reported. I'll have an updated version soon.
-
Here is version 2. As far as I know, there are no issues with it Requires LabVIEW 2019 or later. Not compatible with earlier versions. Y Controls Support - Version 2.0.0.0 Installer.zip Y Controls - Version 2.0.0.0 Source.zip
-
Programmatically Set a Property Item
paul_cardinale replied to paul_cardinale's topic in VI Scripting
The SetProperty method still doesn't support dotted property names in LV 2020. Using the attached VI will allow for a smooth transition if SetProperty is every upgraded. Set Property Item.vi -
Based on the lack of feedback, I infer that there's little or no interest. But I've been using Y Controls, finding issues, and fixing them. Since no one else appears to have been participating, I haven't concerned myself with backward compatibility, I'm getting close to sharing a new version. Anything made with the old version will be broken.
-
This is a named unbundler for clusters; but instead of taking in a cluster value and outputting element values, it takes in a reference to a cluster and outputs references to elements. Sadly, it can't handle a cluster containing a latching boolean. Unbundle Refs By Name_xnode 1_0_0_1.zip
- 1 reply
-
- 1
-
-
Can you send me the entire Y Control?
-
Quite a few changes: Cleanup, bug fixes, and kludges to workaround a bug in LV 2018 and earlier (but the installer is smart enough not to include the kludges when installed with LV 2019 +). If you've made any Y Controls with the prev version, you'll need to remake them. Y Controls Version 1.0.0.3 Source.zip Y Controls Support Version 1.0.0.3 Installer.zip
-
Here's another one: If the owning VI is set to run when opened, it will start running before the Y Control finishes initializing. (I might have to do some major surgery to resolve this.)
-
Is anyone else running into bugs? This one is driving me nuts: If the owning VI is a member of a library, and the library is open, then the event handler usually doesn't launch.
-
Perhaps this is the problem: When changes are made to LV help, they don't take effect until LV is restarted, I'll improve the completion dialog for the installer.