paul_cardinale

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.

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

Uninstall deletes "C:\ ... National Instruments\LabVIEW nnnn\resource\plugins\Y Control\*", "C:\ ... National Instruments\LabVIEW nnnn\help\Y Control\Y Controls.chm", and removes the Y Control from "C:\ ... National Instruments\LabVIEW nnnn\resource\plugins\NewDialogFiles\ LVNewDialog.xml". Is the installer creating "C:\ ... National Instruments\LabVIEW nnnn\help\Y Control\Y Controls.chm" for you? Y Controls.chm

There were some missing dependencies in the source zip. I also renamed a library to make name collisions less likely. Y Controls Support Version 1.0.0.2 Installer.zip Y Controls Version 1.0.0.2 Source.zip

Perhaps you might find this useful. Update File_New.zip

That issue has been corrected (see attached files). However it won't fix already-created Y Controls. To fix them, make sure that Facade.ctl and the .yctl file are set as "TypeDef" and not "Strict TypeDef" Other improvements: The installer and uninstaller will ignore RO status of an existing installation of Y Controls. The wizard fixes up the label of the cluster in the .yctl file. Y Controls Support Version 1.0.0.1 Installer.zip Y Controls Version 1.0.0.1 Source.zip

I've made some minor improvements. Is anyone interested?

Unzip the installer, read the READ ME, run the installer, read the help (LabVIEW -> Menu -> Help -> Y Controls). If you're curious, look in the source. Y Controls Support Version 1.0.0.1 Installer.zip Y Controls Version 1.0.0.1 Source.zip

I managed to post the issue there, but it's very cumbersome because I only get one post per password reset (and their Contact Us link is broken). I did get a reply and was able to solve that problem, but now it throws error 1357. Maybe it's time to throw in the towel on VIPM.

Gee, I put all my ideas into Y Controls. Attached is my help file (still under construction) for Y Controls. Y Controls.chm

I've been developing it alone, but I'll take any help I can get.

Sometimes I get this (which makes no sense because that VI is not a dependency of Y Controls, and it is not missing)

I have invented Y Controls and I am trying to create a VI Package for installing them. I would like it to result in "Y Control" being an option when selecting File -> New from the LabVIEW menu. But my .vipb file doesn't seem to do anything; no output, no errors, just a big NOP. Any help would be appreciated. Y Controls.zip

The Mac equivalent of LabVIEW.ini is at: <volume> / Users / <username> / Library / Preferences / LabVIEW.app 20xx 64-bit Preferences You can edit it directly.

I just came across this: Apparently there's an XNode developers forum somewhere.

That's my point. No XControls, no physical quantities. If LV 20xxis abandoned I'm doomed!

1. I like to use physical quantities when the values represent physical quantities (such as is common with device drivers). 2. When the code to run a control starts getting complicated, and the owning VI is already complicated, I like to encapsulate the code that runs the control into an XControl. Am I doomed?

Ok. As an alternative, is there a way to get the tab key to function as a tool selector on a block diagram that's in a SubPanel of a running VI? (It seems that the VI that owns the SubPanel is swallowing the keystrokes).

I want to turn AutoTool on. Shift-Tab toggles AutoTool on/off. That would be useful if there is a way to check the state of AutoTool.

Is it possible to programmatically change the inheritance of a LV class?

I'm working on a test executive framework (for both test execution and development). The test step editor places the block diagram of a test wrapper VI in a SubPanel. It works fine, but when the framework is running, within that panel, you can't change tools by tabbing. I want the test executive to turn on AutoTool selection so the test engineers using it won't have to.

Thanks for the reply. Close, but that will just toggle the state. I need to set the state to ON.