AddHandler Problem in Windows (New Problem)

I have implemented a file download very similar to the example code to download a file. It has an AddHandler that should fire at the completion of the download. In fact it does in debug on my Mac but it does NOT fire on the Windows server (Abyss Webserver).

I am sure it does not fire because it should immediately turn off a progress wheel and re-enable some buttons but it never fires.

Any ideas?

OK — I take it back. I fired up a Microsoft / Sysinternals DebugView on the Windows server, added a message, and yes it fires. But something else is happening.

[quote=136848:@Mark Strickland]I have implemented a file download very similar to the example code to download a file. It has an AddHandler that should fire at the completion of the download. In fact it does in debug on my Mac but it does NOT fire on the Windows server (Abyss Webserver).

I am sure it does not fire because it should immediately turn off a progress wheel and re-enable some buttons but it never fires.

Any ideas?

OK — I take it back. I fired up a Microsoft / Sysinternals DebugView on the Windows server, added a message, and yes it fires. But something else is happening.[/quote]

First thing I would do is to run the debug under Windows and use some system.debuglog to check what may be going on. Use DebugView since the Windows IDE has a problem with WE log.

Very strange things in Windows but NOT in OSX with debug.

It seems that no statements that need to interact with the browser or app in general will actually work from the method set in the AddHandler statement. The System.Debug messages do work and output into the DebugView utility on the server.

I cannot even get a timer enabled from the AddHandler method. It seems every statement except system.debug simply does nothing … but only in Windows.

Maybe my brain is tired and I am missing something easy. More tomorrow.

[quote=136913:@Mark Strickland]Very strange things in Windows but NOT in OSX with debug.

It seems that no statements that need to interact with the browser or app in general will actually work from the method set in the AddHandler statement. The System.Debug messages do work and output into the DebugView utility on the server.

I cannot even get a timer enabled from the AddHandler method. It seems every statement except system.debug simply does nothing … but only in Windows.

Maybe my brain is tired and I am missing something easy. More tomorrow.[/quote]

OS X and Windows architecture are different enough especially as far as file management is concerned for some events not to work quite the same way.

I re-titled this thread to reflect what I now believe to be the real problem.

The actual problem is the AddHandler DOES fire and works correctly in OSX when debugging BUT when deployed on Windows Web Server running Abyss it is a problem.

The AddHandler method does run but it seems it hangs the app with most further interaction with the browser and some other XOJO functions. The AddHandler would NOT re-enable buttons that had been disabled for the duration of the download or be able to enable a timer in an attempt to do other logic outside of the AddHandler. It is as if the AddHandler never ended so the browser is never updated with changes. I worked around the problem by starting a timer BEFORE the download and had it wait, exiting with each tick, util a BOOLEAN property for the Webpage was true that got set in the AddHandler. After the BOOL was true I did the rest of the logic to re-enable buttons and turn off the progress indicator in the timer.

I am going to try and create a sample project that will identify if this is an issue with Windows on a Webserver.

[quote=137081:@Mark Strickland]I re-titled this thread to reflect what I now believe to be the real problem.

The actual problem is the AddHandler DOES fire and works correctly in OSX when debugging BUT when deployed on Windows Web Server running Abyss it is a problem.

The AddHandler method does run but it seems it hangs the app with most further interaction with the browser and some other XOJO functions. The AddHandler would NOT re-enable buttons that had been disabled for the duration of the download or be able to enable a timer in an attempt to do other logic outside of the AddHandler. It is as if the AddHandler never ended so the browser is never updated with changes. I worked around the problem by starting a timer BEFORE the download and had it wait, exiting with each tick, util a BOOLEAN property for the Webpage was true that got set in the AddHandler. After the BOOL was true I did the rest of the logic to re-enable buttons and turn off the progress indicator in the timer.

I am going to try and create a sample project that will identify if this is an issue with Windows on a Webserver.[/quote]

The UI does not get updated until the end of an event. If the method that manages the event does not end that would prevent the UI from updating. Maybe Windows does not report adequately the end of the download. The timer is a good workaround.

Please, I’d like to see an example project. Just out of curiosity, what version of the IDE are you running? We did a lot of work on AddHandler with respect to the web framework this spring.

I am using 2014 2.1

I will see if I can create a project that will fail but it could be all related to the combination of my deployment on Windows Server 2008 r2 and the Abyss x2 Web Server.

The thing that is strange is the UI never gets updated even when the AddHandler finishes AND the AddHandler will NOT start a timer. It can write to properties for the form but it is as if it cannot call any code to execute … but only in Windows. Works as expected in OSX debug.

I will let you know when I have a sample project that fails.

[quote=137161:@Mark Strickland]I am using 2014 2.1…/…
The thing that is strange is the UI never gets updated even when the AddHandler finishes AND the AddHandler will NOT start a timer. [/quote]

Pardon me, but it is not quite clear if the handler does fire when the download is complete or not. In other words, is it a problem of Windows not reporting the end of the download, or an UI not updating ?

It is almost one of those things you need to see.

  1. The UI does NOT update even when the AddHandler event finishes.
  2. The code in the AddHandler Event to start a timer does NOT actually start the timer. It never starts and does not generate any error.
  3. I placed several System.DebugLog messages in the AddHandler event and they all write messages to the DebugView program. I even put one as the very last line of code in the AddHandler event and it does write to the DebugView program.
  4. Most of the buttons on the UI are disabled before the download but a few are not. There is a button to return to a menu on the UI and it seems to stay responsive and will navigate away from the page.
  5. I can write values to properties on the Web Page. I used this as a work around. I start a timer BEFORE the download starts. It waits on a boolean to be true other wise it just exits with each “tick”. In the AddHandler I set the boolean to true and the timer then recognized the “flag” and processes the finishing of the download and updates the UI by enabling the buttons and stopping the progress wheels.

I have decided I don’t like downloading files because of the very nasty behavior of Internet Explorer. If not specifically configured as Trusted Site in IE the requested download pops up the information bar in IE and asks if it is OK to download. If you answer YES it navigates away from the page and we know what that does in a XOJO Web App.

I am looking for a “Plan C” to download a file but I may just have to provide instructions to configure a Trusted Site in IE.

Did I mention this is making me crazy?

I wouldn’t recommend Internet Explorer for use with a Xojo web app. IE stinks and especially in IE 11, they have broken a lot of functionality in a lot of sites.

Have you checked to see if this behavior occurs in Firefox, Chrome or Safari? I bet you’ve tested only in IE…

We have received another report with a sample project which points to a bug between AddHandler and Timer on Windows and we’re looking into it.

Ok. The one we’ve resolved was only in the 2014r3 Alphas. Please file a bug report with a sample project so we can look at this.