Y Controls

[GuenterMueller]

That was a short while to fix this issue, Paul.  I can confirm:  This issue is gone. 

Now I observe the application (not the source) consumes one CPU and is unresponsive:  I cannot operate on any control.  The "Panel Close?" filter event does not work, either.  Luckily, the application shows the toolbar with the abort button:  This allows me to abort.  After a short period the Event Handler shows a message, that the control has gone idle.

I have not checked thoroughly if this is caused by my code.  As you have provided this immediate fix, I wanted to give almost immediate feedback.  I will now turn back to my current construction area and check my code later.

[paul_cardinale]

---

@GuenterMueller wrote:

That was a short while to fix this issue, Paul.  I can confirm:  This issue is gone. 

Now I observe the application (not the source) consumes one CPU and is unresponsive:  I cannot operate on any control.  The "Panel Close?" filter event does not work, either.  Luckily, the application shows the toolbar with the abort button:  This allows me to abort.  After a short period the Event Handler shows a message, that the control has gone idle.

I have not checked thoroughly if this is caused by my code.  As you have provided this immediate fix, I wanted to give almost immediate feedback.  I will now turn back to my current construction area and check my code later.

---

I'm working on it.  Unfortunately you will have to recreate your Y Control(s) after I fix this.

Here's what's happening: The Init ability of "Y Control Ability Manager.XCTL" calls your Y Control's event handler so the default value can be processed when the owning VI is loaded.  At that time, when in the dev environment, when the event handler tries to register events, it gets an error because the owning VI isn't running yet and it uses that error to "know" that it's just supposed to process the data change and exit.  But when compiled, the owning VI is already running at that time, so instead of exiting right away, it runs it's GUI loop.  This prevents the Init ability (of "Y Control Ability Manager.XCTL") from completing and causes the lockup.  The fix involves changes to the "Y Control Ability Manager.XCTL"'s Init ability and changes to the template for the Y Control's "Event Handler.vi" (which is why you'll need to recreate your Y Control).  (I also have to wait until my access is restored to our source control server.)

[paul_cardinale]

---

@GuenterMueller wrote:

That was a short while to fix this issue, Paul.  I can confirm:  This issue is gone. 

Now I observe the application (not the source) consumes one CPU and is unresponsive:  I cannot operate on any control.  The "Panel Close?" filter event does not work, either.  Luckily, the application shows the toolbar with the abort button:  This allows me to abort.  After a short period the Event Handler shows a message, that the control has gone idle.

I have not checked thoroughly if this is caused by my code.  As you have provided this immediate fix, I wanted to give almost immediate feedback.  I will now turn back to my current construction area and check my code later.

---

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.

[GuenterMueller]

Yes, Paul: That's it.  A short test shows:  I cannot find any issues with a built application.  It starts without any noise, it behaves as expected and there is no noise when exiting the application - with noise meaning any dialog that might have appeared.

Thanks for offering help in rebuilding a control:  My only starter contains four controls:  One Color Box and the components R, G and B.  They always stay synchronised when operating on any of them.  This is not that sophisticated that I have to ask for help.

It's time to think about a license for your code, Paul.

I will continue playing with my code and give further feedback in case issues should arise.

[paul_cardinale]

I've discovered a bug: When code inside a Y Control references code that depends upon another Y Control, things can go haywire (a reference which is supposed to be for one Y Control is actually pointing to the other).  It will take me some time to figure this out.

[paul_cardinale]

This 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.

[paul_cardinale]

After a lot of digging and this:

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.

[paul_cardinale]

 A couple of my "minor" changes caused problems with the Wizard and the buildspec for the Installer.  Here are the fixes.

[nanocyte]

I have a bit of feedback. I'd be happy to take this offline or to another thread if that's easier.

1. I need a little more edit time magic. I wanted some way of seeing what the control would look like in place without having to run the caller. I'm thinking a shortcut menu plug-in might be a good fit.
2. Can you separate compiled code for everything
3. There were some hidden controls in the .yctl that made making a transparent control frustrating. Some of this frustration is with NI and the inability to set borders transparent. I think what I need is a seamless way to make things easy to click on at "edit" time and then more seamless and clean after you "publish" or "finalize" your control.

[paul_cardinale]

---

@nanocyte wrote:

I have a bit of feedback. I'd be happy to take this offline or to another thread if that's easier.

1. I need a little more edit time magic. I wanted some way of seeing what the control would look like in place without having to run the caller. I'm thinking a shortcut menu plug-in might be a good fit.
2. Can you separate compiled code for everything
3. There were some hidden controls in the .yctl that made making a transparent control frustrating. Some of this frustration is with NI and the inability to set borders transparent. I think what I need is a seamless way to make things easy to click on at "edit" time and then more seamless and clean after you "publish" or "finalize" your control.

---

1.  I'll look into it.

2. Why?

3. By "making a transparent control" do you mean setting the "Visible" property to False, or do you mean setting the color of all of the pieces of the control to transparent?