🚀 go-pugleaf

"Colin B Maharaj" <noreply@myhost.com> wrote in message
news:441b5f81@newsgroups.borland.com...

> The call back function has parameters, including a
> TMemoryStream pointer and TStringList pointer.

Those are VCL objects, which use the VCL memory manager internally.  In
order to share VCL objects between the DLL and the Application, and to
ensure that the same memory manager is being used for both, you should make
a Package instead of a DLL.  A Package is a special kind of DLL that has
built-in VCL support.

> You see the calling application that is opening the DLL, has a
> routine with command line parameters that must be called by
> the server DLL.
>
> But in doing so, it causes access violations.

Please show your actual code.

> I there anyway That I can create content in the called routine that
> exists in a BCB3 project but is being called in a BCB6 DLL??

What EXACTLY are you trying to accomplish to begin with?  Please provide
more details.


Gambit

Hi Remy,

Remy Lebeau (TeamB) wrote:
> 
> What EXACTLY are you trying to accomplish to begin with?  Please provide
> more details.
> 
> Gambit


To create a secure web server in BCB3.
BUT!!


After much a mental ado I am going to upgrade my project to BCB6. I just 
realized that I did not have to recreate all the forms just include 
them. (boy was I stupid). So it was easier than I thought.
Yes I actually thought I had to recreate all my forms (boy oh boy).

I have moved most of the components that I use in BCB3 to BCB6 with out 
a problem except for a tiny snag in the TZipBuilder which I was able to 
resolve easily.

Now the challenges..
1. 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).

2. 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;

3. I get lots of errors concerning Trim ambiguity with AnsiStrings and 
WideStrings; and File functions ambiguity with int and __int64. Can I 
typecast my "direct" strings as AnsiString? and typecast my value like 5
to (int)5  ?


Thanks for all your help in the past Remy. I will definitely need your 
(or anyone else) support moving from 3 to 6.

Any other glitches I should know about please let me know..

Thanks again!!

"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