How do I know when user drops a widget?

How do I know when the user drops a widget which is in the process of being
dragged? Do I need to implement the DragDrop event on every widget on my
Form?

Thanks,

- Joe Geretz -

Karl
Thu Apr 29 11:54:23 CDT 2004

Joseph Geretz <jgeretz@nospam.com> wrote:
> How do I know when the user drops a widget which is in the process of being
> dragged? Do I need to implement the DragDrop event on every widget on my
> Form?

Yeah, every one you care to allow the drop on.
--
[Microsoft Basic: 1976-2001, RIP]

Larry
Thu Apr 29 12:20:53 CDT 2004


"Joseph Geretz" <jgeretz@nospam.com> wrote
> How do I know when the user drops a widget which is in the process of being
> dragged? Do I need to implement the DragDrop event on every widget on my
> Form?

If you use control arrays, you can lessen the load. Also, if you use a class you
can keep that OLE goo out of your other code. Here is an example of using a
class to catch the highlighting for some number of boxes. Instead of the focus
events, you'd want to respond to the drag and drop events....

http://groups.google.com/groups?selm=%23gYXnxjEEHA.4080%40TK2MSFTNGP09.phx.gbl&oe=UTF-8&output=gplain
(Try the example, then look at how much code was required in your form!)

HTH
LFS

Larry
Thu Apr 29 12:29:25 CDT 2004


"Larry Serflaten" <serflaten@usinternet.com> wrote
>
> If you use control arrays, you can lessen the load. Also, if you use a class you
> can keep that OLE goo out of your other code.

I should have mentioned, those are mutually exclusive. If you use a control array,
you can't use the class method.

LFS

Joseph
Thu Apr 29 13:47:03 CDT 2004

Hi Karl,

> > How do I know when the user drops a widget which is in the process of
being
> > dragged? Do I need to implement the DragDrop event on every widget on my
> > Form?
>
> Yeah, every one you care to allow the drop on.

But don't those widgets which don't handle the drop need to have DragDrop
implemented as well? Standard windows functionality terminates the drag
operation if the object is dropped on an illegal target. So this means I
need to implement the DragDrop event for every widget on my form! This is so
cumbersome.

- Joe Geretz -

Joseph
Thu Apr 29 13:57:29 CDT 2004

Hi Larry,

I see what you're doing and it has some interesting implications. It would
reduce the complexity I have to deal with, to the number of different
widgets I have on the form. But even so, I must have at least a dozen
different widgets for which I need to handle the DragDrop event. Frames,
Text Boxes, Grids, List Boxes, Combo Boxes, our own user controls, etc. This
is not going to be pretty.

I remember way back when, looking at Delphi, before getting into VB. The
Delphi event model was very interesting. If I recall correctly, an event was
dispatched first to the form, then to its target, then back up through the
container hierarchy, ending finally with the form as the final container.
Back then, I just didn't get the whole complexity. I do now :-(

- Joe Geretz -

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:%23dE%23H9gLEHA.1392@TK2MSFTNGP09.phx.gbl...
>
> "Larry Serflaten" <serflaten@usinternet.com> wrote
> >
> > If you use control arrays, you can lessen the load. Also, if you use a
class you
> > can keep that OLE goo out of your other code.
>
> I should have mentioned, those are mutually exclusive. If you use a
control array,
> you can't use the class method.
>
> LFS
>

Larry
Thu Apr 29 15:54:55 CDT 2004


"Joseph Geretz" <jgeretz@nospam.com> wrote
> I see what you're doing and it has some interesting implications. It would
> reduce the complexity I have to deal with, to the number of different
> widgets I have on the form. But even so, I must have at least a dozen
> different widgets for which I need to handle the DragDrop event. Frames,
> Text Boxes, Grids, List Boxes, Combo Boxes, our own user controls, etc. This
> is not going to be pretty.


You can still keep it all grouped in one class, and if the outcome of a drop is
similar across your controls, you can call on a common routine to keep the
code down to a minimum.

For an example, below is the AutoSelect code assuming you wanted to allow
Command buttons and textboxes to be highlighted on focus. Its just a few
extra lines, and once you've typed it in, you're done! ;-)

Use as you see fit! <g>

LFS


Option Explicit

Private Buddies As Collection

Public WithEvents Buddy As TextBox
Public WithEvents Button As CommandButton

Public Sub AddBoxes(ParamArray Controls())
Dim bud As AutoSelect
Dim box

For Each box In Controls
Set bud = Nothing
If TypeOf box Is TextBox Then
Set bud = New AutoSelect
Set bud.Buddy = box
ElseIf TypeOf box Is CommandButton Then
Set bud = New AutoSelect
Set bud.Button = box
End If
If Not bud Is Nothing Then Buddies.Add bud
Next
End Sub

Private Sub Buddy_GotFocus()
With Buddy
.SelStart = 0
.SelLength = Len(.Text)
End With
End Sub

Private Sub Button_GotFocus()
Button.Font.Bold = True
End Sub

Private Sub Button_LostFocus()
Button.Font.Bold = False
End Sub

Private Sub Class_Initialize()
Set Buddies = New Collection
End Sub

Joseph
Thu Apr 29 16:06:50 CDT 2004

Sorry, my mistake. I didn't set this up properly.

I'm using Manual mode. I start the drag on the source widget by examining
the state of the mouse in the MouseMove event. Since MouseMove, doesn't
deliver this information I use a module level boolean which I set to True in
the MoseuseDown event. I set this to False in the MouseUp event and in the
DragDrop event of the target widget. But since the user might drop this on
any widget, I thought I'd have to set this to False in the DragDrop of all
widgets. Otherwise, the next mouseover would start the drag operation again
since my MoseDown indicator is still set to down. Fallacy!

The correct way to do this is to set the MouseDown flag to false as soon as
the Drag starts. (Even though the mouse is still physically down this state
flag is no longer needed since the drag operation has already started.) Now
there's no longer any need to detect the end of the drag operation (except
for the target widget which is interested in handling the drop, of course.)

- Joe Geretz -

"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:edNm6nhLEHA.2388@TK2MSFTNGP09.phx.gbl...
> Hi Karl,
>
> > > How do I know when the user drops a widget which is in the process of
> being
> > > dragged? Do I need to implement the DragDrop event on every widget on
my
> > > Form?
> >
> > Yeah, every one you care to allow the drop on.
>
> But don't those widgets which don't handle the drop need to have DragDrop
> implemented as well? Standard windows functionality terminates the drag
> operation if the object is dropped on an illegal target. So this means I
> need to implement the DragDrop event for every widget on my form! This is
so
> cumbersome.
>
> - Joe Geretz -
>
>

erewhon
Fri Apr 30 02:38:58 CDT 2004

On Thu, 29 Apr 2004 14:57:29 -0400, "Joseph Geretz"
<jgeretz@nospam.com> wrote:

>Hi Larry,
>
>I see what you're doing and it has some interesting implications. It would
>reduce the complexity I have to deal with, to the number of different
>widgets I have on the form. But even so, I must have at least a dozen
>different widgets for which I need to handle the DragDrop event. Frames,
>Text Boxes, Grids, List Boxes, Combo Boxes, our own user controls, etc. This
>is not going to be pretty.
>
>I remember way back when, looking at Delphi, before getting into VB. The
>Delphi event model was very interesting. If I recall correctly, an event was
>dispatched first to the form, then to its target, then back up through the
>container hierarchy, ending finally with the form as the final container.
That is the Messages
In Delphi the Events are effectively calling a pointer to a function

>Back then, I just didn't get the whole complexity. I do now :-(

Could you not make just one multi function UserControl that can turn
into any of your 'widgets'
- then you could simply have one Control Array

Alternatively, if you are doing some sort of screen designer, do you
actually need to use DragDrop ?
One can position controls quite easily without DragDrop

anonymous
Fri Apr 30 08:56:05 CDT 2004

What if the user fails to drop a widget, but instead drops a log?

Joseph
Fri Apr 30 10:24:40 CDT 2004

Hi J,

> Could you not make just one multi function UserControl that can turn
> into any of your 'widgets'
> - then you could simply have one Control Array

Sounds interesting, but I have the feeling that it would be difficult to
pull this off in a cost effective manner, without the facilities of
inheritance. (I really can't justify reinventing the standard VB widgets
just for the purposes of being able to have them in a single control array.)
Alas, not in VB6.

> Alternatively, if you are doing some sort of screen designer, do you
> actually need to use DragDrop ?
> One can position controls quite easily without DragDrop

Yes, but we're not using drag and drop for positioning UI elements. We're
using it as part of the interface to allow the user to perform specific
tasks. (Like dragging a document into the recycle bin.)

- Joe Geretz -

erewhon
Fri Apr 30 12:36:15 CDT 2004

On Fri, 30 Apr 2004 11:24:40 -0400, "Joseph Geretz"
<jgeretz@nospam.com> wrote:

>Hi J,
>
>> Could you not make just one multi function UserControl that can turn
>> into any of your 'widgets'
>> - then you could simply have one Control Array
>
>Sounds interesting, but I have the feeling that it would be difficult to
>pull this off in a cost effective manner, without the facilities of
>inheritance. (I really can't justify reinventing the standard VB widgets
>just for the purposes of being able to have them in a single control array.)
>Alas, not in VB6.

I would