URLConnection and Xojo.Net.HTTPSocket on Windows 10

I know there was some discussion over the last six months on the forum regarding URLConnection and Xojo.Net.HTTPSocket. Windows is a secondary platform for me, and I admit that I didn’t follow all of the discussion but I’ve been trying to catch up and it’s a little confusing. I know there were some problems but I’m trying to figure out where we are at it now.

There is an example included with Xojo that doesn’t seem to work on Windows 10 anymore. It’s in Communications > Web Services > Twilio. Both URLConnection and Xojo.Net.HTTPSocket just crap out. ContentReceived/PageReceived don’t fire, there is no error, nothing, the app just quits each time. This works fine on the Mac. Simpler URLConnection examples work, but not this one.

I PM’d @Paul Lefebvre as I thought it was maybe just an issue with the example but now I think it’s a deeper problem. I have discovered the same issue in one of my apps - works fine everywhere, except Windows 10, where the app silently dies.

Can some Windows gurus bring me up to speed? Should these classes be solid in 2019r1 or are you all quietly working around the problem now?

I tried to use URLConnection in 2018r4 but it failed to pick up proxy settings (<https://xojo.com/issue/54907> - marked as fixed, but only for Windows 10). In 2019r1 it works on Windows 10 but not Windows 7 (<https://xojo.com/issue/55418>).
We are not able to use URLConnection because of this and are still running our own implementation of winhttp through API calls.

I’m far from a Windows guru but my desktop app is primarily used on Windows. I was hanging out for URLConnection because our web services moved to HTTP 1.1 responses and the classic HTTPSocket couldn’t support that. I’m finding URLConnection is solid enough. I just had to change my install script to deploy a Windows update for Windows 7 users plus change the error numbers that I was handling.

I wonder if this is relevant: <https://xojo.com/issue/55420>

In the Twilio example included with Xojo, PageReceived (or ContentReceived on URLConnection) doesn’t appear to fire at all but perhaps it’s the same issue.

This is a showstopper for me, so I made a Feedback case: <https://xojo.com/issue/55629>

I know that at XDC talking to various engineers there are improvements/fixes in “one of the next few releases” (them being vague enough to make sure not to be committal to a given release). my gut feeling is 19r2. but dont hold me to that. cant speak about either of those cases directly.

I’m aware that 19r1 have 2 no-gos deserving a dot release, URLConnection and the Listbox leaking. Anything else?

I try to keep all my projects on the latest release. There are caveats to doing that, of course, and it won’t work for everyone, but it’s worked pretty good for me until now. This is one of the few times when this release (19r1) is actually useless on a whole platform (Windows) and that’s very, very disappointing.

I agree on the dot release. This is actually the last day of my current license and it doesn’t feel particularly great to have to buy the next version just to get this bug fix for something so broken (assuming it might get fixed for the next version).

For the record, @William Yu marked my case as Verified quickly and some hours later, marked it as Fixed, and that is an excellent response to a showstopping bug like this, and I’m grateful for his response. My remaining gripe now is that this one of those situations in which we need a targeted dot release - a big bug like this shouldn’t wait until the next major release.

Every time we find something like “a bug got into the release, something essential is broken”, it needs a new release or dot release ASAP.

There where much more serious bugs on 2018r4 and they waited until the next mayor release to fix those. As in that release was unusable, in 2019r1 at least it deppends on your needs.

I’m in the same position than @Jason Tait, I need some changes in an App for a server updating to TLS 1.2. It is usable and stable most of the time. For api calls works just fine.

Of course, if the final user use Proxy or if you need to download large files, it is still buggy.

My feeling is becoming - a bug got into a release therefore it is no longer a regression and can be placed in the queue. It is almost as if the unpaid staff (us pre-release testers) aren’t doing our job properly and being punished for it.

The problem I have with the release cycle is thus; A pre-release is posted, I’ll use 2018r4b2 as a perfect example, I tested 2018r4b2 right away, within a day I found a critical flaw with it which meant I couldn’t test it any further. I had to wait until 2018r4rc3 when it was fixed to finally test it again, let me say that again, I got to test it in the release candidate, days before launch! Of the 25 ish days the pre-release was available I only got to use it for about 6 days. So from me, that brand new feature got very limited testing during the ENTIRE testing phase, and we’re STILL having issues with it on windows because we have so little time to test things, and no knowledge of what else the new feature touches to test those things as well.

A company have testers, must have. An outside team of volunteers is just an extra guarantee. The volunteers NEVER are guilt of something with bugs reaching the market, the company IS. Once a bug escapes the depuration process, the company in this case punish themselves rushing for a fix, and an out of schedule release with those fixes. Or the market punishes such company dropping sales. Stability >> New Features, EVER. That’s the reason dot releases exists. Stability.

Well, from browsing Feedback reports, it looks like it’s down to William and Greg for bug fixes. There’s only so much two people can do. I don’t know how long it takes to compile and prep a new version of the IDE for release, but I would think that it’s a significant undertaking that takes away from actually developing/triaging. And I gather from some blogs about XDC that Xojo feels that staffing is currently adequate.

IOW, I don’t think the pace of bug fixes, features, or dot releases will increase.

builds are mostly automatic and have been or some time

Then you’ve missed at least two others :slight_smile:
Let’s dont forget Travis, and just recently I’ve noticed one of Paul’s first engineering tasks: <https://xojo.com/issue/2073>
And who knows (Xojo doesn’t need to and therefore won’t tell us, as we all know)… what other goblins might bet at work that don’t like to be named in public or are secretly being worked with :wink:

[quote=435687:@Jürg Otter]Then you’ve missed at least two others :slight_smile:
Let’s dont forget Travis, and just recently I’ve noticed one of Paul’s first engineering tasks: Feedback Case #2073
And who knows (Xojo doesn’t need to and therefore won’t tell us, as we all know)… what other goblins might bet at work that don’t like to be named in public or are secretly being worked with ;)[/quote]

Thanks for that. I stand corrected.

[quote=435468:@Gavin Smith]I know there was some discussion over the last six months on the forum regarding URLConnection and Xojo.Net.HTTPSocket. Windows is a secondary platform for me, and I admit that I didn’t follow all of the discussion but I’ve been trying to catch up and it’s a little confusing. I know there were some problems but I’m trying to figure out where we are at it now.

There is an example included with Xojo that doesn’t seem to work on Windows 10 anymore. It’s in Communications > Web Services > Twilio. Both URLConnection and Xojo.Net.HTTPSocket just crap out. ContentReceived/PageReceived don’t fire, there is no error, nothing, the app just quits each time. This works fine on the Mac. Simpler URLConnection examples work, but not this one.

I PM’d @Paul Lefebvre as I thought it was maybe just an issue with the example but now I think it’s a deeper problem. I have discovered the same issue in one of my apps - works fine everywhere, except Windows 10, where the app silently dies.

Can some Windows gurus bring me up to speed? Should these classes be solid in 2019r1 or are you all quietly working around the problem now?[/quote]
Apparently the TwilioSMS example, included with Xojo, hasn’t worked right as far back as 2018r2 on Windows. I didn’t bother trying further back. So Xojo.Net.HTTPSocket (and URLConnection) has been broken for HTTP push on Windows for at least that long.

:frowning: