🚀 go-pugleaf

"Colin B Maharaj" <noreply@myhost.com> wrote in message
news:441C0EC1.7010901@myhost.com...

> I got errors where the compiler included winsock.h and winsock2.h.
> will it be ok for me to edit windows.h and replace winsock with
> winsock2. ( I did this already and it looks ok so far).

> Of course I have winshoes all over the place. This is not really a
> problem per say I can handle it, but is there a viable solution or
> workaround for the deprecated function TWinshoeSocket.Readable;

WinShoes is the (long outdated) predecessor to Indy.  You should consider
switching to Indy, which is much more feature-rich over WinShoes.  WinShoes
is only good to use for BCB versions that Indy does not support (BCB 4 and
earlier).

> I get lots of errors concerning Trim ambiguity with AnsiStrings and
> WideStrings

That is because Trim() (and other string-related functions) finally received
overloaded versions for WideString in BCB6.  The only time you should be
receiving an ambiquity is if you are passing in a char* or wchar_t* string
to Trim(), since both AnsiString and WideString have constructors that
accept those types of string values.  To remove the ambiquity, you should
either:

1) don't pass char/wchar_t* strings to Trim() (and other functions with
AnsiString/WideString overloads).  Assign the string to an
AnsiString/WideString variable first, so that the compiler can know which
version of Trim() to call

2) if you are only working with Ansi strings, then assign the char* to an
AnsiString variable and then use the AnsiString::Trim() method instead of
the global Trim() function

> File functions ambiguity with int and __int64.

Similar to the Trim() issue above, many int-related functions (IntToStr(),
etc) now have overloaded versions for __int64.  You have to assign your
numeric values to an int or __int64 variable so that compiler knows which
one to call.

> Can I typecast my "direct" strings as AnsiString?

Yes, although it would technically be constructing a temporary AnsiString
object, not typecasting the string to act like an AnsiString.  For example:

    AnsiString s = Trim(AnsiString(mystring));

Or:

    AnsiString s = AnsiString(mystring).Trim();

> and typecast my value like 5 to (int)5  ?

Yes, you can do that.

Alternatively, you can use the 'i32' suffix instead, which tells the
compiler that the value must be treated as a 32-bit signed int value:

    AnsiString s = IntToStr(5i32);


Gambit