Hi again Daniele!
Got it... Please MERGE the following three lines in to your current/adapted SendFileMQ SuperBasic program:
Code: Select all
2120 netBlk$=netPayload$(9 TO result%): blkLen%=LEN(netBlk$)
2170 PRINT #fCh%,netBlk$(fHdrLen%*fileHdrFlag% + 1 TO blkLen%);
2210 PRINT #fCh%,netBlk$;
I'll publish a revised, full version of SendFileMQ at the weekend that works under SuperBasic, but the above should get you receiving successfully again - let me know.
By way of explanation, under SBASIC, when extracting a slice from a string-array, the implicit end-index of the slice is, as you might expect, the current
LEN of the 1D string-array element - which will be less-than or equal to the DIM'd length.
When slicing a string-array under SuperBasic however, the implicit end-index defaults to the DIMensioned end of the string-array.
As the netBlk$ string-array in question here is DIM'd at 255 characters AND because (both) Super and SBASIC always round-up to the next even byte length when DIMming a new array, under SBASIC only the current LENgth of the latest network block is PRINTed out as we want in to the saved file. Under SuperBasic, all
256 bytes of the array (including the space that pads-out the last character of the DIM'd array) is PRINTed out to the file for each received block.
By capturing the current LENgth of netBlk$ (as blkLen%) and then explicitly specifying this as the end-index ( .. TO blkLen% ), we workaround SuperBasic's behaviour and get back to what we intended.
I'll have to take a look at Jan Jones' authoritative handbook to check, but I suspect this is designed behaviour in SuperBasic, but 'rationalised' in SBASIC to behave more intuitively...