Using a TypeDef as an XControl Data ctl

[robotics_chuck]

Just like a string control can have an input (if it's an indicator) or an output (if it's a control), an XControl can take <data> in or pass <data> out, where <data> is defind by the XControl's Data ctl file. For my particular application, I'm trying to refactor an array of hard-coded dialogs into a single customizeable dialog. My thought was that I'll create one TypeDef to have visibility, position/size information, text information, etc., and that data will be interpreted differently (text is text, or an image path, etc.) based on what that data is trying to control.

I also created a dialog builder that allows users to alter the dialog layout, and to support this I created a set of XControls that wrap the underlying TypeDef so instead of showing a string path the user gets a combo box of available files, or fields that aren't applicable to certain controls are hidden, etc. 

The problem I've got is that I can't use my underlying TypeDef in the XControl, because I get the error:

Type Definition 'Cluster': Invalid use of type definition in Control Editor

You cannot use a type definition in the Control Editor unless it is inside another control, such as a cluster or an array.

It looks like I have two options: 

1. I can put down a cluster and then drop my TypeDef into it, but then I can't pass my underlying TypeDef directly to the XControl, I have to Bundle By Name to put it into "Cluster.____" to pass it in and similarly unbundle by name to access the field, OR
2. I can recreate the TypeDef in the XControl's Data ctl. Doing this works, I can pass my underlying TypeDef directly in and receive it as an output, but poses two new problems:
   1. Changes to the underlying TypeDef are not reflected in the XControl data ctl files, and
   2. Anywhere I interact with the XControl I get a coercion dot.

I don't understand why I'm not allowed to use the TypeDef as the sole item in the XControl's Data ctl. If I delete everything and drop a String Control it's fine with a single control not in a cluster. If I have the TypeDef and right-click and "Disconnect from TypeDef" it's fine, because the TypeDef is already a cluster of individual controls. I also don't understand why the XControl can't just reference the existing TypeDef instead of needing to have its own TypeDef. 

I could go the other way, and use the XControl to define the TypeDef, but then I'm faced with the fact that I have several kinds of items I'm trying to control (images, buttons, inputs, etc.), and now I have to make everything that was referencing the single underlying TypeDef (like my XML read/write files) instead become malleable and accept all of the kinds of XControl Data fields, even though they're all identical. 

Am I missing something? I thought I had read something on Friday that said I *could* use a TypeDef instead of the XControl-specific Data ctl, but now of course I can't find anything that supports that. When I browse properties for the XControl I can see "Items," where the Data ctl is defined, but I can't edit any of the fields there and cannot select a different control to use.

[paul_a_cardinale]

I've been making an Express VI that's a Universal Dialog Box.

It generally works well, but I still need to fixup the localization.

If you like, I can send it to you.

[robotics_chuck]

No thanks; I've got a complete, working solution for the dialog that functions as-inteded for my organization. I'm looking for a solution to how I could use a typedef with an XControl that isn't the one that's auto-generated on creation. 

I tried opening the xctl in a text editor to manually change the reference to my TypeDef and everything loaded, but the XControl was broken because the Facade VI's reference to the Data typedef was broken, and I could not fix that with a text editor.

Right now it looks like this isn't possible. Mine appears to be a niche use case, where I want the same underlying type represented several different ways. For future visitors coming to this thread, the most straightforward thing to do is probably to use the XControl's typedef in place of your other typedef, such that the sole typedef is the one defined inside the XControl. 

Another concept brought up by a colleague that I didn't try is to consider using a class to wrap the typedef. As a quick proof-of-concept, this does seem to work - you can drop the *class* in as the sole item in the XControl's Data typedef, and so this should then work as an input and output. For me at the moment, though, this would be re-threading new classes through all of my existing infrastructure, which would be a significant change. 

My workaround today is going to be to create a set of converter VIs that un/bundle by name to convert between the XControl's typedef and the typedef that everything else uses, with comments blocks in both typedefs referencing the converters would need to be updated if the typdef changes. I'll create small icons and put those converters before/after any interaction with my XControls. This is the most minimally invasive for what I'm trying to do today. 

[paul_a_cardinale]

Use caution when putting classes inside XControls.  They often don't play well together.

Note that if, in your XControl's data typedef, you put a cluster, then put your typedef in the cluster,  you can use the simple "Bundle" and "Unbundle" functions; you don't need the "by Name" versions.