But there is no front panel connection with an XNode. XNodes are great for making a single thing on the block diagram do different things and encapsulate functionality in it. I don't think XNodes would help with this. (And I don't mean empty clusters or void arrays.) Incidentally an uninitialized plug-in control is the only way I know of to get a control with "void" as its type. You can place it via my Place by Style Quick Drop plugin. I already know how you would load a control from a DLL: there's a hidden "Plug-In Control" object that, when placed via scripting or a modified palette, allows you to load a DLL from the context menu. I've actually been meaning to see if I can figure that out, lol. Also I'd like something I can put in an array or cluster XControls can't do that and I don't think QControls can either. Yeah but I want the best of both worlds, extending existing controls while also being able to use it via just a block diagram terminal. Sounds like that might be right up your street NI can also have some DLL controls using a completely undocumented API. Instead, we got xcontrols (xcontrols do a lot of what you are asking for, by the way.
We've been asking for that since about LabVIEW 6. I see it has a place, but it doesn't seem to be a replacement for xControls.
But It wouldn't have been much use for my Tab Control as that needs edit time capabilities and doesn't inherit from any existing control. It would have been useful for my Markup String xControl if a little unweildy for the end user (they would have had to have init and deinit Vis and an event structure instead of just placing a control). There are no edit time capabilities and it isn't encapsulated like an xcontrol. I think rather than thinking as it being an alternative. They do but it's really only a wizard that takes the grunt work out of creating the properties and methods yourself (something xControls could have done and probably still could do). Politically and strategically no.Ī hooovahh said. For this reason and this reason alone I am skeptical and pessimistic. I have the feeling NI might use this as an excuse to see their promise of extendible FP controls as being fulfilled. We were promised that NXG would get exactly this kind of extensibility, but having heard nothing more on it (and a few rumours to the contrary, I fear the worst). Correct me if I'm wrong, but I don't think QControls do either. Just being able to extend a String control to allow for a dictionary should be possible without it being distinguishable from a "normal" String control on the FP or BD (Perhaps for some identification on the BD of it being an extended control).
In end effect what we need is the ability to actually inherit from existing controls in order to extend their functionality.
0 kommentar(er)
