I have a normal FB STRING that has been loaded with the contents of a JPEG file. When I set a DWSTRING = FB STRING the resulting DWSTRING is only 4 bytes long. Some code below. I have verified that sFileContents does have the contents of the JPEG file.
DIM sImageStream AS DWSTRING
DIM sFileContents AS STRING
' Get File Size
uImageAttributes.ImageSize = oCFileSys.GetFileSize(szImageFile)
' Get Raw Stream
sFileContents = STRING(uImageAttributes.ImageSize, 0)
hFile = CreateFileW(@szImageFile, GENERIC_READ, FILE_SHARE_READ, NULL, _
OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, NULL)
ReadFile(hFile, STRPTR(sFileContents), uImageAttributes.ImageSize, @dwBytesRead, NULL)
CloseHandle(hFile)
' Save Image for reference
sImageStream = sFileContents
Never use DWSTRING or any other null-terminated string (WSTRING, ZSTRING) to store binary data. For that, use STRING or a buffer of bytes.
It does not make any sense to convert the contents of a JPEG file to Unicode.
It was my over zealous use of DWSTRING. I switched over to STRING and now another interesting issue has come up.
When I take a STRING that is already populated and then add my string with the jpeg file contents that seems to work. Then when I add CRLF, I lose the jpeg file contents. I think I'm hitting a chr(0) that is messing things up.
Using memcpy instead of adding strings together solved the chr(0) issue.
Here is the updated SUB.
Private SUB cPDF.BuildObject(BYREF sObject as STRING, BYVAL sObjectPart AS STRING)
DIM sCRLF AS STRING = CRLF
DIM nObjectSize AS LONG = LEN(sObjectPart)
DIM sNewObject AS STRING
If nObjectSize > 0 Then
sNewObject = SPACE(LEN(sObject) + nObjectSize + LEN(sCRLF))
If LEN(sObject) > 0 Then
memcpy(STRPTR(sNewObject), STRPTR(sObject), LEN(sObject))
memcpy(STRPTR(sNewObject) + LEN(sObject), STRPTR(sObjectPart), LEN(sObjectPart))
Else
memcpy(STRPTR(sNewObject), STRPTR(sObjectPart), LEN(sObjectPart))
End If
memcpy(STRPTR(sNewObject) + LEN(sNewObject) - LEN(sCRLF), STRPTR(sCRLF), LEN(sCRLF))
End If
sObject = sNewObject
End Sub