🚀 go-pugleaf

An Update:  I tried run time creation of the previously mentioned code, a 
rebuild of Indy, and various other attempts, no joy.

However, the follwoing code does work.  So there isn't anything major wrong 
with the Indy build and the SysLog components, but must be something 
specifically wrong with the SendMessage methods.  Has anyone come across 
this before?

void __fastcall TForm1::Button1Click(TObject *Sender)
{
    TIdSysLog * c = new TIdSysLog(NULL);
    c->Host   = "127.0.0.1";
    c->ReceiveTimeout = 15000;
    c->Active = true;

    TIdSysLogMessage * t = new TIdSysLogMessage(NULL);
    t->Msg->Content = "Hi Server";
    t->Severity = slDebug;
    t->Facility = sfUserLevel;
    t->SendToHost("127.0.0.1");

    delete t;
    delete c;
}


"Paul" <plmacca@clara.co.uk> wrote in message 
news:4412d1f1$1@newsgroups.borland.com...
> Hi,
>
> I've built and included Indy9 (as far as I can tell).  I've made a couple 
> of small apps to test the build and components and I get the following 
> error with SysLog (Client) link:
>
> [Linker Error] Unresolved external '__fastcall 
> Idsyslog::TIdSysLog::SendMessageA(const Idsyslogmessage::TIdSysLogMessage 
> *, const bool)' referenced from D:\VSS\SYSLOGSERVER\CLIENTFORM.OBJ
> [Linker Error] Unresolved external '__fastcall 
> Idsyslog::TIdSysLog::SendMessageA(const System::AnsiString, const 
> Idsyslogmessage::TIdSyslogFacility, const 
> Idsyslogmessage::TIdSyslogSeverity)' referenced from 
> D:\VSS\SYSLOGSERVER\CLIENTFORM.OBJ
>
> Any ideas? (test code below).  I'm a bit confused why the method in the 
> header is "SendMessage", the linkers says SendMessageA, and it compiles 
> with either (and makes no difference to the linker error).
>
> Regards
>
> Paul

In the Help, the TIdSysLogMessage description has the following for 
SendToHost :

****
SendToHost is public procedure used to send the Syslog message to the host 
name or IP address indicated in Dest. SendToHost will create a temporary 
TIdUDPClient instance, when one has not already been assigned, to be used to 
for the transmission to the Syslog daemon in Dest. SendtoHost call 
TIdUDPClient.Send using Dest and IdPORT_syslog as the destintination for the 
contents of the message created using EncodeMessage.
****

What does "create a temporary TIdUDPClient instance, when one has not 
already been assigned" mean?  Did I achieve "assigning a TIdUDPClient 
instance" by doing the following in my code, even though there is no obvious 
link between these two?

Paul.

    TIdSysLog * c = new TIdSysLog(NULL);
    c->Host   = "127.0.0.1";
    c->ReceiveTimeout = 15000;
    c->Active = true;

    TIdSysLogMessage * t = new TIdSysLogMessage(NULL);
    t->Msg->Content = "Hi Server";
    t->Severity = slDebug;
    t->Facility = sfUserLevel;
    t->SendToHost("127.0.0.1");

Paul wrote:

> but must be something 
>specifically wrong with the SendMessage methods.

Ii seems likely that there is a naming conflict with the Windows
SendMessage function, which has a #define to SendMessageA

I was thinking that since I have the source I might rename this function (or 
add an identical one) and see if I can get around it.  Although I would have 
thought that the namespace would have prevented this conflict?

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 
news:2ae71213clfue1q426pv3rrjl2hqedgf1i@4ax.com...
> Paul wrote:
>
>> but must be something
>>specifically wrong with the SendMessage methods.
>
> Ii seems likely that there is a naming conflict with the Windows
> SendMessage function, which has a #define to SendMessageA
>
> 

Hi,

I rebuilt the Indy9 project with the SysLog method renamed to SendLogMessage 
and I get no linker error, and it runs.  Noticed that version reports 
'DevSnapshot' in the server log, not '9.0.50' (I thought I had picked up a 
known stable version).

Anyway, I guess I can't keep the SendLogMessage change as it is, so I wonder 
what the correct fix is?  Although, I've just looked into the DevSnapShot 
for Indy10 and it now uses SendLogMessage, so maybe its ok for now.

I could go to Indy10, but with no batch files available from what I can see, 
I'm reluctant to spend time on it at the moment.

Paul


"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 
news:2ae71213clfue1q426pv3rrjl2hqedgf1i@4ax.com...
> Paul wrote:
>
> Ii seems likely that there is a naming conflict with the Windows
> SendMessage function, which has a #define to SendMessageA
> 

"Paul" <plmacca@clara.co.uk> wrote in message
news:4412d1f1$1@newsgroups.borland.com...

> I've made a couple of small apps to test the build and components
> and I get the following error with SysLog (Client) link:

You can thank Microsoft for that error.  There is a Win32 API function named
SendMessage().  Under C/C++, Microsoft uses precompiler #define statements
to declare many Win32 API functions, including SendMessage(), do deal with
Ansi vs Unicode parameters.  Such #define statements are global in nature,
do not repect namespaces, and do not differentiate between standalone
functions and class methods.  TIdSysLog has a method named SendMessage(), so
the C++ header file that is produced when Indy is compiled declares that
method as SendMessage(), as expected.  But then Microsoft's own headers
overwrite that declaration with SendMessageA() during compiling.  Since the
method is named as "SendMessage" in the Delphi code and as "SendMessageA" in
the C++ code, the linker can't find the "SendMessageA" method in the
Delphi-compiled binaries, hense the error.

This error effects many aspects of the VCL in general.  It is not specific
to Indy.  You can thank Borland for that, for writing theVCL in Delphi
Pascal to begin with, and for naming many of its own methods and functions
the same as Win32 API functions, hense suffering from the same #define
issue.

> Any ideas? (test code below).

There are 3 possible solutions:

1) re-write and re-compile IdSysLog.pas to not use "SendMessage" as its
method name, but do use something more unique so that its name is not
changed by the C/C++ precompiler.

2) change the winuser.h header file to not declare SendMessage() using
#define statements.  That was really stupid on Microsoft's part, since
SendMessage() does not use any strings in its parameters, and thus there was
no reason for Microsoft to make separate Ansi and Unicode flavors of
SendMessage() in the first place.

3) change IdSysLog.hpp to #undef SendMessage before TIdSysLog::SendMessage()
is declared.  This would have to be done each time Indy is recompiled, and
may have side-effects elsewhere in the project unless you re-#define
SendMessage after TIdSysLog::SendMessage() is declared.

> I'm a bit confused why the method in the header is "SendMessage", the
linkers says SendMessageA

See above.


Gambit

"Paul" <plmacca@clara.co.uk> wrote in message
news:4413126f@newsgroups.borland.com...

> What does "create a temporary TIdUDPClient instance, when one
> has not already been assigned" mean?

It means exactly what it says.  SendToHost() creates a TIdUDPClient object
internally if one has not been assigned to the TdSysLogMessage yet.  This
allows you to use just TIdSysLogMessage by itself without a separate
TIdSysLog object.

> Did I achieve "assigning a TIdUDPClient instance" by doing the
> following in my code

No.  TIdSysLog and TIdSysLogMessage do not link themselves to each other at
all.  And by calling SendToHost() directly, you do not need TIdSysLog at
all, unless you want more control over the connection, in which case you
should be passing the TIdSysLogMessage to TIdSysLog::SendMessage() instead
of calling TIdSysLogMessage::SendToHost().


Gambit

"Paul" <plmacca@clara.co.uk> wrote in message
news:4413e72a$1@newsgroups.borland.com...

> I was thinking that since I have the source I might rename this function
> (or add an identical one) and see if I can get around it.  Although I
would
> have thought that the namespace would have prevented this conflict?

#define statements do not respect namespaces.


Gambit

"Paul" <plmacca@clara.co.uk> wrote in message
news:441420e6$1@newsgroups.borland.com...

> Noticed that version reports 'DevSnapshot' in the server log, not '9.0.50'
> (I thought I had picked up a known stable version).

9.0.50 is the development snapshot.

> Anyway, I guess I can't keep the SendLogMessage change as it is

Why not?

> so I wonder what the correct fix is?

That is one of the possible fixes.

> I could go to Indy10, but with no batch files available from what
> I can see, I'm reluctant to spend time on it at the moment.

Indy 10 does not officially support C++ yet.  I am currently working on
that.


Gambit

Hi,

I have rebuilt it with the SendLogMessage (as per Indy 10 naming), and it 
seems fine so far.

In the back of my mind I'm sure I've had this same issue with SendMessage 
for something else in the past, but can't remember what it was.  Anyway 
thanks for your information.

Paul

> 1) re-write and re-compile IdSysLog.pas to not use "SendMessage" as its
> method name, but do use something more unique so that its name is not
> changed by the C/C++ precompiler.