HttpUpload_AddFileField first file is ok, the rest of the files are corrupted

Questions, comments and suggestions concerning VintaSoft Twain ActiveX.

Moderator: Alex

Post Reply
alexei
Posts: 15
Joined: Thu Jun 09, 2016 9:04 pm

HttpUpload_AddFileField first file is ok, the rest of the files are corrupted

Post by alexei » Thu Jul 14, 2016 12:51 am

Hi Alex,

I'm uploading the scanned images as PDF through the HttpUpload_AddFileField and what I noticed is that when I check the files in the database only the first file is recognized as PDF and the rest are corrupted. Because there is no functionality yet to upload all the images as one PDF multipage file in the VintaSoft twain driver( pending to be provided) I used the ITextSharp to merge the PDF files into one PDF file when I get the HTTP response ( or request). It gives me an error that the header could not be found, so I changed the code to store each file individually into the database table so I can check if I can open all of them, and only the first file opens correctly and I can see the scanned image, but the rest does not open, it gives me an error :
"Adobe Acrobat Reader DC could not open [filename] because it is either not a supported file type or because the file has been damaged".

If I do a select statement on the database (SQL Server 2008) and just by viewing the binary column I see for the first file the text representation of the binary file 0x255.........(PDF) the rest I see the 0x00000......
furthermore, before saving a file to the database I do a compare to see if I'm not saving an empty binary, all files are stored in the database. all saved files gives me a 380 KB size, including the first one that I can open, so this means that the rest of the files have data.

The code I'm using to upload the scanned images is the following and the imageFormat variable is = 'PDF':

Code: Select all


function UploadToHttpServer() {
    if (VSActiveX4Scan.Error) {
    } else {   
        if (VSActiveX4Scan.HttpUpload_SetServerParams('" + PostImageUrl + "',''," + Site.ActiveXConnectionTimeout + ") == 0) { 
           alert(""Image could not be transferred to server: "" + VSActiveX4Scan.ErrorString);
        } 
        else {
            var addResult =  false;
            //var imageFileName = '" + GUID + ".' + ImageFormat;
            for (var i = 0; i < VSActiveX4Scan.AcquiredImages_Count; i++){
                if(!VSActiveX4Scan.AcquiredImages_IsBlank(i, 0.01, 0)) { 
                    if (VSActiveX4Scan.AcquiredImages_Despeckle(i, " + Site.SmallNoise + ", " + Site.MediumNoise + ", " + Site.Radius + ", " + Site.BorderNoise + ") == 0) {
                        //error
                    }

                    if (VSActiveX4Scan.AcquiredImages_Deskew(i, " + Site.BorderColor + ", " + Site.ScanIntervalX + "," + Site.ScanIntervalY + ") == 0) {
                        //error
                    }

                    if (VSActiveX4Scan.AcquiredImages_DetectBorder(i, " + Site.BorderSize + ") == 0) {
                        document.getElementById('" + "').innerHTML += VSActiveX4Scan.errorString;
                    }
                    //each scanned image will be send to the server separately
                    var imageFileName = 'Image' + i + '.' + ImageFormat;
                    if (VSActiveX4Scan.HttpUpload_AddFileField('file', imageFileName, i) == 0) { 
                       alert(""Image"" + (i + 1) + ""cannot be uploaded: "" + VSActiveX4Scan.ErrorString);    
                    }
                    else {
                        addResult = true;
                    } 
                    if (!addResult) {
                        alert(""No images to upload."");
                        return;
                    }
                }
            }
            if (VSActiveX4Scan.HttpUpload_PostData() == 0) {
                    alert(VSActiveX4Scan.ErrorString);
                    return;
            }
            setTimeout('UploadStatus()',10);
        }
    }
}

function UploadStatus() {
    var statString = VSActiveX4Scan.HttpUpload_StateString
    if (VSActiveX4Scan.HttpUpload_State == 4)
        statString = statString + ' Uploaded ' + String(VSActiveX4Scan.HttpUpload_BytesUploaded) + ' bytes from ' + String(VSActiveX4Scan.HttpUpload_BytesTotal) + ' bytes.';
    if ((VSActiveX4Scan.HttpUpload_State == 6) ||  // Aborting
        (VSActiveX4Scan.HttpUpload_Status == 5) || // Completed
        (VSActiveX4Scan.HttpUpload_Status == 0) || // None  
        (VSActiveX4Scan.HttpUpload_ErrorCode != 0)) {
        if (VSActiveX4Scan.HttpUpload_ErrorCode == 0) {
            if (VSActiveX4Scan.HttpUpload_ResponseCode == 200) {
             // succesfull upload, no need to notify.
            }
            else {
                  alert(""Response code: "" + VSActiveX4Scan.HttpUpload_ResponseCode);
                  alert(""Response string: "" + VSActiveX4Scan.HttpUpload_ResponseString);
            }
            VSActiveX4Scan.HttpUpload_ClearAllFileFields();
            if (VSActiveX4Scan.Device_State == 0) {
                CloseDeviceAndManager();
            }
            uploadEnded = true;
        } else {
            //error 
            alert(""Error: "" + VSActiveX4Scan.HttpUpload_ErrorString); 
        }
    }
    else
        setTimeout(""UploadStatus()"",1);
}

Can you let me know what can be causing this issue?

Thanks in advance

Alex
Site Admin
Posts: 1445
Joined: Thu Jul 10, 2008 2:21 pm

Re: HttpUpload_AddFileField first file is ok, the rest of the files are corrupted

Post by Alex » Thu Jul 14, 2016 2:23 pm

Hi Alexei,

We have uploaded several PDF documents in one HTTP session and have not found any problem. I think you have problem on a server-side when you saving file streams into database. Please check your code.

Best regards, Alexander

alexei
Posts: 15
Joined: Thu Jun 09, 2016 9:04 pm

Re: HttpUpload_AddFileField first file is ok, the rest of the files are corrupted

Post by alexei » Thu Jul 14, 2016 7:01 pm

HI Alex,

I found what was the issue, when sending each image through the HttpUpload_AddFileField you need to provide the fieldname with a unique name for each file, otherwise only the first file will be a pdf file, and the rest will be corrupted. I don't know if this has to do with the OutSystems platform, but there is a function (GetRequestFiles) that you can call in the page load (Preparation ) of the page that will get the files from the HTTPRequest and returns you a Record List ( DatasSet).

In my code I did the following at the section where you will provide each image to the HTTPUpload function:

Code: Select all

  if (VSActiveX4Scan.HttpUpload_AddFileField('Image' + i, imageFileName, i) == 0) { 
                       alert(""Image"" + (i + 1) + ""cannot be uploaded: "" + VSActiveX4Scan.ErrorString);    
                    }
After doing this all images are readable and then I used the ItextSharp to merge the PDF files into one PDF file.

**************************** Images are not being received through HTTPUpload with their original scanned size. ******************************************
Now I'm having another issue that the PDF's received are not of the same size (A4 Page), the PDF's are received without the borders ( white space around the pages ) furthermore, if you have only a part of the page with data, specifically hand written stuff, it only provide you with that part of the page, so the pages are not of the same size, even though I'm scanning only A4 Pages. I saved each received image prior the merging in order to know for sure that it is not the merging that is doing this and I can conclude that the pdf's are being received like that.

Alexander have you encounter such a similar case?

Regards,

Alexei

Alex
Site Admin
Posts: 1445
Joined: Thu Jul 10, 2008 2:21 pm

Re: HttpUpload_AddFileField first file is ok, the rest of the files are corrupted

Post by Alex » Fri Jul 15, 2016 10:09 am

Hi Alexei,
I found what was the issue, when sending each image through the HttpUpload_AddFileField you need to provide the fieldname with a unique name for each file, otherwise only the first file will be a pdf file, and the rest will be corrupted. I don't know if this has to do with the OutSystems platform, but there is a function (GetRequestFiles) that you can call in the page load (Preparation ) of the page that will get the files from the HTTPRequest and returns you a Record List ( DatasSet).
Several file fields may have the same name because this parameter is informative. I think your code has bug OR your development environment (the OutSystems platform) has bug or limitation.

Now I'm having another issue that the PDF's received are not of the same size (A4 Page), the PDF's are received without the borders ( white space around the pages ) furthermore, if you have only a part of the page with data, specifically hand written stuff, it only provide you with that part of the page, so the pages are not of the same size, even though I'm scanning only A4 Pages. I saved each received image prior the merging in order to know for sure that it is not the merging that is doing this and I can conclude that the pdf's are being received like that.
You are processing images before uploading to HTTP. The AcquiredImages_Deskew and AcquiredImages_DetectBorder methods can change the image size. Please debug your code and determine why you are receiving images with different size.

Best regards, Alexander

alexei
Posts: 15
Joined: Thu Jun 09, 2016 9:04 pm

Re: HttpUpload_AddFileField first file is ok, the rest of the files are corrupted

Post by alexei » Fri Jul 15, 2016 3:52 pm

Hi Alex,
Several file fields may have the same name because this parameter is informative. I think your code has bug OR your development environment (the OutSystems platform) has bug or limitation.
I will contact the OutSystems support about the issue with the field name, because what I'm doing I'm just calling in the preparation (page_load) of the page a core function created in OutSystems which retrieves the HTTP upload and stores it in a dataset, I only iterate through the dataset and stores the binary in a SQL server table.

About the deskew and Detect Border, I will comment out those operations and test it. in the previous 5.2 version we were using these operations, because only TIFF files could have been send, maybe now that the files are PDF, there is no need anymore. I will try it and keep you posted.

I really appreciate your assistance.

Regards,

Alexei

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest