Drag Drop problem....

[SamOscarBrown]

In the image below, I want to drag, for example, a Blue Command Button (near top) and place it ON the Green Command Button you see along one of the paths (not in the BASE area). I currently have all command button (Blue, Orange, Green, etc) set to be dragged to any position on the form. The 'normal' event would be drop one of the buttons on the 'pink' circles around the board, but if one of those pink circles is 'occupied' by another command button, I want to know that I have dropped it there. Of course, when 'trying' to drop a button on another one, the move won't take place as the 'target' is somewhere on the FORM.

What approach should I use to be able to 'hit' another command button (and subsequently send that button back to its base---I'll figure that out later, but first need to know how to do such a 'hit', while keeping the capability to drop anywhere on the form (of course, that 'anywhere' would be one of the pink circles)).



EDIT: each 'set' of colored command buttons are in image arrays (GreenPlayer(1), GreenPlayer(2), etc---four in each array).

[dilettante]

This demo uses lightweight UserControls instead of fat and stupid CommandButton controls. This not only saves a ton of "weight" but also lets you bury a lot of housekeeping within the UserControl and out of the Form module code.

This one doesn't "snap" on drag collisions, but that should be simple enough to add.

• Any of the controls here is allowed to be dragged. You could also have some that are only targets and do not drag around if desired.
• While being dragged a control turns yellow. Once it "hits" another control it turns magenta and turns the control collided with red. Drag it off the collided control and it goes back to yellow until the mouse button is released.
• After one or more "hits" you can click on the "Clear" menu item to reset all controls to their idle colors.

While being dragged, a control instance raises an event asking its Parent's logic to perform hit tests against the other controls. The Parent needs to do this, because it "knows about" the set of controls to be tested for hits.

In theory, the dragged instance could spelunk the Parent's Controls array for controls to hit test against and just do that itself. The controls would need to be "tagged" in some way to be recognized, but you could do it if you wanted.

Normally the Parent wants to know if a hit occurs though, if only to do things like enable "Clear." So you'd probably want to raise a "been hit" event anyway.


Most graphical games probably shouldn't use controls at all though and just draw everything.

[SamOscarBrown]

Great demo, dilettante....thanks a lot.

Going to take me some time to implement this (for one, UNDERSTANDING it all, and two, implementing what happens when Hit (I won't be changing colors, but will want to move the target to a certain location on the screen).

You certainly have a deep understanding of VB6, for sure...You've assisted me several times in the past with your examples.

Thanks

Sam

[dilettante]

Well it isn't really that exotic. You need to break it down and examine the steps.

All it is really doing is handling control dragging, but while doing that compares the dragged control's "rectangle" with those of all the other control instances for intersection. The GDI call helps by doing the comparisons but you could also check the positions by brute force code too.

To snap in place instead of changing colors you could stop comparing at the first "hit" then cancel dragging and move the dragged control to that "hit" rectangle.

[Niya]

Most graphical games probably shouldn't use controls at all though and just draw everything.

I'll co-sign this. Like this cannot be overstated. You can get away with it for very simple games or simple engines but it much better in the long run to avoid using Controls to implement game elements.