Drop a control on constituent controls of a user control

[Donar]

Hello all,

I tried the whole day now with solving a problem which I have come across yesterday, nothing seems to work. Google does not help for once, so a question out to you, somebody simply must have had the same problem once. So, here we go:

In VB6, I have a user control with a number of constituent controls (CommandBox, Label, TextBox controls as well as subordinated user controls).

I want to drop an unrelated control onto one of the user control's constituent controls, starting it with the .Drag vbBeginDrag method.

The UserControl gets the DragDrop, but the constituent controls do not. How ca I make them recognize the Drop on them?

Thanks,
Donar

[DataMiser]

Well, normally you would do some mapping but I think the drop event can only be mapped to one thing so if you are trying to get it to be able to drop on possibly more than a single control within your user control then you are going to have to code it in the drop event of the user control and then determine where the data/object needs to go.

In general I avoid user controls and can't think of a case where I would want to use one that had several other user controls within it. To many sources for possible problems, to many dependencies.

[Schmidt]

In general I avoid user controls and can't think of a case where I would want to use one that had several other user controls within it. To many sources for possible problems, to many dependencies.

Nah - there's dozens of scenarios where UserControls which contain additional Controls make perfect sense.
And I also don't see, where the "additional dependencies" would come from (e.g. when you use only VBs intrinsic
Controls as constituent Controls within an project-private UC, then there's not a single extra-dependency needed).


@Donar
Just tried to replicate your scenario - and as it seems the old Drag-Support of VB will not work
well "across Control-Boundaries".

I then tried the newer OleDragDrop - and with that it's perfectly possible to work across Control-
Boundaries (as well as Cross-Process of course)...


To reproduce that, you can create a new project-private Usercontrol - put a CommandButton,
as well as a PictureBox on it (just to represent two constituent Controls) - then set the
PictureBox to OleDragMode = [1 automatic] and OleDropMode = [1 manual].

Then put the following code into the Usercontrol

Private Sub Picture1_OLEStartDrag(Data As DataObject, AllowedEffects As Long)
  Data.SetData "Action started on hWnd: " & Picture1.hWnd, vbCFText
End Sub

Private Sub Picture1_OLEDragOver(Data As DataObject, Effect As Long, Button As Integer, Shift As Integer, X As Single, Y As Single, State As Integer)
  If Not Data.GetFormat(vbCFText) Then Exit Sub
  If Left$(Data.GetData(vbCFText), Len("Action started")) = "Action started" Then Effect = 1
End Sub

Private Sub Picture1_OLEDragDrop(Data As DataObject, Effect As Long, Button As Integer, Shift As Integer, X As Single, Y As Single)
  Parent.Caption = "Picture1_OLEDragDrop ... " & Data.GetData(vbCFText)
End Sub

Now create two Instances of your Usercontrol on your Form - and drag between the two PictureBoxes.

Olaf

[DataMiser]

Nah - there's dozens of scenarios where UserControls which contain additional Controls make perfect sense.
And I also don't see, where the "additional dependencies" would come from (e.g. when you use only VBs intrinsic
Controls as constituent Controls within an project-private UC, then there's not a single extra-dependency needed).

If you read the OP it says

a number of constituent controls (CommandBox, Label, TextBox controls as well as subordinated user controls).

But yes there are cases were a user control would contain more than one control, a textbox and a label for example, but when you start placing other user controls within a user control that can get ugly.

[DataMiser]

Nah - there's dozens of scenarios where UserControls which contain additional Controls make perfect sense.
And I also don't see, where the "additional dependencies" would come from (e.g. when you use only VBs intrinsic
Controls as constituent Controls within an project-private UC, then there's not a single extra-dependency needed).

If you read the OP it says

a number of constituent controls (CommandBox, Label, TextBox controls as well as subordinated user controls).

Also note that I said I would not want to use a UC that had several other UCs within it, it can cause a lot of issues and you have those extra dependencies of all the additional user controls and whatever dependencies they may have themselves. I believe in the K.I.S.S. principle

But yes there are cases were a user control would contain more than one control, a textbox and a label for example, but when you start placing other user controls within a user control that can get ugly.

[Schmidt]

If you read the OP it says ... "... subordinated user controls"

And so what?

User-controls are basically the same thing as normal VB-Classes (just having additional "visual behaviours").
And in the same way as with normal VB-Classes - there can be "project-private" ones, as well as "public ones"
(defined in a separate "Dll- or OCX-Binary-project") - and they can be nested.

Also note that I said I would not want to use a UC that had several other UCs within it, it can cause a lot of issues ...

In what regard?
Nesting Controls within Controls is (as well as nesting Classes within Classes) a common base-pattern.

I believe in the K.I.S.S. principle

Me too - but nesting of Classes (or Controls) and their interfaces is a necessity to *achieve* KISS -
and not something which contradicts KISS.

Olaf

[jmsrickland]

I then tried the newer OleDragDrop - and with that it's perfectly possible to work across Control-
Boundaries (as well as Cross-Process of course)...

To reproduce that, you can create a new project-private Usercontrol - put a CommandButton,
as well as a PictureBox on it (just to represent two constituent Controls) - then set the
PictureBox to OleDragMode = [1 automatic] and OleDropMode = [1 manual].

Then put the following code into the Usercontrol

Private Sub Picture1_OLEStartDrag(Data As DataObject, AllowedEffects As Long)
  Data.SetData "Action started on hWnd: " & Picture1.hWnd, vbCFText
End Sub

Private Sub Picture1_OLEDragOver(Data As DataObject, Effect As Long, Button As Integer, Shift As Integer, X As Single, Y As Single, State As Integer)
  If Not Data.GetFormat(vbCFText) Then Exit Sub
  If Left$(Data.GetData(vbCFText), Len("Action started")) = "Action started" Then Effect = 1
End Sub

Private Sub Picture1_OLEDragDrop(Data As DataObject, Effect As Long, Button As Integer, Shift As Integer, X As Single, Y As Single)
  Parent.Caption = "Picture1_OLEDragDrop ... " & Data.GetData(vbCFText)
End Sub

Now create two Instances of your Usercontrol on your Form - and drag between the two PictureBoxes.

Olaf

I'm not following this thread but I did take an interest in your OLEDragDrop so I have two questions

1) drag what between the two PictureBoxes

2) What's the purpose of the Command Button

[DataMiser]

And so what?

Whatever dude, clearly you just feel like arguing even if it means moving the posts. Feel free to use as many OCXs in OCXs as you like and have fun with the issues that come with them.

[Schmidt]

Whatever dude, clearly you just feel like arguing even if it means moving the posts. Feel free to use as many OCXs in OCXs as you like and have fun with the issues that come with them.

It was not "feeling like arguing" - it was just a correction to your blanket statement where you said that you:

...can't think of a case where I would want to use one that had several other user controls within it. To many sources for possible problems, to many dependencies.

Because that's just misleading info for community-members who consider to use UserControls.

If you have no experience with UCs, then why trying to "warn" others about them?

It's the same thing as if you'd say: "Never use a reference to the MS-XML- or MS-ADO-
Classes within your own Classes".

People who say things like that do not understand much about encapsulation or simplest OO-patterns.

Olaf

[dilettante]

The only headache I can think of is when trying to reuse nested UserControls at the source level.

If you wrap an instance of one UserControl inside another UserControl, the parent .CTL file refers to it using AppTitle.CtlName in its source file. This means when you try to reuse those controls in another project (with a different Title) you have to be sure to rename the occurrences in the parent .CTL file to reflect the new project's Title.

If the parent and child controls are part of a separately compiled OCX this issue doesn't arise, since when you build the OCX it uses its own Title. So a new project using the OCX has no conflict.


I seem to recall that Microsoft originally didn't expect people to try to reuse UserControls at the source level that often. When it turned out to be more common they had added something to the list of VB7 features to address the matter.

But we all know what came of that.

[Schmidt]

The only headache I can think of is when trying to reuse nested UserControls at the source level.

If you wrap an instance of one UserControl inside another UserControl, the parent .CTL file refers to it using AppTitle.CtlName in its source file. This means when you try to reuse those controls in another project (with a different Title) you have to be sure to rename the occurrences in the parent .CTL file to reflect the new project's Title.

That's true - and although it would have been nice to have a fix for this particular problem (to avoid
copying of private *.ctl-Files from a "leading source") - *when* it happens to you, it might serve as a nice
reminder, that you should think about "sharing per compiled Binary" among the two (or more) hosting
projects which need this Control nested in another Control. Time to define a nice and stable Interface then -
switching BinComp on - making an OCX-COMponent out of it.

If the parent and child controls are part of a separately compiled OCX this issue doesn't arise, ....

Yep.

Olaf

[Schmidt]

I'm not following this thread but I did take an interest in your OLEDragDrop so I have two questions

1) drag what between the two PictureBoxes

Whatever you want to put into the Data(Source)-Parameter which comes in per OleStartDrag-Event
(StdPictures, Plain-Text, RTF-Text, FileNames/Paths, your own Bytearrays etc.)...

In the code-snippet of the simple example further above, I was placing only Plain-Text in it, to keep it simple.
Tough the Plain-Text was already containing the hWnd of the Source-PictureBox, the Dragging-Op was started on.

2) What's the purpose of the Command Button

Just to have another "sibling" to the intrinsic PictureBox placed on the container-control
(at the same "nesting-level") - to demonstrate what I think the OP had in mind - only
allowing an OleDragOver- OleDragDrop-reaction on a single constituent Child-Control on the
given UC - neither the CommandButton, nor the hosting Parent-UC itself will react to the
Drag-Events (showing the "forbidden" MouseCursor then on their appropriate areas,
as it should be).

Olaf