LabVIEW
Custom controls or Xcontrols?
Suretha wrote:The user wil not necessarily be a developer, no.
...
My idea is to create a basic valve with different attributes, for instance it's timing can be linked to another valve, but then you can specify if it should be identical, inverse or a delayed version of the other valve's timing sequence.
...
This sounds like intelligence to me, so I assume an Xcontrol will be necessary?
This is starting to shape up as a "control on the Fly" Challenge. But I'm not going ther yet.
XControls are great if you as a developer have same functionality you want to include in more than one app. They wrap-up all of the functionality you associate with that control. You (as a developer) just drop another one in a new app and the functionlaity comses along for the ride. In my experience this means I code up the function I want in an app (done coding if I don't go to XControl) and then start the work of converting to work as an XControl.
If you can put an upper limit on the number of objects you will present on the screen at any one time you can;
Create a cluster with the max number of controls you need and hide what you are not using at the time.
Do the same as above with hidden controls.
If you can let the GUI NOT look like the widget you are testing then arrays are useful.
If all of the above leaves you lacking I'll outline what I went through to do my last "Controls on the Fly" app.
1) Get very familiar with the LV Picture control. If allows you to draw whatever you want and offers mouse down/up move, enter and leave events. The picture control will be used to render your objects.
2) Get familiar with LVOOP. I used LVOOP because many of the routings of mouse clicks, possitioning, rendering, etc are common to all of the object on the screen. Code up this functionality in a parent class so the childeren can inherit this functionality.
3) Code up an application that operates in two modes (optional but it makes design easier) "Desgn mode" and "Operate". In Design all the user to layout the GUI but do not implment any functionality beyond Deisgn work. The design when loaded in Operate mode should establish all nessesary communications and use the events captured from the Picture control to invoke the methods required for each class of gizmo on your widget.
There is a LOT of work that goes into a "Controls on the Fly" app. If the work I outlined above "bugs" you. It should. 
Ben
@Ben wrote:
Suretha wrote:
The user wil not necessarily be a developer, no.
...
My idea is to create a basic valve with different attributes, for instance it's timing can be linked to another valve, but then you can specify if it should be identical, inverse or a delayed version of the other valve's timing sequence.
...
This sounds like intelligence to me, so I assume an Xcontrol will be necessary?
This is starting to shape up as a "control on the Fly" Challenge. But I'm not going ther yet.
XControls are great if you as a developer have same functionality you want to include in more than one app. They wrap-up all of the functionality you associate with that control. You (as a developer) just drop another one in a new app and the functionlaity comses along for the ride. In my experience this means I code up the function I want in an app (done coding if I don't go to XControl) and then start the work of converting to work as an XControl.
If you can put an upper limit on the number of objects you will present on the screen at any one time you can;
Create a cluster with the max number of controls you need and hide what you are not using at the time.
Do the same as above with hidden controls.
If you can let the GUI NOT look like the widget you are testing then arrays are useful.
If all of the above leaves you lacking I'll outline what I went through to do my last "Controls on the Fly" app.
1) Get very familiar with the LV Picture control. If allows you to draw whatever you want and offers mouse down/up move, enter and leave events. The picture control will be used to render your objects.
2) Get familiar with LVOOP. I used LVOOP because many of the routings of mouse clicks, possitioning, rendering, etc are common to all of the object on the screen. Code up this functionality in a parent class so the childeren can inherit this functionality.
3) Code up an application that operates in two modes (optional but it makes design easier) "Desgn mode" and "Operate". In Design all the user to layout the GUI but do not implment any functionality beyond Deisgn work. The design when loaded in Operate mode should establish all nessesary communications and use the events captured from the Picture control to invoke the methods required for each class of gizmo on your widget.
There is a LOT of work that goes into a "Controls on the Fly" app. If the work I outlined above "bugs" you. It should.
Ben
I lit a hundred candles, memorized a witch doctor chant, and followed all the guidelines on moon phase and planet alignment, and sourced several gigawatts to bring this thread back from the dead.
Ben, I understand what you're describing here but would absolutely love to see an example implementation. By any chance do you have something like that you can share publicly? I totally understand if not, sounds rather horrendous to code up just for an example.
Does anyone have code for this (eg. the picture control stuff Ben describes) that's shareable?
I'll be honest, I would probably exhaust every avenue relating to convincing client they don't want a UI like that or just implement said UI using a different language and likely some relevant third party UI library. UI's like that are one of LabVIEW's Achilles' heel.
That last sentence it was kills me. Basically the OP would love a somewhat limited palette/dumbed down version of the LabVIEW block diagram IDE, something I have posted about my desires for more than once. I really think it would be worth the trouble for NI, possibly even the "killer app" for LabVIEW. Many of us write applications that are used by highly educated/trained, technically minded, scientists/engineers/operators. While asking them to master LabVIEW themselves is probably a tall and unrealistic order, but giving them a built executable with a UI that works and resembles the LV block diagram with a limited palette and custom rules/limitations would be the bees knees in many applications I have been involved in. Even better if it's prettied up like the block diagramming in the ill-fated NXG IDE.
Using the picture control, even with LVOOP/inheritance, is just impractical for anything but the most cartoonish basics (and that's assuming the developer has an artistic eye to begin with, judging by the LV UI's that I see, that eliminates about 99.9% of us LV devs).
But I would love to see this picture control method with my own eyes if someone has anything. If so, please share! I vaguely remember making a similar attempt using picture control years ago, after awhile I decided it was too much trouble for something that was just an internal project with no requirement for such a UI (but it would have been cool).
