A few weeks ago I re-architected a large part of my app’s network communication to use the new xojo.net.HTTPSocket class rather than the older HTTPSocket class, using asynchronous communication. I develop on OS X first, and it seems to be working perfectly there, but on Windows the socket events never seem to fire. I call .send on the socket, and none of the events fire - eventually the state machine that is watching the socket times out and gives up, as no response is ever received.
Which led me to this feedback case, that perfectly describes what is going on, with the only difference being that I’m working on a desktop app, not a console app:
<https://xojo.com/issue/40980>
Any chance I’m just doing something wrong? Or are subclassed xojo.net.httpSockets really broken?
I’ve just put together a sample project that demonstrates this issue on Windows. I’ve marked it as private simply because I’m not testing on a general release. I’ve attached the sample project to this issue in Feedback: <https://xojo.com/issue/40980>.
I’ve put together a simple test project that I’d love to have some people run for me. Specifically, download the .zip file, and open the project it contains from Xojo on the Mac. Run the project natively on the mac, and press the button on the window that appears. You should see a socket response of “OK”.
Then launch it again from the mac but running in the remote debugger on any recent flavor of Windows. What do you see in the box when you press the button then?
I’m also curious to see what happens when this is run from Xojo on Windows on Windows.
I know I had issues with the Xojo.Net.HTTPSocket in Windows recently. After messing with it for a while I gave up. For me, the new Xojo framework classes are just a bit too flaky for everyday use. Hoping that changes in the near future.
Kimball- can you file a different case on this? The case you commented on is specifically about adding support for xojo.net.httpsocket in console/web apps (I’ve made that more clear in the title)- while you are discussing a Windows desktop project issue in an implementation that already exists.
@Wayne Golding - do subclasses of the new xojo.net.HTTPSocket work correctly in older versions of Xojo? As far as I understood, they have never worked when instantiated within a thread on Windows.
I don’t use them in threads, so haven’t got that experience. The app I have posts to a server that requires http 1.1, so I need to use the new framework. After recompiling with 2015R3.1 the app started to respond to the pagereceived event handler again. The subclass of the socket is very simple, the page received handler just checks for an error state & either raised an error event or a data received event.
Thanks for this thread - saved me some time. I simply don’t understand why a subclassed Xojo.Net.HTTPSocket shouldn’t work. I thought it would be possible to simply replace my old Socket implementation with a new one based on the new framework, but alas. Re-architecturing needed.
I remember seeing somewhere that the new framework HTTP socket on Windows hasn’t been implemented yet by Xojo. This is one of the reasons I haven’t renewed my license. Poor W32/64 support. How long have we had HTTP 1.1? The old socket still uses HTTP 1.0. Although I prefer Macs over PCs, this is a PC and Windows dominated world and I have to compile my project for Windows.
There was a problem with the PageReceived event not firing on windows console projects. This is marked as fixed in FB. However I’ve been using them just fine on desktop projects although there is a problem with no content being delivered unless the status is 200. This is only verified in FB.
Xojo.Net has been implemented in Web apps early this year if I am not mistaken. I was waiting for Xojo.Net.HTTPSocket to make a Paypal listener in Xojo Web, because it needs HTTP 1.1.
I started the project back in March, and today the listener runs like clockwork on 1701’s ServerWarp.