How to keep types straight in PPLS

[CoastalMaineBird]

LV 2013

I'm fairly new to PPLs, so I may be missing something obvious, but I have a dilemma:

Suppose I have a TYPEDEFed ENUM - let's call it X.ctl

Suppose it's in a LVLIB called L.lvlib

That makes its full name into L.lvlib:X.ctl

Suppose I have code that makes a queue of these enums.  The queue data type is queue of L.lvlib:X.ctl

Suppose I put both those into a PPL called L.lvlibp

From outside the PPL, I see a control called L.lvlibp:X.ctl - it changed to the lvlibp version - Fine.

In some other code, I take this queue and add an ENQUEUE ELEMENT to it.

If I pop up on the input of that function and CREATE CONSTANT from it - the constant is BROKEN !

Why?  Because the data type of the queue is queue of L.lvlib:X.ctl, therefore data type of the constant is L.lvlib:X.ctl

IOW it did NOT get changed to queue of L.lvlibp:X.ctl - it is still queue of L.lvlib:X.ctl

If I place a copy of the  L.lvlibp:X.ctl myself, it's not broken,  but if I wire it to the ENQUEUE function, I get a COERCION dot - they are different types.

The code works just fine, but I don't like coercion dots unless explictly needed, and I certainly don't like broken constants.

What can I do to resolve this?

[CoastalMaineBird]

Here is a project to demonstrate this.

Open the USE THE QUEUE project, and open the USE THE QUEUE vi.

Pop up on the input of the ENQUEUE element, and CREATE CONSTANT - it's broken !

The other project shows how I built the PPL.

[CoastalMaineBird]

Up to the top for the weekday crowd...

[Norbert_B]

This rather looks like a bug to me.

I *think* to know why this is happening:

1. You obtain a queue using the development control X from L.lvlib. This will result in a typified queue of type "L.lvlib:X.ctl"

2. You create an indicator with QueueRefOut. The type will be L.lvlib:X.ctl.

3. You pack everything in the PPL. The constant for the Obtain Queue will be replaced by X.ctl inside the PPL. However, this is obviously NOT happening for the typified queue refnum.

4. Loading the PPL using the typified queue refnum "L.lvlib:X.ctl" will automatically search and load (if available) the original lvlib.

5. As your Enqueue is reading the type from the queue refnum, it will create a constant of type L.lvlib:X.ctl. If you load that control manually (unless automatically happened in 4), the VI would be executable.

Take Away:

The data type of the queue refnum is not correctly updated during the build process.

Possible workaround:

Wrap all queue operations (enqueue, dequeue, flush, ..) you need in the PPL as well and provide wrapper VIs using the data type control as parameter. These well be updated in the build process. I would expect the queue refnum still to be "incorrectly typed", but the coercion dots are now hidden in the VIs.

Norbert

[CoastalMaineBird]

So, it's not something I'm missing.

To work around it, I provide an ENQUEUE VI for the user to see.

This offers an L.lvlib:X.ctl control input, which will be updated in the build process to L.lvlibp:X.ctl

Any constant created from this will then be an instance of L.lvlibp:X.ctl

No problem there.  If they use a standard dequeue, an create a constant from that, it's broken.  So I have to either duplicate the DEQUEUE operation, or hope they don't create a constant from the output.

The same problem applies to EVENTS as well:

In the PPL, I might create an EVENT of type X.ctl.  If I register that event, the data that comes out of the event is  L.lvlib:X.ctl.

If I connect that data to something that uses a L.lvlibp:X.ctl, then it's type-coerced, or broken.

Yuck.

If I put the TypeDef into one PPL, and the queue-creator and event maker into another, which used the first, then that would work all the way around, I think.

Yuck again, though.

 Thanks, Norbert for spending a few brain cells on this one.

[Norbert_B]

Well, the underlying issue seems to be that AppBuilder does not update typified refnums (Queue, User Event, ..).

Your mentioned workaround with the type in another PPL would work because the type is already "correctly placed" when creating the refnum. So you would circumvent the need to update the refnum.

However, you would "stack" PPLs which can get quite tricky. That's why i share your "Yuck"....

Norbert

[CoastalMaineBird]

Not sure what you mean by "stacking" PPLs.

I already have about 30 PPLs.  I'm implementing an addon system, where the user can make an addon (PPL) and put it into a certain folder.

The main program then sees it and "attaches" it to the main, and they can share whatever is in the PPLs.

I know that I have to build the things in a certain order.  If X depends on Y, then I have to build Y first.  So far, I have no circles, just a straight line. 

Any other "gotchas" I should know about?

[Norbert_B]

The main pitfall when "stacking" PPLs is that during build process of the PPL, the dependent PPLs have to be either copied (and the code updated) or already in the correct place during development.

While this is not such a big problem anymore (AppBuilder got at least one useful configuration setting options here), it was in the beginning.

I think that you are already aware of this, but it always helps:

Packed Project Library Pitfalls

Norbert

[CoastalMaineBird]

I think that you are already aware of this,

Yes - the first question at the bottom of that article is from me about a year ago.

Thanks.

[Norbert_B]

Reading is a matter of luck. Sometimes 😄

However, the link still might be new for other reading this post.... i hope.

Anyhow, thinking of your setup, it might be useful to create a PPL for all type defs in case this situation you have is "regular"....

Norbert