as the subject says:
Dim dlg As New SaveAsDialog etc…
I can type into, but cannot paste into the filename field.
macOS XOJO 2019r3
as the subject says:
Dim dlg As New SaveAsDialog etc…
I can type into, but cannot paste into the filename field.
macOS XOJO 2019r3
What have-you done before wanting to Paste something ?
I suppose your Clipboard holds some texte.
Using Drag and drop in the dialog, sometimes, disable the Paste, not not only.
What Control had the focus when You called the dialog ?
Sometimes, the Paste goes to theat Control.
More data are needed to make a useful guess.
Adobe apps have had this issue for years, it annoys me to no end, because when exporting a image to web, it never remembers the specific file name that I use for the exported image.
[quote=473437:@Emile Schwarz]What Control had the focus when You called the dialog ?
Sometimes, the Paste goes to the Control of the window behind the Dialog.[/quote]
Peter ?
Sorry Emile (was sleeping
No drag-drop, just some text on clipboard that I wanted to name my save file with. As for which control had the focus before, not sure, but I think the originating window/tap panel had only a canvas and a bunch of buttons so nobody had the focus.
Is this an OSX thing or XOJO’s fault?
I do not know (I suppose Xojo, but who really knows ?)
When that started, I noticed that I had a Window with a Listbox and the Lisbox get the clipboard text as New Row / New text.
Sometimes, the Paste do not worked, sometimes a click in OK do not worked (Open or Save, I forgot).
Then, in my window, in the MenuItem, I added a check if that window was frontmost and if so add go ahead / if not, do not Paste anything. I think it was enough.
The other related bug is macOS (El Capitan here): when this happened, a click in Cancel, rtry to save and Paste without trying anything else worked.
BTW: I do what you want to do many times a day, with or without any (my) Xojo created applications.
Best advice right now is to create a brand new project with only a button with the code to display the SaveAsDialog and check that (of course, after quitting everything and reboot macOS and Xojo).
Have you looked at what type is on the clipboard ?
Apple used to ship a tool called Clipboardviewer as an example that would let you see all the different data types on the clipboard (there can be several at once)
It may be that the paste fails because the type the dialog expects isnt present and so it cannot paste
I didn’t check explicitly what flavors were on the clipboard, but I did check by pasting into TextEdit to confirm there was at least a text flavor that the dlog should readily accept
textedit accepts a lot of different types
and that could include one that the dialog does not and may explain the difference
its the only reason I can think of that makes sense why it would paste into textedit but not the dialog
maybe, but a) the paste into textedit was editable text (so at least had utf8 flavor I would think), and b) the source copy came from a listbox cell. If it happens again i’ll look with Clipboardviewer to see what’s there as you suggest.
Even if the number of characters - for a file name - is long (Yes, there is a limy on macOS), it may be too long in your case
So, try to copy a simple word (less than 31 characters for example *) in the Clipboard and run your program.
Once the test ended, chack if the Clipboard text is the same and still less than 31 characters.
I tried with just “test” and it failed too (cut failed as well), and most other times it works with even long filenames, very annoying.
I have no issue when testing with ExeWrapper. It was built with 2019r1.1; do you still see the issue if you use an older version? Do you have an issue pasting into the ExeWrapper save dialog?
haven’t tried ExeWrapper, and the problem is this occurs “once in a while”
Oh well darn, that will make it significantly harder to debug. The only reason I was suggesting you test ExeWrapper is that I can confirm it’s working here in that app for me, and we know which version of Xojo it was built with.
If there’s anything more I can do to help, let me know; but I’m stumped now
Thx Tim, it’s one of these once-in-a-while things that are just frequent enough to drive one crazy, but infrequent enough to make it very hard to fix.
Are you using a modal save dialog or a sheet save dialog. Adobe uses the modal dialog. Maybe it’s because of how the save dialog is displayed?
It could be! I switched to modal dialogs and not sheets because the window was so small the sheet animation was goofy.
Ha ha… It also avoids “sheet creep” whereby a Sheet Window can get longer and longer until the buttons appear offscreen. This phenomenon was introduced in Yosemite and while is greatly reduced in newer versions, can and does still happen with 10.15. The last I heard was that the “functionality” is the same as 10.14, which indicates that it’s not a regression and is completely unlikely to be fixed until management really puts attention on fixing the macOS.
Can you share a bare bones project that display that behavior (with the OS # to run it) ?