Hm, yeah that might not be working.. but it should be compatible with standard drag/drop so it's probably a bug.

As for the original issue that can certainly be fixed.

But in any case, there still seems to be the issue with the data object (I wanted to use the Eto version for unified Clipboard/drag-and-drop handling). Though I can work around that with creating the handler manually if needed.

I had drag implemented on items in a embedded control (System.Windows.Forms.ListView). I guess that might not be supported with the shell drag and drop?

The shell drag and drop is used so you can have drag images and have a tooltip like how the File Explorer drag/drop works.

Thanks for reporting the issue! What control(s) are you dragging/dropping with where it doesn't work?

Also, is the "shell drag and drop" documented anywhere? I'm not sure the point of it, it seems like I also need to set WindowsControl.UseShellDropManager to false in order for drag-and-drop to work.

<!-- Thanks for taking the time to report an issue! Some things to consider:

• Please be detailed and ensure there isn't already an open issue for your bug/request.
• If you can, please try to reproduce the problem using the develop branch first as your issue may already be fixed.
• If you have an enhancement request, you can remove the sections that don't apply.

-->

Setting data on an Eto DataObject has no apparent effect - subsequent gets return null. This applies to all methods (SetString, SetObject, SetData, etc.).

var x = new Eto.Forms.DataObject();
x.SetString("data", "type");
Console.WriteLine(x.GetString("type")); // null

This seems related to https://github.com/picoe/Eto/commit/1b32e67b0a7de0715d2fa08c51621e535e070f68 which creates a custom internal data object in the default constructor.

Creating with a normal data object works as expected:

var x = new DataObject(new DataObjectHandler(new System.Windows.Forms.DataObject()));
x.SetString("data", "type");
Console.WriteLine(x.GetString("type")); // "data"

<!-- Please specify the version of Eto and all platforms this can be reproduced in -->

Specifications

• Version: 2.5.10
• Platform(s): WinForms
• Operating System(s): Win10

Trying the unique option and I don't see any difference in the output. Thanks!

Added .NET 5.0 support to execute tool inside mcr.microsoft.com/dotnet/sdk:5.0* docker build images.

@tomchavakis: please fix github workflows to add .NET 5.0 sdk during build process

@tomchavakis: github workflows updated with .NET 5 install step. I'm waiting for your review.

Thanks!

Hi @alesebi91 ,

A really cool feature just come up with your contribution. I'll review it until tomorrow.

Thanks!!

@tomchavakis: github workflows updated with .NET 5 install step. I'm waiting for your review.

Thanks!

Hm, I'm seeing the same results on macOS using the accessibility on-screen keyboard so it's probably a quirk (feature) of that platform. It doesn't appear to be giving a different key code so there's not much I can do about that.

As for Gtk that should be no problem to fix those two at the very least.

The following table contains the output of $"{e.KeyChar}|{e.Key.ToString()}" where non-printable key chars have been omitted. The platforms behave completely different... In bold there are some of my ideas how to change

On Windows, 4 events will be raised (duplicating first and second Key value); those are only shown once per distinct event args. For the second press of a dead key the same keychar is emitted 4 times!

I don't know if the macOS result is right, as I'm using a VM with a Standard German keyboard - a German mac keyboard has a different layout...

The most problematic is probably the + as requiring umlaut or dead keys for custom actions is hopefully uncommon... But still emitting events for those would be needed for e.g. implementing custom input on controls. The inconstency on the + key for macOS still isn't great, but is a quirk of macOS?

Awesome, that is much appreciated and will make this very quick to fix!

Working on it. Good news: On Windows everything seems quite fine; I'm currently preparing testing on macOS. Bad news: Also some other keys (8 in total) on the German keyboard do not work on Eto.Gtk

Awesome, thanks for reporting the issue! I'll see if I can get the virtual keyboard to show a German layout, but if not I might not be able to know which key it reports on the various platforms.

One way you could help is to run your application in debug on the other platforms (Wpf, WinForms, Mac). You should then get an output like Unknown key XX, where it will tell us which key to map it to.

On a German keyboard, there is an extra key for the plus sign that is located to the left of the enter key. With eto the keypress returns a Key=Keys.None, KeyChar='+'. I suppose this is not optimal...

See Wikipedia: https://en.wikipedia.org/wiki/German_keyboard_layout#/media/File:KB_Germany.svg

e.g. on Gtk3, Gtk returns Key.plus which is not handled in the KeyMap: https://github.com/picoe/Eto/blob/develop/src/Eto.Gtk/KeyMap.cs. I did not test on other platforms...

Expected Behavior

Pressing + on my keyboard returns a meaningful keycode (e.g. Keys.Plus) and not Keys.None. Returning Keys.Equal would be misleading, as the plus key on a German keyboard layout cannot produce an equals sign... [1].

Specifications

• Version: latest CI build
• Platform(s): Gtk3

[1] Note/addition: there is also no equals key on German keyboards at all, as the equal sign is produced with Shift+0.... But those keys at least return some meaningful Key value)