drjdpowell Posted April 20, 2013 Report Share Posted April 20, 2013 XControls? A) Yes B) No C) <Head banging against wall> Thump…Thump…Thump... D) All of the above Quote Link to comment
todd Posted April 20, 2013 Report Share Posted April 20, 2013 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. Quote Link to comment
candidus Posted April 20, 2013 Report Share Posted April 20, 2013 First I thought A), then I switched to D) 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. Quote Link to comment
Antoine Chalons Posted April 20, 2013 Report Share Posted April 20, 2013 A, incredibly helpful for making custom probes. Quote Link to comment
drjdpowell Posted April 20, 2013 Author Report Share Posted April 20, 2013 I’m sort of A, but the large amount of C involved makes me consider B. Thus: D. 1 Quote Link to comment
JackDunaway Posted April 20, 2013 Report Share Posted April 20, 2013 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: Inability to designate an XControl as a view of an LVOOP class 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 Inability to override VI Server API methods/properties of composed elements Handler in Façade does not actively handle incoming User Events (just VI Server events) 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. 1 Quote Link to comment
mje Posted April 21, 2013 Report Share Posted April 21, 2013 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. Quote Link to comment
Yair Posted April 21, 2013 Report Share Posted April 21, 2013 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. Quote Link to comment
Olivier Jourdan Posted April 22, 2013 Report Share Posted April 22, 2013 A. A. A. To be fair, I run into much C, but I can't think ui without the use of XControl. I want #5 Jack mention to be false, but I'have to recognize that XControls new features or bug fix are really rare Quote Link to comment
ShaunR Posted April 22, 2013 Report Share Posted April 22, 2013 (edited) 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 April 22, 2013 by ShaunR 1 Quote Link to comment
fabric Posted April 23, 2013 Report Share Posted April 23, 2013 A few inconveniences that come to mind: ... You forgot "Inability to use in arrays" Quote Link to comment
JackDunaway Posted April 23, 2013 Report Share Posted April 23, 2013 You forgot "Inability to use in arrays" To be fair, this must be qualified by "inability to use in arrays using conventional, discoverable techniques" :-) Quote Link to comment
Rolf Kalbermatter Posted April 23, 2013 Report Share Posted April 23, 2013 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. Quote Link to comment
Mads Posted April 23, 2013 Report Share Posted April 23, 2013 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... Quote Link to comment
shoneill Posted April 23, 2013 Report Share Posted April 23, 2013 XControls remind me of following image: They promise SO much but don't deliver what they were clearly designed for and could probably manage. I use them from time to time but my expectations have steadily shrunk over time. Quote Link to comment
Olivier Jourdan Posted April 23, 2013 Report Share Posted April 23, 2013 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.