So I can't reproduce what you see. What is the stack trace at the moment of
Wim.
Post by Mario Diethelm GuallarHi Wim,
thanks for your answer. Follows a description of the WFileResource problem
- the application stores at server level some files that users could
review time to time. Most of those files are PDF files (papers, letters and
stuff like that) and image files (pictures, charts and others) plus some
other kind of files just for inquiry purposes
- the application allows the user to seek for one of those files using
some filters stored at data base level. In a one by one basis the user can
display the file in a separated browser window
- the problem arises with the ISAPI connector when the user selects
the "View File" option. For instance, surfing in the same machine that is
running the application, the browser tries to deliver the
file at localhost/application/application.dll/<file> getting a file not
found error (HTTP 404). With the built-in httpd connector the browser
delivers the file at 127.0.0.1:8080/application/<file> perfectly
The code that I am using to set up and then display the file is the
following (is the same code for both, the built-in httpd connector and the
string mimeType = GetDocFileMimeType(dDocFileName->text()); // gets the
file's mime type from data base
string serverFileName = WApplication::instance()->appRoot() +
myApp->GetAppServerTargetFolder() + dDocFileName->text();
dDocResource = new WFileResource(mimeType, serverFileName);
dShowDocument->setLink(dDocResource);
dShowDocument->setLinkTarget(Wt::TargetNewWindow);
- myApp is a pointer to an object that holds parameters about the running
application.
- dDocFileName is a WLineEdit * that contains the file name selected by
the user
- dDocResource is a WFileResource *
- dShowDocument is a WPushButton * ("View File" option)
I have verified that the string serverFileName holds exactly the same
string (file's server full path) for both ISAPI and built-in httpd
connectors.
I would appreciate your comments.
Thanks. Regards.
________________________
*Mario Diethelm Guallar*
------ Original Message ------
Sent: 08-04-2015 08:15:46
Subject: Re: [Wt-interest] WFileUpload and WFileResource objects problems
under IIS
Hello Mario,
This sounds like this is indeed a bug in the ISAPI handler. I will check
this.
I'm not sure I understand the point you're trying to explain in your third
bullet. Can you send me some example code?
Best regards,
Wim.
Post by Mario Diethelm GuallarHi,
I have been trying to figure out what is causing the above mentioned
- about the PDF generation, it was an application bug. I was using a
relative path to refer to the styles file (.CSS) for the report. Now,
using an absolute path to refer to the styles file, the PDF file is being
generated correctly. Sorry about that.
- about the WFileUpload widget problem, I have tested with different
files and the problem seems to arise every time that I try to load a file
bigger than 50Kb. I have compiled widgetgallery to run under IIS and I get
the same results. Every time that I try to upload a file bigger than 50Kb,
the application crashes causing the application freeze or restart
(randomly) and at IIS level the application pool gets stopped
- about the WFileResource widget problem, what I am trying to do is
simply display in a separate browser tab an existing file (.pdf, .jpg or
others) that is selected by the application user. The problem seems to be
that no matter the file name that is informed to the WFileResource
(relative, absolute, as an URL), the ISAPI connector adds the full site
path as file name prefix (for instance, if you try to surf from the same
machine where the application is running, the application tries to open the
file at localhost/application/application.dll/<file name>
As I commented before, using the built-in httpd connector both
WFileUpload and WFileResource work ok.
I would appreciate any comments or clues regarding WFileUpload and
WFileResource problems under IIS.
Thanks. Best regards.
________________________
*Mario Diethelm Guallar*
------ Original Message ------
Sent: 01-04-2015 19:31:23
Subject: WFileUpload and WFileResource objects problems under IIS
Besides the problem related to PFD generation using the ISAPI connector
commented in a previous e-mail (always gets a zero bytes corrupted PDF
file), I am experiencing problems with WFileUpload and WFileResource
objects under IIS.
Every time that I start a file uploading to the server using the
WFileUpLoad widget, the application crashes while the WProgressBar widget
is showing the upload progress (at random levels). The application then
starts a completely new session.
In a similar way, the WFileResource object always ends with an HTTP 404.0
error every time that I try to display a file (PDF, .jpg or any other). The
application is using absolute paths to specify each file.
The same application widgets work just fine using the built-in httpd
connector.
Any idea about what is going on?
thanks. Best regards.
________________________
*Mario Diethelm Guallar*
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
by Intel and developed in partnership with Slashdot Media, is your hub
for all
things parallel software development, from weekly thought leadership
blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
witty-interest mailing list
https://lists.sourceforge.net/lists/listinfo/witty-interest