Jump to content

XControls?


Recommended Posts

Ha! Only tried it once, for a kind of record-and-playback scrubber with multiple cursors, annotations, scroll bars, buttons, etc. I started with the XGrapher example on NI.com, which was nice. I soon made things more complicated than they needed to be. I mean, I soon realized that wasn't the best fit for an XControl.

Link to comment

First I thought A), then I switched to D) :yes:

 

XControls are great but they have their limitations. I've written some XControls over the years I don't want to miss anymore. But I also remember situations where subpanels did a better job and were easier to maintain. If you need the same custom control with some logic behind it frequently in your project then an XControl is probably a good choice.

Link to comment

Over the past 5 years, each year, approximately:

 

B -> C -> A -> B -> B

 

tl;dr -- does not solve sufficiently painful problems efficiently enough.

 

A few inconveniences that come to mind:

  1. Inability to designate an XControl as a view of an LVOOP class
  2. Inability to expose VI Server API of composed elements, other than through a naked ref getter on the XControl API, or re-implementing a wrapper
  3. Inability to override VI Server API methods/properties of composed elements
  4. Handler in Façade does not actively handle incoming User Events (just VI Server events)
  5. It feels like they were both released and EOL'd the same day (this is just perception, yet it plays a substantial role considering ROI in this technology)

They're still super cool, and I would not recommend against developing an XControl. (I've developed perhaps a dozen?) It's just one of those tools in the toolbox that's not rusty, yet not often reached for.

  • Like 1
Link to comment

My history with xcontrols is very similar to Jack's. Basically went full circle from "why would anyone ever use this?" to "Ok, this is pretty cool" then having learned of some key limitations or challenges I could not overcome without ditching the xcontrol idea completely, I'm now squarely in the "just no" category.

If I want a modular control, I now wrap it in a class and give it a method to attach it to a subpanel or other UI element it needs to function. Xcontrols are just too limiting and completely non-extensible. I will not be burned again by sinking my time into developing any more. I realize their uses, but I just don't think it's worth it even if you have a perfect use case because who knows what that use case will evolve into...

Jack hit many of the obstacles I ran into, and if I recall I also found quite a performance problem as well. I seem to remember a side by side comparison where I had identical code/functionality working in an xcontrol and a normal async vi + loop and the resulting xcontrol behavior was terrible due to what I can only assume is the overhead involved with whatever voodoo is done behind the scenes to wake that wannabe-but-totally-isn't-asynchronous facade.

Link to comment

I'm somewhere between A and D, but I have only felt the need to create a few controls (hmm, maybe I should replace "need" with "justification", thus making me a C?). I will certainly add to the others in saying that they don't feel fully baked, both in terms of functionality and ease of use, but I would still consider them as a viable tool (although that might just lead me to mje's position in the end if I run into the correct Xctl.). I will also add that resizing XControls can be a pain, as well as having pop up controls in them, because contained controls can't appear outside the bounds of the XControl.

Link to comment

B.

Too hard, too buggy, too limited and too slow.

 

X controls are the ActiveX of LabVIEW and I treat them with the same derision. We would be better off with NI just telling us how they create the real controls and be done with it (NI also have the capability for plug-in controls via DLLs which is completely undocumented).

Edited by ShaunR
  • Like 1
Link to comment
B.

Too hard, too buggy, too limited and too slow.

 

X controls are the ActiveX of LabVIEW and I treat them with the same derision. We would be better off with NI just telling us how they create the real controls and be done with it (NI also have the capability for plug-in controls via DLLs which is completely undocumented).

 

I haven't really looked at the current implementation of pluggin controls through DLLs but a quick glance at the IMAQ control made me believe that the DLL part is really just some form of template handler and the actual implementation is still compiled into the LabVIEW kernel. And changing that kernel is definitely not something that could be done by anyone outside the LabVIEW development team even if you had access to the source code.

 

In old days (V 3.x) LabVIEW had a different interface for external custom controls based on a special kind of CIN. It was based directly on installing a virtual method table for the control in question and this virtual method table was responsible to react to all kind of events like mouse clicks, drawing, etc. However since this virtual method table changed with every new LabVIEW version such controls would have been very difficult to allow to move up to a new LabVIEW version without recompile. Also the registration process of such controls was limited in that LabVIEW did only reserve a limited amount of slots in its global tables for such external plugin controls. It most likely was a proof of concept that wasn't maintained when LabVIEW extended that virtual method table to allow for new features like undo and what else in 4.0 and was completely axed in 5.0.

 

It required more or less the entire set of LabVIEW header files including the private headers in order to create such a control from C code. Also the only real documentation was supposedly the LabVIEW source code itself. I do believe that the Picture control started its initial life as such a control but quickly got incorporated as whole into the LabVIEW source code itself as it was much easier to maintain the code changes that each new LabVIEW version caused to the virtual table interface of all LabVIEW controls.

 

In short, writing custom controls based on a C(++) interface in LabVIEW while technically possible would require such a deep understanding of the LabVIEW internals that it seems highly unlikely that NI ever will consider that outside of some very closely supervised NDA with some very special parties. It would also require access to many LabVIEW internal manager APIs that are often not exported in any way on the C side of LabVIEW and only partly on the VI server interface. LabVIEW 3 and 4 did export quite a lot of low level C API manager calls such as text manager, graphic drawing, and window handling, which for a large part got completely removed in version 5 and 6 in favor of exporting more and more functionality through the newly added VI server interface on the diagram level.

Link to comment

Every now and then I try using an XControl.. and get annoyed by its limitations. Graph annotations is another example...

 

I just used the IP-address XControl here from the LAVA repository - it is a great use case, but the fact that you cannot tab out of this XControl like with other controls breaks the consistency of the GUI.

 

I have not tried to get around it by modifying the code, but found a page on ni.com that says it's not doable. Is that really the case? Silly...

Link to comment
Every now and then I try using an XControl.. and get annoyed by its limitations. Graph annotations is another example...

 

I just used the IP-address XControl here from the LAVA repository - it is a great use case, but the fact that you cannot tab out of this XControl like with other controls breaks the consistency of the GUI.

 

I have not tried to get around it by modifying the code, but found a page on ni.com that says it's not doable. Is that really the case? Silly...

 

Tabing navigation with XControl is really painful to implement, but it's doable. You can see an example with placeHolder Xcontrol here --> https://decibel.ni.com/content/docs/DOC-21668

I've posted an idea about this, but get not much kudos for :( --> http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-quot-Get-focus-quot-facade-VI-Event-to-XControl/idi-p/1482670

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.