For CMD + V, after several tries, in macOS this “works”
In TextChange event:
if keyboard.AsyncCommandKey and Keyboard.AsyncKeyDown(09) then
me.Text=""
End If
I tried to save initial Text to replace in the test instead of “” but it seems this code is executed after the paste is done, so it ends with the value pasted.
This is what we call in Spain a “apa” (a very bad done job) 
THIS: is a great sample of a “apa” (to explain!) https://i.ytimg.com/vi/oOsp79T99GU/hqdefault.jpg
After more tests you only need:
TextField1 - Open event - me.AcceptTextDrop
and that way, what you drag will not be added to the TextField1
So for macOS, if you don’t put the code in Open event, then all text you drag to TextField will be added to TextField.
If you add the me.AcceptTextDrop then the dragged text will not be added (I guess you need code in DropObject to handle it)
For Windows 10, if you don’t put the code in Open event, the drag will show an icon telling you can’t drop the text there.
If you add the me.AcceptTextDrop then the icon will say Copy but I guess you need code to handle the drop.
Why the keydown event can’t detect command, option, control, fn, shift, etc.?
If I want to create this Keyboard in Xojo is not possible? (pressing the command key):
Edit: maybe using a timer?
because those are not “key strokes”… they are key stroke modifiers, and have no meaning without another key.
They CAN be detected, just not in KEYDOWN
Ok, after testing/learning a lot I found that:
To disable dragging:
As mentioned above, just add me.AcceptTextDrop to Open even in TextField1
To disable EditPaste menu:
TextField1 - GotFocus - EditPaste.Visible = False
To enable EditPaste menu for other controls:
TextField1 - LostFocus - EditPaste.Visible = True
Note: making invisible EditPaste then there is no need to use a timer to detect the command key. At least I learned that I can use a timer to detect the command key.
I made a simple program with 2 TextFields. The first one will not allow Command + V, the EditPaste menu is invisible and will not allow dropping text, the second works as normal. The only code used is:
[code]Sub GotFocus()
EditPaste.Visible = False
End Sub
Sub LostFocus()
EditPaste.Visible = True
End Sub
Sub Open()
Me.AcceptTextDrop
End Sub[/code]
Hope this help.
[quote=402252:@Alberto De Poo]To disable dragging:
As mentioned above, just add me.AcceptTextDrop to Open even in TextField1
[/quote]
Are you sure??? I got the same solution except I add a return to the DropObject event.
Let me check again, maybe it is related with EditPaste.Visible = False?
Edit: Yes, I’m sure. The only code is TextField1 - Open - me.AcceptTextDrop, no events/code on TextField2
Running on macOS 10.12.6
I just got a Feedback Case closed as not reproducible. Maybe it has something to do with the macOS version?
This is simply weird. If the Paste menu is invisible then with a me.AcceptTextDrop one cant drop text, but without it one can. To my mind something is not as it should be underneath
I think I didn’t make myself clear, the Paste menu (visible or not) has nothing to do with the AcceptTextDrop.
Testing on Windows 10, I can see the OS difference, it shows an icon (circle with diagonal line) to represent that you can’t drop text (without me.AcceptTextDrop). If I add me.AcceptTextDrop then the icon change to Copy, to give visual clue that you can drop text there, but without DropObject code, then nothing happens.
After that I tested on mac without DropObject and behaves just like Windows 10 (without the icon). If I add to DropObject:
me.Text = obj.Textthen the dragged text will appear on TextField
My guess on macOS (at least 10.12.6):
In other words, on mac without AcceptTextDrop the OS drop/paste the dragged text in TextField (without Xojo intervention/code), like an automatic paste feature. With AcceptTextDrop we take control of the situation and must handle the drop with code ourselves.
I hope my idea is more clear. Of course I know next to nothing on how the OS works but from my tests that is my guess.
The result is the same, but I am not sure this behavior is an OS behavior. It can be a Xojo specific feature.
And when you specifically tell Xojo you will be in charge with the textFileDrop, Xojo awaits you to add the DropObject Event and place code there to deal with the drop.
This is IMHO (and if my memory serves correctly).
Markus ?
This works for me in Mac, haven’t tried it on PC…
Sub DropObject(obj As DragItem, action As Integer) Handles DropObject
Return
End Sub
Function MouseDown(X As Integer, Y As Integer) Handles MouseDown as Boolean
If IsContextualClick then return true
End Function
Sub Open() Handles Open
me.AcceptTextDrop
End Sub
… and in the menu for that window there is no “Paste” menuitem.
Lennox
Lennox, you too need Return in DropObject?
Good to see you find a solution. I rarely use Contextual Menus, so I didn’t test that part. Your solution works for that too.
Just tried it in Windows/PC
Control-V still allows paste, how can I prevent Control-V from pasting text in a TextField in Windows/PC?
Thanks.
Lennox
Maybe you need to handle the clipboard within your app?
https://documentation.xojo.com/index.php/Clipboard
Do not clear the clipboard to prevent a paste. That is destroying data that is not yours. That is malware.
If you know what is in the clipboard, and you use TextField’s TextChange, then you can check if the user is trying to paste the information and remove that from the TextField. This way you do not clear clipboard contents.