DecodeBase64 gives empty string

Targets Windows
1

Hello,

I have this code… Windows 10

  Dim MyFile as FolderItem = ...  // the location  has been defined
  Dim S as string
  Dim TIS As TextInputStream

  If MyFile <> nil and MyFile.isReadable then TIS = TextInputStream.Open(MyFile)
  S = TIS.ReadAll
  TIS = nil
  
  S = Decodebase64(S)   // The data was encoded like this EncodeBase64(TheText, 0)
  EditField3.Text = S

The encoded string is not empty still I am getting an empty string returned.

What am I doing wrong or how can I fix that?

Thanks

Lennox

2

Have you checked S does contain something after TIS.ReadAll ?

Maybe you want to place a break before you nil TIS and check it’s value in the debugger.

If it is OK, you may save a line of code, doing :

[code]S = Decodebase64(TIS.ReadAll) // The data was encoded like this EncodeBase64(TheText, 0)

EditField3.Text = S

TIS.Close
[/code]

Also, I don’t know why you make TIS = nil. It should simply be closed.

3

BTW, if MyFile is NOT readable, your app will crash.

4

Thanks Michel,

Yes S does contain text, encoded text.

But still the decoded text is not being displayed…

Further on, I have

Dim f as folderitem
f = GetFolderitem(S)
If f <> nil and f.isReadable then f.launch

… and f is launched!

I can’t figure that out,.

The real problem is this…
I have a a launcher app.
It has several imageWells that have the icons of folder items that were dropped on to the imageWells.
On dropping a folderitem on an imageWell the icon of the folder item is displayed in the imageWell.

A shellpath is stored for that folder item so that when the imageWell is clicked the folder item is launched.
The app works well on a Windows 32 bit OS.

When I put the folder that has those shell paths in a Windows 64 bit OS the problem arises…
A Windows 64 bit OS has Program Files and Program Files (x86)

The shellpaths are indicating Program Files and not Program Files (x86)

So I would like to change the logic to

Pseudocode - isWOW is a method that indicates if the OS is 64 Bit
If isWOW then change those shellpaths from Program Files to Program Files (x86)

So that is why I need to be able to see S

Lennox

5

Thanks Kem,

MyFile is readable and I can manually open it and see the encoded text.

I also have
S = TIS.ReadAll
EditField2.Text = S
TIS = nil

and the encoded text is displayed in Editfield2

Lennox

6

If indeed S contains encoded text, then the only two lines where the issue can lie are :

S = Decodebase64(S) // The data was encoded like this EncodeBase64(TheText, 0) EditField3.Text = S

You want to place a break after the first line and check in the debugger if now it contains decoded text.

If it does and somehow line 2 does not places the text in EditField3, then your code is haunted.

Seriously, all other considerations are of the same nature as the proverbial red herring.

I very much doubt S contains anything at the entry of these two lines. I tried with a small project here, and if indeed S contains encoded text, there is no way in this space time continuum what comes out of the first line can be empty.

7

Thanks Michel,

Yes I put a break at the second line and yes there is text in the debugger
S then some garbled characters then the expected decoded text.

OK, I think the problem would be like this…

I use Mac and sometimes I transfer files from my PC to my Mac, I don’t know if those characters are being added in the transfer.

I will check that and see.

Thanks for pointing that out to me.

Lennox

8

[quote=220906:@Lennox Jacob]Yes I put a break at the second line and yes there is text in the debugger
S then some garbled characters then the expected decoded text.

OK, I think the problem would be like this…

I use Mac and sometimes I transfer files from my PC to my Mac, I don’t know if those characters are being added in the transfer.

I will check that and see.[/quote]

Forgive me, but I do not follow. If indeed S contains the expected text after the first line, that would mean somehow EditField3.Text does not display whatever you set it with.

I frankly do not see what transferring to a Mac would have to do with that…

9

Tiny possibility… very long shot…if the file comes over via FTP and its not set to binary mode, maybe windows line ends are being turned into Unix line endings and screwing it up?

10

Thanks,

OK I just re-created the files on my PC and the same thing happens…

In the debugger there are these garbled characters - 5 of them and some spaces - then the expected text appears but TextField3 does not display any text. The files does not go over FTP.

Lennox

11

That could happen, but Lennox says :

[quote=220906:@Lennox Jacob]Yes I put a break at the second line and yes there is text in the debugger
S then some garbled characters then the expected decoded text.[/quote]

If I understand right what he writes, S does contain the decoded text just before he sets EditField3.Text with it.

If S contains the desired text, try this :

MsgBox S

EditField3 may simply be corrupted somehow.

12

what does the line that SAVES the text to the file in the first place look like?

The data was encoded like this EncodeBase64(TheText, 0)

Is there any chance that before the textstream.write TheText happens , you have written something else to the file?

if one of the garbled characters after the S is a character zero, that might account for the textfield not displaying it

13

OK I tried this

EditField3.Text = “C:” + NthField(S, “C:”, 2) and now the expected shell path is displayed.

I do not know where those prepended garbled text come from.

Lennox

14

None of this makes any sense…

Giving up. When all logic is gone, only an exorcist can do anything…

15

OK I got a temporary work around using nthFields, so I can now do some detailed checks to correct the garbled text that was included and have it working the correct way.

Thanks Michel
If indeed S contains encoded text, then the only two lines where the issue can lie are :
S = Decodebase64(S) // The data was encoded like this EncodeBase64(TheText, 0)
EditField3.Text = S
You want to place a break after the first line and check in the debugger if now it contains decoded text.
…was the most helpful part.

Thanks to all that participated.

Lennox

16

Unless there are stray (garbled) characters in S before you decode it, then those extra characters are part of your encoded string, which means they were in the string before you encoded it and wrote it to the file in the first place.

Can you post the encoded string?

Oh, and bad characters in a string CAN cause it not to display. No real mystery there.

17

OK Thanks all,

The problem was this… To save the path I used this
TOS.writeline encodeBase64(f.GetSaveInfo (f, 2))
Then I encoded it and that was the problem…
The LR states - NOTE: The returned string is not intended to be human-readable and any modifications may render it useless.

I now use this
TOS.writeline encodeBase64(f.NativePath, 0) ’ TOS.writeline encodeBase64(f.GetSaveInfo (f, 2)) ’
encode it, and all works great.

Thanks again.

Lennox