It looks like for some reason RDTabs cannot store a password correctly if I use special characters in it.
In particular I am using, besides normal letters and numbers, the euro (€) and dollar ($) sign.
The symptoms are that I save it in my favorites, try to logon, and get authentication failed.
After the authentication failed message I get a prompt to enter the password manually which works fine.
Obviously I triple checked for typo's.
using a different account and password works just fine for the system i am logging on to so the problem cannot be there either.
Is that a bug or a known limitation ?

I know dollar signs work as I use them regularly (among the other USA keyboard top-row symbols). It's possible that with things like the euro symbol, there may be some sort of text conversion problem. For entering passwords, they are normal textboxes, encoded in (I think) UTF-8. If the RDP control is expecting a different encoding for those symbols, that could certainly be causing issues. The problem is that there is really no way to get the password string out of a successful session to compare it to what RD Tabs is storing to see if they are byte-different. I'll have to do some research.

Well, I just tried passwords with a slew of special characters and they work fine when entered initially, but then fail after being stored as a favorite (I think that's what you were saying, but I interpreted it as never working, for some reason). I get the feeling it might be my password encryption algorithm that's actually failing. I'll need to look at it and see where it is failing with the encoding.

This one was easy (thankfully). It turns out I was using ASCII encoding for the conversion from string to byte array before feeding the byte stream to the encryption algorithm. I changed that to UTF-8 and now the entire unicode character set is available to you. The next version of RD Tabs will include this as a bug fix.

EDIT: I should mention that all currently stored passwords will be backwards compatible as long as nobody was using any of the ASCII characters in the 8-bit character space, which is probably pretty unlikely.

great support, thanks for the fast response Thimothy.