Hi Thierry,

Downloading a 24MB piece with Awimggetpict() causes a serious error, of course linked to the limits of VFP 32bits.
Would it be possible to use the Rick bypass .lUseLargePostBuffer = .T. (with Awimggetpict) ?

Thanks in advance,

Vincent

Hi Vincent,

.lUseLargePostBuffer applies to download while awImgGetPict (derived from awImgGetFile) generates an Ajax File Upload command using the jQuery File Upload library.

In jQuery File Upload we can implement a validation process with maxFileSize as an option; however this implementation is pretty complex and would require extensive testing.

Documentation also mentions the ability to resize image on client side before upload, however this would require new properties to awImgGetPict to fine tune the size you expect for each object of that class.

Both can be an evolution project.

Bonjour Thierry i am also very interesting with the ability of resize image on client side..

Amicalement Gilles

Well ...
Question can be innocent: why not do an ftp transfer of the file ?

Because AJAX supports the http protocol only, not ftp, and you’d need to install a ftp server, another deployment pain.

OK Thierry, it's really necessary for us to be able to file PDFs greater than 16 MB.
At first, is it possible to set up a size test to avoid the download error ?
Have a nice week end
Vincent

What do you think about https://github.com/blueimp/jQuery-File-Upload ?

Is it a good track ?

FoxinCloud already uses this library; please see my earlier post.

Oops, sorry ...

Can adaptation be considered and can we exceed 16 MB ?

This evolution is complex, I don't know yet how long it'll take -- more than a day for sure.

More than 16 MB: as the code of wwRequest:GetMultipartFile() uses variables, impossible with VFP/wConnect. It requires another Ajax request server-side handler written in another language without limitation on variable size.

this solution is worth testing (using this callback)