I have finally managed to get the HTTPSocket PageReceived event to fire as advertised and advise on 3 issues to avoid (under Windows / 2015 R2.2):
There is an unreported compile error when an HTTPSocket class (or sub-class) is instantiated in code from within a WebContainer. However when a socket is dropped onto the container in the IDE the following error reports:
[quote]
Parameter “NewParent” expects class WebPage, but this is class [WebContainer][/quote]
Even in a web page, the HTTPSocket (or sub-class) if instantiated in code will not trap the PageReceived event as far as I could see.
This meant the PageReceived event would only fire when an object is dragged from the library and dropped into the Naviagtor directly under the Web page and then the standard HTTPSocket class (i.e. not a subclass elsewhere in the project) was set as its super.
However there seems to be a compatibility issue with the second call to the classic HTTPSocket’s Post setting with WebFileUploader data, so the solution only works with one file at a time for now.
Nevertheless the ability to offload data to other Web servers from a Web App for processing elsewhere allows scalability using standard web technologies such as load balances etc., so I expect this websocket-like technique could be quite valuable.
Thanks Wayne for your help with this - I greatly appreciated your call!
I have found web timers to be effective to poll changes since they count down on the client independent of the server’s event loop and raise an event within that loop when they fire. Thus this method does not seem to compete with XOJO’s Web architecture (2015R2.2) but rather works with it. I have found this method can be used even when polling a property on another web page from a timer on a hidden web page.
Actually… It depends on how long the loop will run. If it’s less than a second a tight loop with DoEvents is fine in a web project. If it’ll be longer than that, I’d suggest using a WebThread (which will still consume CPU time in your app, but won’t block) or an external helper app ( which will probably run on another cpu core if one is available). Like I said above, it depends largely on what you’re trying to do and how long it will take.
For scalability a helper app on the server side seems like a good strategy. However I have found polling with a webtimer (not a server-side timer) is useful to monitor and control the long-running process of receiving http post data from a Web user asynchronously. I have not had much success with doevents, threads or server-side timers in a web app when used in conjunction with asynchronous operations.
[quote=195291:@Eric Wilson]I have finally managed to get the HTTPSocket PageReceived event to fire as advertised and advise on 3 issues to avoid (under Windows / 2015 R2.2):
There is an unreported compile error when an HTTPSocket class (or sub-class) is instantiated in code from within a WebContainer. However when a socket is dropped onto the container in the IDE the following error reports:
Even in a web page, the HTTPSocket (or sub-class) if instantiated in code will not trap the PageReceived event as far as I could see.
This meant the PageReceived event would only fire when an object is dragged from the library and dropped into the Naviagtor directly under the Web page and then the standard HTTPSocket class (i.e. not a subclass elsewhere in the project) was set as its super.
However there seems to be a compatibility issue with the second call to the classic HTTPSocket’s Post setting with WebFileUploader data, so the solution only works with one file at a time for now.
Nevertheless the ability to offload data to other Web servers from a Web App for processing elsewhere allows scalability using standard web technologies such as load balances etc., so I expect this websocket-like technique could be quite valuable.
Thanks Wayne for your help with this - I greatly appreciated your call![/quote]
Eric, make sure you file a bug report in Feedback and include all of your findings. They’ll be handy for tracking this down.
I have filled cases 39872, 39977, 40099, 40100, 40101, 40102 & 40107 demonstrating the issues, most with workarounds.
I have also filed case 39365 which impacts the new Framework’s WebHTTPSocket because this socket uses the Text datatype (not String) for URLs and Querystrings.
When posting feedback reports, better click the gear at the bottom of Feedback and go “Copy sharing link”. Not only that will ensure that you got the right number, but also you will be able to paste a link in your post, which is greatly easier for readers.
[quote=200512:@Eric Wilson]Thanks for the tip on sharing Michel. The link to 39635 is below:
<https://xojo.com/issue/39635>[/quote]
Thank you.
At first glance, after reading the case, I would suspect the invalid apostrophe to not be the regular quote but a curly quote inserted by the “smart” text features.
True enough, however there are two issues here:
(a) The “invalid” character is in the name of the filename in Windows created by a .pdf print of a Web page, so there’s no way to prevent users from creating files with such names; and
(b) Simply replacing with an apostrophe may work in that particular case (provided the new file name does not already exist), but what happens when a filename contains an em-dash or something else that crashes the system? In other words, without knowing the real cause of the issue (possibly differences between Mac and Windows text encoding related to Xojo’s code-base) any substitution table-based solution created by Xojo users may or may not work.
[quote=200527:@Eric Wilson]True enough, however there are two issues here:
(a) The “invalid” character is in the name of the filename in Windows created by a .pdf print of a Web page, so there’s no way to prevent users from creating files with such names; and
(b) Simply replacing  with an apostrophe may work in that particular case (provided the new file name does not already exist), but what happens when a filename contains an em-dash or something else that crashes the system? In other words, without knowing the real cause of the issue (possibly differences between Mac and Windows text encoding related to Xojo’s code-base) any substitution table-based solution created by Xojo users may or may not work.[/quote]
We are hijacking the thread.
But I believe the solution is to convert the file name to ASCII. This will effectively convert single quote to normal quote, same thing for usual accented characters :
if not (uFile.File is Nil) then
self.UploadedPictureList.AddRow uFile.Name.ConvertEncoding(Encodings.ASCII)
end if
Returns error in browser: [quote]Unhandled xojo.Core.BadDataException
Message: String must have a known encoding[/quote]
This breaks WebHTTPSocket in the new Framework which demands the Text datatype.
In the string-based Classic system the issue appears to be handled inconsistently. The WebHTTPSocket (or perhaps the HandleURL event or FolderItem object on the remote server) converts the apostrophe to while TextField or Message Box displayed in the client’s WebApp show an apostrophe.
[quote=200586:@Eric Wilson]WebFileUpLoader1.FileAtIndex(0).Encoding
Returns: Nil
This indicates Xojo is not picking up the encoding from the browser (Firefox & IE).
This breaks WebHTTPSocket in the new Framework which demands the Text datatype.
In the string-based Classic system the issue appears to be handled inconsistently. The WebHTTPSocket (or perhaps the HandleURL event or FolderItem object on the remote server) converts the apostrophe to  while TextField or Message Box displayed in the client’s WebApp show an apostrophe.[/quote]
You know what ? You error comes from the Text type.
I did verify the JavaScript error box that comes up when you click upload with the project you submitted.
Remove the “ToText”. This produces no error, even with two curly quotes (I did not see very well in the file name so I added one) :
if not (uFile.File is Nil) then
self.UploadedPictureList.AddRow uFile.Name
end if
Michel, you are correct it is at type conversion issue, however Text type is required for the New Framework’s WebHTTPSocket URL/QueryString which doesn’t accept strings.
I have now written the following workaround to convert from string to text with user code to solve this problem:
Dim mbClassic As New Global.MemoryBlock(len(WebFileUpLoader1.FileAtIndex(0)))
mbClassic = WebFileUpLoader1.FileAtIndex(0)
Dim mbXojo As New Xojo.Core.MemoryBlock(mbClassic,mbClassic.Size )
dim txtFilename as Text = Xojo.Core.TextEncoding.UTF8.ConvertDataToText(mbXojo)
msgbox txtFilename
Seems to work fine. Apostrophe left in tact but assumes browser uses UTF8.
That’s what I love about Xojo, you can always do low-level stuff yourself if you need to.
[quote=200602:@Eric Wilson]Michel, you are correct it is at type conversion issue, however Text type is required for the New Framework’s WebHTTPSocket URL/QueryString which doesn’t accept strings.
I have now written the following workaround to convert from string to text with user code to solve this problem:
Dim mbClassic As New Global.MemoryBlock(len(WebFileUpLoader1.FileAtIndex(0)))
mbClassic = WebFileUpLoader1.FileAtIndex(0)
Dim mbXojo As New Xojo.Core.MemoryBlock(mbClassic,mbClassic.Size )
dim txtFilename as Text = Xojo.Core.TextEncoding.UTF8.ConvertDataToText(mbXojo)
msgbox txtFilename
Seems to work fine. Apostrophe left in tact but assumes browser uses UTF8.
That’s what I love about Xojo, you can always do low-level stuff yourself if you need to.[/quote]
Fact is I believe your error came from adding a row with Text data to a WebListBox that expects String. Furthermove the error you obtained was JavaScript, not Xojo, indicating that illegal characters where injected into the DOM. It has nothing to do with Xojo.Net.HTTPSocket at that point.
Apostrophe left in tact but assumes browser uses UTF8.