Jump to content

Recommended Posts

A recent thread has raised the issue of example code illustrating the use of new features of LV8x, in particular the topic of XControls was mentioned. In that vein -- and FWIW -- I have yet to see a complete example of an XControl that implements, for instance, the functionality of a CD drive transport control panel. I mention this example because:

1. Such an instance would be a generally useful example.

2. The idea of such an instance has been mentioned in several other venues.

3. I haven't (yet) seen one -- and perhaps I've missed it so apologies in advance if one already exists and is available.

4. It SEEMS LIKE it should be a "really good thing" to use an XControl for this.

5. But, despite #4, I find myself returning to using "older controls" in a Queued Messaged Handler or Event State Machine architecture.

Now perhaps it's just that I'm used to "old school" LV code, perhaps I'm just not enough "up to speed" on XControl features to get it to work well. But regardless of any of that, I still think it might be a good example -- if someone else has one.

And, in any event, this is my contribution (albeit very, very small) to trying to keep a positive focus here. I've found LAVA to be very valuable and am glad that it's here. I hope to be able to be of help to others as well.

Link to post
Share on other sites

Yes it is kind of dissapointing only one XControl made it into the Code Repository. [/plug]

The way you do it now is very good to change into an XControl! because it is already event driven!

And what do you mean by CD drive control panel?

Ton

Link to post
Share on other sites

QUOTE(tcplomp @ Apr 30 2007, 06:17 AM)

Yes it is kind of dissapointing only one XControl made it into the Code Repository. [/plug]

The way you do it now is very good to change into an XControl! because it is already event driven!

And what do you mean by CD drive control panel?

Ton

"CD drive" means CD-ROM so I would like to see an example of an XControl that would involve all of the "transport" controls of a typical CD-ROM control program - something like a media player's Stop, Play, Pause, etc...

Link to post
Share on other sites

QUOTE(Michael_Aivaliotis @ Apr 30 2007, 06:26 PM)

I don't mind working on this however, the requirements seem vague. The XControl should not actually implement any of the functionality. XControls are mainly for UI implementations. What does your data type look like? You say you want Stop, Play, Pause but you can just as easily assemble this inside a cluster typedef. One thing I can think of is a Play button that after being pressed, turns into a pause button. I think we should work on the requirements first:
  • Must have a Play, Pause, FF, FR button
  • Play button will turn to pause after it's pressed.
  • Should have a progress indicator. Progress of what? Music?

Yes, I agree -- and here's where I see the lack of value in using an XControl. Now I'm NOT asking for all of the following functionality to be included in a posted example but I am pointing out that -- at least as far as I'm concerned -- there are shortcomings to using XControls in real world, deployed code. I HOPE the shortcomings that I see relate more to my own lack of familiarity with XControls but....

So if I talk about my own project -- as an example -- my code currently has:

Record, Play, Stop, Eject/Load, Fast Forward, Fast Rewind, GoToBeginning, GoToEnd, Nudge buttons (left and right to advance/reverse one "step" in the file), Progress Bar of file being played (with drageable indicator of current position that, when dragged, sets current position to its position), Elapsed Time, Remaining Time.

Now to me it's easier to architect all of that NOT in an XControl but in the "older" architectures of QMH or ESM using typedefs, etc.

Link to post
Share on other sites

QUOTE(Val Brown @ Apr 30 2007, 06:34 PM)

Yes, I agree -- and here's where I see the lack of value in using an XControl. Now I'm NOT asking for all of the following functionality to be included in a posted example but I am pointing out that -- at least as far as I'm concerned -- there are shortcomings to using XControls in real world, deployed code. I HOPE the shortcomings that I see relate more to my own lack of familiarity with XControls but....

Now to me it's easier to architect all of that NOT in an XControl but in the "older" architectures of QMH or ESM using typedefs, etc.

What you are describing is a complete application on its own. This can definitely be encapsulated into a single VI. If you need to use this functionality then you can call the VI and embed it into a subpanel. Why not?

QUOTE

there are shortcomings to using XControls in real world

I disagree with this. If you ever have to use multiple property nodes to manipulate and customize a UI then this is a good candidate for an XControl. You are not manipulating hardware, you are manipulating UI components based on user interaction or possibly interlock conditions. Based on my experience, manipulating UI's to handle users takes 10 times as long as hardware communication. XControls allow you to reuse this UI code.

Having stated all this, it does not mean you cannot implement hardware interaction or tasks that take a little too long inside of an XControl. You can always launch parallel process VI's for that. This requires a little more effort on the part of the programmer and is not a built-in feature of XControls.

Link to post
Share on other sites

QUOTE(Val Brown @ May 1 2007, 11:34 AM)

Here's some buttons you might be interested in...

http://forums.lavag.org/index.php?act=attach&type=post&id=5674

QUOTE(Michael_Aivaliotis @ May 1 2007, 11:28 AM)

I'm giving an XControl presentation at NIWeek this year.

:thumbup: I'm looking forward to it!

Link to post
Share on other sites

QUOTE(Michael_Aivaliotis @ Apr 30 2007, 06:56 PM)

What you are describing is a complete application on its own. This can definitely be encapsulated into a single VI. If you need to use this functionality then you can call the VI and embed it into a subpanel. Why not?

I disagree with this. If you ever have to use multiple property nodes to manipulate and customize a UI then this is a good candidate for an XControl. You are not manipulating hardware, you are manipulating UI components based on user interaction or possibly interlock conditions. Based on my experience, manipulating UI's to handle users takes 10 times as long as hardware communication. XControls allow you to reuse this UI code.

Having stated all this, it does not mean you cannot implement hardware interaction or tasks that take a little too long inside of an XControl. You can always launch parallel process VI's for that. This requires a little more effort on the part of the programmer and is not a built-in feature of XControls.

Actually I'm NOT describing the complete application -- just the UI for the complete application. Now perhaps that's part of my problem -- I'm (still) separating UI from the process(es) that the UI controls. So, from that perspective, I see the possibility of an array of just such UIs (perhaps implemented as an XControl) with the user being able to select a "look and feel" by selecting amongst that array. This aspect of the question relates to another thread I started about "skinnable" interfaces. Could an array of XControls be used to "skin" different interfaces? Seems to be that, theoretically at least, that could/should be possible.

And, yes, I have used property nodes to customize a UI -- MULTIPLE property nodes to dynamically customize a very, very complex UI. My understanding, and I may be incorrect, is that an XControl might be able to handle the messaging aspect of just such a UI. Then it would be a reusable component for interfacing to CD-ROMs, or DVD players or....could even be used as a front end to an array of instruments (if that metaphor made sense to the relevant users) with the message that "Fast Foward" button has been pressed being, perhaps mapped to "Use Next Available Instrument" or whatever.

I'll be very interested in your presentation but may not be at NI Week. Hopefully it will (ultimately) be made available via LAVA.

QUOTE(crelf @ Apr 30 2007, 06:58 PM)

Here's some buttons you might be interested in...

Thanks! These are useable in a distro?

Link to post
Share on other sites

QUOTE(Val Brown @ May 1 2007, 12:50 PM)

Thanks! These are useable in a distro?

Sure - go for it. I've been meaning to get them into the OpenG buttons toolkit for ages but just haven't had the time.

Link to post
Share on other sites

I personally don't think XControls are the definitive solution for UI customizing. Are interesting, yes, but have too much caveats. When you make a XControl, you want the behavior of a normal control plus some specific changes. The way XControls are conceived, when you create a new one you go back to a generic control and then you have to add all the things a specific control type (like numeric, picture, etc) does (and then, of course, make the special things you want for your XControl).

IMHO, some things are not well implemented like the error propagation, the impossibility of using a XControl property or method inside another property or method, the absence of a simple way of adding your own events, etc.

As you can see, I'm a little dissapointed with XControls even if at the beginning I considered it a great step forward. I'm looking forward Michael's presentation too, because I'd love to love XControls again ;).

Saludos,

Aitor

Link to post
Share on other sites

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.