Native drag-and-drop in Win10 visual issues

[TamarGranor]

I have a vague feeling this is connected to something I've read about, but I can't put it together.

For my drag-and-drop session at SWFox, I'm demoing both native and OLE drag-and-drop. With native drag-and-drop, everything is fine on my Windows 7 machine. But in Windows 10, when there's no custom DragIcon, the default icon appears not at the cursor position, but well to the left and above the cursor position and much smaller than exepcted, so it's hard to tell you're dragging.

Anybody have ideas?

Tamar

 

[Scott24x7]

Tamar,
Have you tried treating the native drag and drop the same as an OLE drag and drop? I've not had this issue because I just enable the control for drag-and-drop, and it just works because it can accept either Native or OLE...

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

I just tried automatic mode and a form dragdrop event as follows:

LPARAMETERS oSource, nXCoord, nYCoord

oSource.left = nXCoord
oSource.top = nYCoord

No dragicon set.

This drops the dragged control at the mouse position, not at the position you might expect from the frame appearing during the dragging. The frame is drawn with whatever offset the mouse position had when the drag started. I don't find the solution sample, but IIRC there was code storing mousex/y offset from the start of the drag and applying that at the dragdrop event.

I have no comparison Win7, but isn't that normal behaviour?

Are you really talking about native drag&drop? Native dragging is about the whole control and has no default drag icon but a rectangle in control size. It also doesn't set the drag object to the textof a textbox or a listbox item or something like that, it's about dragging the controls, whereas OLE drag&drop is about dragging data.

If I set a dragicon the dragging is not as sluggish (the drawing of the frame while dragging is sluggish since the introduction of Aero in Vista and there was this fix to change the properties of the EXE to turn off something or run in reduced color mode to get this faster), but aside of that sluggish drawing of the drag frame I see no problem.

Do you have a sample of what you're doing and when using manual native drag&drop where and how you initiate the drag?

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[TamarGranor]

Yes, I'm talking about native drag-and-drop, and I need to use that for this demo. This is not for an application.

I think a couple of screenshots will help. Hoping I can make that work.

Here's the Windows 7 version. Note that the drag icon (the rectangle) is right at the mouse

Now here's the Windows 10 version. Note that the drag icon is far from the mouse, and much smaller than it should be.

 

[Olaf Doschke]

Aha, I see the above image on my Windows 10 version, in short: In my Windows 10 this is not broken.

So it must have to do with some setting of either VFP or Windows or with your build of Windows 10.

I'd guess this could be about the typical scale factor for fonts and icons, if you've set that to 150% on an UHD display to be able to read something, VFPs native drag might still work with native coordinates not zoomed up.

Bye, Olaf.





Olaf Doschke Software Engineering

https://www.doschke.name

 

[TamarGranor]

I noticed today that I see this dragging stuff around in VFP, even if it's not in my forms. I suspect it might be scaling. Not much I can do about that. The recommended scaling for this machine is 250%; anything much smaller and I can't read a word.

Guess that's one more reason to use OLE drag and drop.

Tamar

 

[Scott24x7]

Ah... yes. Tamar, one way you can fix that is not to run at maximum screen resolution and use a different one. I noticed a long time ago that scaling and VFP don't mix at all.

So if you right click anywhere on the open desktop, click Display Settings, in the window that comes up scroll down to "Display" and change the resolution down to one that you can read, set change the size of text, apps, and other items to 100% (instead of 250%), and run it that way. Just because a screen has a resolution of 2736 x 1824 (for example) doesn't mean you can't run at 100% at 1600 x 1200 (for example). Then its readable, no scaling and no issues. You can do this in particular for the demo purpose if you like, and run your 250% as a "normal" operation when you're not using it for demo. That's what we do too...


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

The print is while that's possible ClearType and other mechanisms render text blurry when not using the native resolution of a display.

I do use the native resolution and simple reading glasses.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[TamarGranor]

So I tested today, switching down to much lower resolution with 100% scaling. It actually made things worse. With these settings, I see two rectangles, neither of them in the right place, one larger out in front of the mouse and one smaller trailing behind. Really weird and after the drop, part of the larger rectangle remains.

Tamar

 

[Olaf Doschke]

Then I guess this only will work with 100% scaling at native resolution. And if that's making it all too small, you will need to find another laptop with less advanced display resolution to make this demo.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Scott24x7]

Hi Tamar,
This is still unique only to Native mode right?
I'm just wondering why use this though? OLEDragDrop and OLEDragOver will manage non-OLE data. And then you get none of these anaomolies. (I have discovered that's why I'm not seeing the issue you have).

In a textbox class add this code to OLEDragDrop:

LPARAMETERS oDataObject, nEffect, nButton, nShift, nXCoord, nYCoord

NODEFAULT

This.Value = ALLTRIM(oDataObject.GetData(1))
*
This.Value = CHRTRAN(This.Value,CHR(10),"")

and in the OLEDragOver add this code:

LPARAMETERS oDataObject, nEffect, nButton, nShift, nXCoord, nYCoord, nState
*
DO CASE
CASE nState == 0		&&DRAG_ENTER
	DO CASE
	CASE oDataObject.GetFormat("OLE Variant Array")	&& Array
		This.OLEDropHasData = 1		&&DROPHASDATA_USEFUL
		This.OLEDropEffects = 1+2	&&DROPEFFECT_COPY + DROPEFFECT_MOVE
		
	CASE oDataObject.GetFormat(1)				&& Text
		This.OLEDropHasData = 1		&&DROPHASDATA_USEFUL
		This.OLEDropEffects = 1+2	&&DROPEFFECT_COPY + DROPEFFECT_MOVE
		
	CASE oDataObject.GetFormat(15)				&& Files CF_HDROP
		This.OLEDropHasData = 1		&&DROPHASDATA_USEFUL
		This.OLEDropEffects = 4		&&DROPEFFECT_LINK
	OTHERWISE
		This.OLEDropHasData = 0		&&DROPHASDATA_NOTUSEFUL
	ENDCASE

CASE nState == 1	&& Drag Leave
CASE nState == 2	&& Drag Over
ENDCASE

No you can drag and drop text from one text box to another (or edit box, or combo, etc, anywhere you select text, then drag and drop it). This is what I use for non-ole data.
In addition, I have these three properties set as follows:
OLEDragMode - 1 Automatic
OLEDropMode = 1 Enabled
OLEDropTextInsertion - 1 insert at word boundaries only
OLEDropEffects = 3 (This is 1+2 for nDropEffect value I believe this is the default)

I then have 0 need for "Native" drag/drop support, and I have none of the display issues you are finding.
Now, I know your intention is for demoning this at SWFox, but it may be something you want to mention there is no need for "native" support, and by using the OLEDragDrop for everything it simplifies the code, and you don't have all these weird visual issues your facing.



Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Well, native drag&drop is about dragging the controls themselves, not data. It has a different intention.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Scott24x7]

Ah, right. Forgot about that aspect of it.
I never have a need to move controls around on a form, but I guess others might.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

There are uses of native drag & drop that are not just moving controls around. One example that comes to mind is if you want to delete an image from a catalogue. You could let the user drag the image control onto a rubbish bin, at which point the underlying image file would be deleted.

It's true that, in this example, it is the control that you are dragging, but the intent is not to change the position of the control within its form.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

You're free to do whatever action at the drop event.

You can also use OLE Drag&Drop to drag controls, just let the mouse icon be the control (or screenshot of it) and allow the form to be the drop target.

In that sense Scott is right we could just do without native drag & drop. Also, automatic native drag&drop does in fact not move a control you need the code I posted above changing oSource.left and top, that doesn't happen automatic. You couuld also take oSource.value or oSrouce.Displayvalue and add it to the target object.

So indeed both methods can do the same, the automatic visual feedback - which is broken for native automatic drag&drop - is just favoring native for control ragging an ole for data dragging.

The reason OLE is more important is it also works in and from or to external applications. It's more like a visually used clipboard.

We don't need to put down native rag&drop overall, if we set the icon while dragging.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[TamarGranor]

Actually, in the session, one of my bottom lines is to use only OLE drag-and-drop, but since I'm giving a session on the top, I want to demo the native version as well. I'll just live with it, and explain.

Tamar