If I wizard-build a trivial Automation server, with a simple method or
(even) no methods, and I try to compile it, it starts throwing const char*
to const wchar_t* conversion errors in utilcls.h, atlvcl.h and other core
includes. If I remove the UNICODE definition in the project conditionals, it
compiles OK. This is with NO manually generated code in the project.

Test case: Just start a new app, add an ActiveX automation object, make sure
the project defines UNICODE, save it, compile it. It fails to build. What???

This is running BCB4.00 EE Trial version OR BCB4 Pro release on two
different  NT Server machines, both of them with Delphi 4 installed.

Also a VCL control I've written will not port, it  keeps complaining about
the linker not finding wsprintfA, no matter whether I define UNICODE or not.
The Pascal code uses Strings, PChars, and calls wsprintf onto a PChar, and
compiles fine under D4. I wonder if this is related.

Can someone try the above trivial automation server test and tell me what
they see? Am I overlooking something obvious in how to set up BCB for COM?

Thanks,
Fernand

Robert West
borland.com QA.

This is getting me worried. I have had to manually revert to an older
4.0.5.106 VCL40.BPL since the latest 4.0.5.108 crashes my BCB4 Pro, and now
I'm wondering if any of the COM stuff works.

What do you recommend on this COM object stuff, I've got work to get done.
Not use UNICODE??? How can I get a fix ASAP, as troubleshooting the BCB4 ATL
source stuff is a little beyond me at the moment?

BTW, can you tell me how, in BCB4, one connects to a server's COM events
from the client side? Is there any documentation on that?

Note that all the utilcls-type functions call SysAllocString for string
allocation, so defining UNICODE should not be necessary.

If you naively build a service application and then drop a client
socket on the service container AND if you use SetPort then you get
"interesting" linker errors "TCustom..::SetPortA" not found.

The reason? Microsoft grab "SetPort" and #define it to "SetPortA".
Very kind. I have no idea whether these are related, but that may
perhaps give a clue where to look? OTOH, if it is OK in the OBJ (how
did you check? TDUMP?), then I am clueless.

Sorry, my knowledge about ATL-based COM is next to zero, so I am of
absolutely no help in that area.

--
Stefan Hoffmeister      http://www.econos.de/
Due to time constraints I cannot give free face-to-face advice.
Please do apply judgement when sending email.

Many of the Win32 calls obviously come in two flavors: A and W, ASCII and
WideString, not as a Microsoft "unkindness", but to let you either use
UNICODE or not. If I use wsprint in an ASCII build, not UNICODE, the call
should map to wsprintfA. You can see this in Borland's Windows.pas file.
Borland does this mapping, not Microsoft. That wsprintfA in turn should link
as an extern and resolve at runtime to an API call in User32. Right?

In BCB4 I see that my wsprintf has been mapped correctly to wsprintfA, in
myVCLsource.obj, if I use TDUMP. But it can't link. It's as if the wsprintfA
extern were not available to the linker, but I CAN use wsprintf (and
wsprintfA) allright in non-component code.

Something seems different in how a component (vs. an app) is linked. If I
replace wsprintf explicitly with wsprintfA in my source, or if I
undefine/undefine UNICODE, nothing changes.

Fernand

BTW, the same A vs. W split is true of SetPort, take a look, it's in the
WinSpool.pas file. It's a Win32 call in the default namespace, and maybe
that's the source of your service problem.

, please do not cross- or multi-post, as this is against the guidelines for these newsgroups (see http://www.borland.com/newsgroups/). Please choose the *single* most appropriate newsgroup for your message and post it there. Thank you.

That's just not right. It is BORLAND and not Microsoft that is "redefining"
here. SetPort had been a spooler Win32 API call since 1996, a pretty dumb
name, but it's been that way for about 3 years. In fact it was BORLAND that
both introduced the conflicting socket SetPort *and* imported the Win32
SetPort in Delphi 3, at least a year later.

That's why I think you're being a bit TApologist here, some people would
rather always see it the other way around, and this is how these anti-MS
rumors start. Please be fair.

As to why it only broke code in BCB4, I don't know.

Fernand

p.s. There is also a SetPort in java.net.

what is the linker error in question?

Hello...

I am also having a problem with BSTR and WideString in BCB4.
Using MapObjects ActiveX ver 1.2 from ESRI,  the code below is OK in compiling,
but error during linking:

      _DataConnectionDisp *dc;
      dc = new _DataConnectionDisp;
      dc->Database = (WideString("[arc]c:\\GisPangan\\Data").Detach());

Database is a field in _DataConnectionDisp object with "type" = BSTR and
"visibility" = public.

Thanks for the attention,

best regards,

Yuli S.

--
Stefan Hoffmeister (TeamB)     http://www.econos.de/
Please do apply judgement when sending email.

I put the code in :
    void __fastcall TForm1::FormCreate(TObject *Sender)
    {
      _DataConnectionDisp *dc;
      dc = new _DataConnectionDisp;
      dc->Database = (WideString("[arc]c:\\GisPangan\\Data").Detach());  // problem!

     }

if I compile the unit, it is OK. But when I try to run there is a dialog message
with the title:
            _ASSERTE,
and the question mark with message:
            IsBound()@
            PROGRA~1\BORLAND\CBUILD~1\INCLUDE\vcl/utilcls.h/2431
            Press [Y]es to terminate, [N]o to continue and [C]ancel to debug

Thanks again for the respond.

best regards,

Yuli S.

I put the code in :
    void __fastcall TForm1::FormCreate(TObject *Sender)
    {
      _DataConnectionDisp *dc;
      dc = new _DataConnectionDisp;
      dc->Database = (WideString("[arc]c:\\GisPangan\\Data").Detach());  // problem!

     }

if I compile the unit, it is OK. But when I try to run there is a dialog message
with the title:
            _ASSERTE,
and the question mark with message:
            IsBound()@
            PROGRA~1\BORLAND\CBUILD~1\INCLUDE\vcl/utilcls.h/2431
            Press [Y]es to terminate, [N]o to continue and [C]ancel to debug

Thanks again for the respond.

best regards,

Yuli S.