How about allowing the creation of XControl classes?
Families of XControl classes would allow the Publish / Subscribe paradigm I'm struggling with as discussed here: http://forums.ni.com/t5/LabVIEW/XControl-publish-subscribe/m-p/1568958
Being derived from a common ancestor client, XControls could be managed in a collection (array) and the publisher could call a common or overidden class method for each XControl client in the list.
XControl classes would also allow an elegant implementation of the Model View Controller paradigm used extensively by other object oriented languages.
You should also allow XControls to be members of an existing class. That way the XControl would gain access to the member variables of the class without resorting to cumbersome accessor vi's.
XControls sub-classes of a class should also be allowed, then methods in the parent could be overidden in the XControl. Mediator objects can then call class methods without caring if the instance is a XControl View, Model, Controller or some other object.
Phill
National Instruments will not be implementing this idea. There is no further feature development planned for XControls.