paul_cardinale

Is there really a menu command that would invoke the font dialog?

What would it be?

Do you know of a way to invoke the font dialog?

This seems to work OK.  But the Mac version is rather slow.

Get Font Names.vi

Unfortunately, "Get Font Names.vi" doesn't work properly on a Mac: The list returned includes names of fonts that aren't available, and is missing some that are available.

Here's what I came up with.  Don't know if the Unix target works.

Get Font Names.vi

Aggg!  I can't remember how to get a snippet from LAVAG.  What's the trick?

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

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 hour ago, X___ said:

LV 2019 SP1f1 64 bit crashed upon closing my first Y Control... but seems to have recovered fine.

So, I can now resize objects within a Y Control cluster, but there seems to be a glitch (race conditions?) in the Process New Value.vi:

When the user changes the checkbox (for visibility) to True, the string is hidden and reciprocally. Am I missing something?

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.

12 hours ago, X___ said:

1. I removed LVNewDialog.xml before re-installing 1.0.0.2 and got this:

which, after I pressed continued, left the installer window opened in a stopped state, but at least now the help is back in the menu (but in Help>>Y Control, not Help -> New -> Y Control as you have it in the Readme.txt)

However, the File>>New... dialog is now empty, so removing LVNewDialog.xml is definitely not the thing to do (putting it back resolves the issue but is missing the Y Control item).

2. Re-uninstalling Y Control Support now LEAVES the Help >> Y Control menu but nothing happens when selecting it:

3. Re-reinstalling 1.0.0.2 restores the Y Control item in the New... dialog box...but removes the Help menu!

Getting somewhere?

Is the installer creating "C:\ ...  National Instruments\LabVIEW nnnn\help\Y Control\Y Controls.chm" for you?