I have a container control with a canvas layered on top, and controls on the canvas. The canvas was added so I can scroll the controls on it when the CC gets resized. The scrolling worked and continues to do so. Later, I added drag/drop of files onto the canvas for processing. Luckily there is a nice example in the Xojo Examples/Desktop folder, and I cribbed how to do it from there. That, too, worked. But now I notice that, all of a sudden, files dropped are rejected and return to their folder. The DropObject event of the canvas isn’t even called. I checked everything against the Xojo example, and all looks identical between the two. The example works fine. This is Xojo 2019r3.1
How do I debug this?
Just to check the obvious, by this do you mean you added a canvas to the CC, or placed the canvas over the CC on the window? (“layered on top” is a little vague)
I’m sure that when I originally started on that item, it just had the CC with controls on it. Then to implement the scrolling aspect, I would have moved all the controls off the CC, added a canvas of the same size as the CC so it exactly overlaps it, and then moved all the controls back to where they were.
What happens if you drag the canvas off the CC (do the controls move with the canvas?) and run the project?
The AcceptFileDrop is correct?
I sometimes (rarely) have it that code looks perfectly fine but isn’t working. I have to delete the event and add it and the code again.
Have you looked at the project with Arbed to check for project corruption?
What happens if you drag the canvas off the CC (do the controls move with the canvas?) and run the project?
If I do that the controls go with the canvas.
The AcceptFileDrop is correct?
I added a second AcceptFileDrop, explicitly specifying “image/jpg” (in fact I copy/pasted that off the Xojo doc page for AcceptFileDrop). I left the first one in place (the first one was copied from the Xojo examples). Drag/drop of a .jpg file was rejected.
I’d better go back and check that the .open in which the AcceptFileDrop sits actually executes. Also, I use Cornerstone for version control, I’d better go back and look for a version which works, and then look for changes.
I’m unfamiliar with Arbed. I’ve been having some IDE crashes recently, related to doing a number of Undo’s in a row, I suppose that might have had some effect. Where can I find Arbed?
Did you add jpg to your file types?
Combine the two separate AcceptFileDrop into one?
For Arbed you COULD use Google … 
http://www.tempel.org/Arbed/Arbed
Taken jpg out now.
ha ha, yes, I did google but got a reference to a Belgian steel company 
Anyway found that now and will look into it - thanks.
It helps to add Xojo to your search … 
I still suspect the filetypes might be the problem.
Yeah, that’s how I got to it.
Re the filetypes, let me look a bit further.
Try acceptFileDrop( "public.jpeg" ) Use the UTI instead IMME.
Or for all supported image formats (macOS) me.acceptFileDrop( "public.image" )
I only added that second AcceptFileDrop as a test, in case it turned out that I could then drag/drop an image but not other files. That turned out not to be the case so I have removed that. I’m using the “AllFiles” example from the Xojo Examples, since I want the user to be able to drop any file there.
I then checked that drag/drop in my app works on my wife’s Mini, which it does. Copying the .app from her machine to mine, and it works here too, thus eliminating possible oddities like I have two screens, she has one. Her .app build number, using my version numbers, is 141.
Going back through Time Machine and retrieving past versions then, still using my build numbers, 141 works, 142 works, and 144-1 doesn’t. I’ve been up and down inside Cornerstone (which uses Subversion) comparing and looking for differences in the project and can find nothing of substance between these versions in terms of the project contents.
The user can adjust the height of the CC and its canvas, using a grabber. Around the time that the drag/drop stopped working, I added a Pref to allow the user to fix the initial height of the canvas and its CC and to have that or the changed value saved over app restarts, so I did wonder whether I was somehow, for example, inadvertently setting the canvas height to zero. But checking with the debugger at runtime seems to disprove that.
But that at runtime I am doing something to the CC and its canvas which is messing things up seems like the best bet at the minute.
OK I have the cause.
The CC/Canvas is on one page of a PagePanel. What I had also done was to add another page to the PagePanel (or more accurately, start to use page 0 which had not been used heretofore); I put an HTMLViewer on it and sized it to be the same size in the IDE as the PagePanel. I did notice that in doing so it covered up the little PagePanel navigator that is visible in the IDE for switching between panels, but thought nothing of that. It does seem to be a child of the PagePanel; clicking on it brings the red outline of the control behind it.
But if I make it smaller so it has a border round it (say 20 px), then when running the app that 20px becomes available for dropping files on the CC/canvas.
Is there a way in the IDE to see what the parent of a control is? I couldn’t find one. I will try putting the HTMLViewer in a container and instance that onto the PagePanel.
1 Like
Yes, instancing another CC onto the PagelPanel has fixed the problem. Is there a reason for needing to do that in this case?
would need to check out a sample but it doesnt seem to make sense you should have to do this given what I know at this point
Nice sleuthing 
Thanks. What’s frustrating is knowing that 30 - even 20 - years ago I’d have solved it a lot faster.
would need to check out a sample but it doesn’t seem to make sense you should have to do this given what I know at this point
Well, the HTMLViewer being laid straight on a PagePanel page seemed to interfere with the control on another PagePanel page from being able to do drag/drop. Move it into its own CC and instance that onto the PagePanel page, and all is peachy.
The clue was that the HTMLViewer, directly on the PP page, obscured the little panel the IDE puts there so you can, in the IDE, navigate to other PP pages. And I couldn’t get it to stop doing that.
HTML Viewers do have a few known “issues” when on a layout
Basic functionality has to be … oh why do I bother …
1 Like
Some of how HTMLViewer behaves on macOS isn’t Xojo’s doing.
Should they be able to “fix” some of this behaviour ? I suppose they could if they subclassed and overrode a bunch of WKWebView or whichever one it is in use now (I honestly dont know which is is)
nothing time, money and the right expertise cant / couldnt fix I suppose
