Indy 9 and SysLog
Paul
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
***************
Test code inside button click is like this:
{
// tried this too: using Idsyslogmessage::TIdSysLogMessage;
// tried this too: using Idsyslog::TIdSysLog;
TIdSysLogMessage * msg = new TIdSysLogMessage(NULL);
msg->Msg->Content = "Hi the Server";
msg->Severity = slDebug;
msg->Facility = sfUserLevel;
IdSysLog1->Host = "127.0.0.1";
IdSysLog1->Active = true;
IdSysLog1->SendMessage( msg, true );
IdSysLog1->SendMessage("Hi",sfUserLevel,slDebug);
}
Paul
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" <plm...@clara.co.uk> wrote in message
news:4412d1f1$1...@newsgroups.borland.com...
Paul
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.
Bob Gonder
> 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
Paul
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" <no...@notmindspring.invalid> wrote in message
news:2ae71213clfue1q42...@4ax.com...
Paul
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" <no...@notmindspring.invalid> wrote in message
news:2ae71213clfue1q42...@4ax.com...
> Paul wrote:
>
Remy Lebeau (TeamB)
> 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
Remy Lebeau (TeamB)
> 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
Remy Lebeau (TeamB)
> 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
Remy Lebeau (TeamB)
> 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
Paul
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