I found the workaround. I use a suggestion on the site about simulating a
web post:

http://www.elevatesoft.com/supportfaq?action=view&category=ewb&question=tserverrequest_formdata

If I use this, the server does not freeze anymore and the data is saved. One
little thing: the é not really saved as é but shows up in the SQL Server as
é. In the browser in and forms it is shown correct. So, my simple solution
with sending a var-value list to the server does not do the complete job.
You need to simulate a webpost.




"Matthew Jones"  schreef in bericht
news:49BD3009-714A-4D0F-8666-4613C1CD0F79@news.elevatesoft.com...

Ronald wrote:

> If I add the header: Content-Type: text/plain;charset="utf-8" then my
> server .exe now freezes also in Explorer. Maybe a dumb remark, but it
> seems like I do not really send UTF-8?

UTF8 requires certain things from a characters over the 127 value. The
accented character will have that high bit set, and it is possible that
something is parsing it and not interpreting it properly. Hmm, is this
the last character in the string? I wonder if there is a nul byte
(zero) following, and then the parser wonders off into memory.

Anyway, I think you have two steps here to help debug. First, I don't
really understand where this is failing - sending to or from the
server, but use the F12 debugging capabilities of Chrome to see what is
happening. You can set breakpoints and everything. Once javascript is
stuck in a loop, you lose the browser, but if you can break point it
you can often see where it is failing.

If it is the server, then you need to work out how to get the debugger
on that. I suspect it would be hard, but once you have it you can hit
pause and see where it is stuck.

Good luck!

--

Matthew Jones

A little too early...
It works fine on Explorer, but on Firefox the server still freezes.

"Ronald"  schreef in bericht
news:5F81B0C5-3E43-47CC-80CA-30CE2A151988@news.elevatesoft.com...

UTF8 is a real problem. Meantime I found the following. I I use the
SubmitForm method of the form it works correct and no the .exe does not
freeze. Apparently the SubmitForm method does something important that I
miss.

"Matthew Jones"  schreef in bericht
news:49BD3009-714A-4D0F-8666-4613C1CD0F79@news.elevatesoft.com...

Ronald wrote:

> If I add the header: Content-Type: text/plain;charset="utf-8" then my
> server .exe now freezes also in Explorer. Maybe a dumb remark, but it
> seems like I do not really send UTF-8?

UTF8 requires certain things from a characters over the 127 value. The
accented character will have that high bit set, and it is possible that
something is parsing it and not interpreting it properly. Hmm, is this
the last character in the string? I wonder if there is a nul byte
(zero) following, and then the parser wonders off into memory.

Anyway, I think you have two steps here to help debug. First, I don't
really understand where this is failing - sending to or from the
server, but use the F12 debugging capabilities of Chrome to see what is
happening. You can set breakpoints and everything. Once javascript is
stuck in a loop, you lose the browser, but if you can break point it
you can often see where it is failing.

If it is the server, then you need to work out how to get the debugger
on that. I suspect it would be hard, but once you have it you can hit
pause and see where it is stuck.

Good luck!

--

Matthew Jones

Ronald wrote:

> One little thing: the é not really saved as é but shows up in
> the SQL Server as é. In the browser in and forms it is shown
> correct. So, my simple solution with sending a var-value list to the
> server does not do the complete job. You need to simulate a webpost.
>

That "é" simply suggests to me that your SQL Server, or the utility
you are using to read the table data are not using UTF8 encoding but
some ANSI code page.

So, to be clear. You have an EWB application that is doing a
TServerRequest, and when that is done, the server code in an IIS DLL
written in XE5 gets to run, but when it accesses the
Request.ContentFields of the request it is freezing?

Have you used the Chrome debug to see the exact data being sent?

I have found the Chrome "PostMan" tool very handy for setting up
requests, and you can put in raw data, and it may be able to work
things out for you.

Fundamentally, you need to get the debugger into that DLL.

--

Matthew Jones

Yes, but in fact it is an .exe not a .dll that does the actual post and I
use XE2 (I made a mistake). I will try Chrome to see what is sent.


"Matthew Jones"  schreef in bericht
news:1F0D3521-05B6-4A7A-AFE0-22026DF9D024@news.elevatesoft.com...

So, to be clear. You have an EWB application that is doing a
TServerRequest, and when that is done, the server code in an IIS DLL
written in XE5 gets to run, but when it accesses the
Request.ContentFields of the request it is freezing?

Have you used the Chrome debug to see the exact data being sent?

I have found the Chrome "PostMan" tool very handy for setting up
requests, and you can put in raw data, and it may be able to work
things out for you.

Fundamentally, you need to get the debugger into that DLL.

--

Matthew Jones

Ronald,

<< I mean the .exe on the server (webbroker). I do not set the
contentlength.  Could it be that Chrome and Firefox have a problem with
that? >>

No, but the WebBroker application may have an issue with the UTF-8 character
set used for the form data.  EWB's HTML loader page sets a document-wide
content type of text/html with a UTF-8 character set, and that is used as
the character set for all HTML forms that are submitted to the back-end web
server.  If your web application or web server isn't expecting such an
encoding of the character data, then it will present a problem for it.

IOW, it doesn't have anything to do with the front-end EWB application or
browser.

Tim Young
Elevate Software
www.elevatesoft.com

Ronald,

<< UTF8 is a real problem. >>

UTF-8 is the accepted way of handling Unicode characters for web
applications that transfer data.

<< Meantime I found the following. I I use the SubmitForm method of the form
it works correct and no the .exe does not freeze. Apparently the SubmitForm
method does something important that I miss. >>

I thought you were using the SubmitForm method before.  Were you using a
TServerRequest component before ?  If so, then you need to make sure to set
the Content-Type header for the server request, and you're going to want to
use UTF-8 for the character set.

Tim Young
Elevate Software
www.elevatesoft.com

Ronald,

<< I found the workaround. I use a suggestion on the site about simulating a
web post: >>

You're *still* going to need to specify a UTF-8 character set so that the
extended characters are translated properly from end-to-end.  You'll just
specify it in the MIME header for the applicable section (above or under the
Content-Disposition header), instead of as a header for the entire request.
That example doesn't do so because it's sending basic text without any
characters that may need special code page interpretations.

Again, the problem is that your back-end application and/or web server isn't
handling UTF-8 character encodings properly.  The EWB Web Server (and
modules built for it) transparently handle UTF-8 character set encodings
properly.  What you see coming into an EWB Web Server module is always just
Unicode strings for text content and binary strings (AnsiStrings) for binary
content, such as what is present in MIME-encoded form data with file
attachments.

Tim Young
Elevate Software
www.elevatesoft.com