XControl that acts as container for other objects at edit time

[davidc10]

I want to create an XControl that acts as a container for objects dropped into it - after the XControl itself has been placed on a VI, and while that VI is in edit mode. 

The behaviour I'm looking for is similar to how a cluster or array behaves when a control is dropped into it on the front panel of a VI in edit mode.  I don't need a complete solution; I think I could make it work if I could capture the drag/drop event from the VI front panel - but I can't.

Thanks,

David

[tst]

One thing that *might* work is this -

1. Check for a mouse enter event followed by a mouse up event.
2. When you get that, get a reference to the containing VI and use the Selection List[] property for the front panel to see what was the object that was grabbed. I'm not convinced it will be in that list, but it might be. You can then get its class, etc. from the reference.

What specifically are you trying to accomplish?

[davidc10]

tst,

Thanks, that worked.  After closer examination the "container" I'm looking for is not like a cluster or array, but instead like a tab control. 

What I want to do is have an object - like a tab control - with an extended set of re-sizing, coloration, visibility methods to be used in a splitter pane.  I have a UI that simulates the behaviour of the docked/pinned/auto-hide windows found in some IDEs (e.g. Visual Studio), and I thought I'd make some of the components re-useable by creating XControls.

I've got it now.  All the XControl has to do is take ownership of the "dropped" control's positioning, visibility etc., while the dropped control remains an independent entity on the BD - like dropping an array on a tab control.

David

[tst]

---

@davidc10 wrote:
 

Thanks, that worked.  

---

Did it? OK. After writing that I did a quick test and my impression was that XControls don't get the mouse events when you drag another control, so I guess I don't understand what you actually did in the end.

Why not upload an example? Someone else might find it useful in the future.

[davidc10]

tst,

"That worked" referred to the part you were uncertain about: the SelectionList[].  I am able to get the dropped items from the list as you said.

As for detecting the drop using the available mouse events,  your test was correct: the XControl doesn't get a mouse event, (such as mouse enter, or mouse up),  if the mouse down started *outside* the XControl - as occurs during a drag *into* the XControl.

I took part one of your suggestion to mean "don't try to rely on the Drag/Drop events - just look at the mouse events".   I try, when possible, to use LV built-in events for portability, and I was intent on doing so in this case.  When I found it would not work - as in your quick test - I went back to plan B.

Plan B was: capture the mouse and generate the events myself using a Windows hook and PostLVUserEvent.  I avoid this when I can, but the availability of built-in events is sparse, and I have the Plan B tools from prior projects. 

In the end I just extended my callback VI for the hook procedure by creating the rules for a drag/drop into, and drag/drop out of, the XControl.  It would be nice to turn this into a tool that extends the availabilty of events in general way - user configurable through a dialog box, etc.   I'll be sure to post it when done.

David

[JackDunaway]

You have my interest piqued - looking forward to your upload.