I have been spending a lot of time trying to figure this out, but I have a large project that uses the WebFileUploader control. It fails to fire any events after the StartUpload is called.
The example WebFileUploader project works fine. As I tried to pare down the large project into a small one. I discovered that if I changed the name of the 3 target compile names to something else, then my small version of the project would work. Changing it back to the original it still worked. It only fails on the compiled version on Windows, using the IDE it works, large project, small project or example.
To recap, the compiled version of WebFileUploader example works. Large project fails, smaller project failed, until I changed those 3 target names, then it won’t fail again.
I’m wanting this to work on a compile on linux, but it still fails small or large project (again the WebFileUploader example works).
So at present I don’t have any project to submit that is small in nature, and having spent a lot of time on this was wondering if anyone else is experiencing anything similar.
Silly question. Is it the project size that fails or the file you are uploading. Very large files can fail on WebFileUploader (at least when I was writing Web1 apps). I can’t talk of Web2 I’m afraid.
It’s the size of the project. Any size file uploading will fail. I’ve seen entries where people are having trouble with larger files uploading. This doesn’t apply here.
The WFU keeps temporary files as it’s uploading - I wonder if you have a “stuck” temporary file, and by changing the Application’s name, it’s changing the name of the temporary file or folder?
I cleared out the source folder on Linux and re-copied it from my Windows Machine, and now if it is compiled on the Linux machine, the WebUploadFolder stuff works there as well. It still fails if I do the compile under windows and FTP it to the server (for the large project).
We did clear out both the user (c:\users<user>\AppData\Local\Temp folder (the %tmp%) as well as C:\Windows\Temp in hopes it would correct the above. But it did not.
Now, I can test with the IDE on windows, transfer it to Linux when I am ready for a build and it is working (at least for now).
Could this be a simple FTP problem? Some FTP clients “helpfully” translate line endings from Windows to Unix, and often don’t maintain file permissions properly, either of which could corrupt the app.
I’m not sure I understand. It’s working when I FTP to the Linux machine and compile there, but not under a compile on Windows. At any rate, the problem has somehow resolved itself, or perhaps clearing tmp stuff… It works in the IDE on windows, and works as a compile application under Linux (my normal process) I just have to compile on Linux, rather than from my Windows machine with a Linux build setting. - Minor inconvenience -
Also the only antivirus software I have running is Windows Defender (10).
Well, the problem is back now. WebFileUploader failed in all situations on Windows. I deleted tmp files on c:\users<user>\AppData\Local\Temp as well as on c:\Windows\Temp. That made it so that the example WebFileUploader ran, but adding that page to the beginning of my large project and running it before anything else, It would not work.
It doesn’t really crash, when I clicked on the upload button it went to a state similar to if you ran a project and then clicked on the pause button. I have break on exceptions checked. If uncheck break on exceptions, it doesn’t have that behavior, but it still fails the same way.
Also, ExecuteJavaScript fails in any window past the initial one. (It doesn’t do the expected behavior - there is no other indication)
OS?
Browser (and version?)
Does the browser console show any errors?
If you put up a public demo, I’d be happy to run tests against it. I’m known around here as the “Ghost of WFU” (my first WFU bug report was 8 years ago
So it’s breaking into the debugger with a blank page and pressing Run/Resume fixes it?. That usually means that an exception is occurring down in the compiled web framework xojo code somewhere and the fact that the program continues when you resume means that it’s actually being caught and handled correctly.
What happens if you build this app for Windows and just run the application? Do uploads work then?
In this case, are you getting error messages in the browser console?
At this point I can’t determine a small project to fail. Although it doesn’t require it to actually run any of the large project to fail. What you could try is take your largest web project, copy the WebPage1 object out of the WebFileUploader example and paste it into your project. Change the starting Window to WebPage1. That is all it takes for it to fail for us. Obviously, the FileUploader code we have buried in our project fails also…
Number of objects doesn’t tell you everything, but we 387 entries of various classes,etc. in the xojo_project file. (439 lines total)
Pressing the Run/Resume doesn’t fix it, it just continues. The upload still failed, and further in my project, a button may not respond to a click or some other thing won’t be working quite right unless I stop and restart it. (if I go directly to the button it will then work fine)
That’s Windows/IDE. Running Windows as a compiled application acts the same as in the IDE except with no indication of an error, no event after the StartUpload is fired in the WebFileUploader object to catch. (I compiled as 64-bit)
If I step over that one line of code for ExecuteJavaScript, nothing shows immediately, but if I resume lots of entries for POST commands containing …/comm/event/… all successful. No errors that I can see shown.
I have posted a feedback (#68154) along with an attached project that demonstrates what I am experiencing with trying to transition to Web 2.0.
It seems various places, events will stop working (including FileUploader) I’m hoping the sample project that I have attached to the feedback will be useful to figure out what is happening. I am not getting any messages or errors, events just quit responding. And if I have Break on exception on (like I have in my attached demo project in the feedback) than it will “pause” sometime sooner as if I hit the pause button in the IDE while not processing any events.
(my first WFU bug report was 