Please visit our new home community.embarcadero.com.
By: Christine Ellis
Abstract: C++Builder ActiveX Live Chat Transcript from Nov. 17th, 1999
This is a question asked by a chat participant
This is an answer or message posted by a speaker
This is another question asked by a chat participant
This is another answer or message posted by a speaker
This is an editorial comment
Please note: Some of the text for this chat has been edited for clarity.
Welcome to today's moderated chat on ActiveX!
Your moderator for today's event is Christine Ellis of Developer Relations.
The speaker(s) present at today's Delphi chat are:
Robert West - Delphi/C++ ActiveX
John (JT) Thomas - Developer Relations
Before we start with the chat, our lawyers ask us to post the following message: "Forward-looking statements, if any, made during this online discussion, including, but not limited to those concerning Inprise's future financial performance, product availability dates, and the potential features of or benefits to be derived from the company's products, will involve a number of uncertainties and risks, and actual events or results may differ materially. "Factors that could cause actual events or results to differ materially include, among others, the following: difficulties in integrating the operations and technology of Visigenic Software or other companies or technologies which the company may acquire, possible disruptive effects of organizational or personnel changes, shifts in customer demand, market acceptance of the companys new or enhanced products, delays in scheduled product availability dates, actions or announcements by competitors, software errors, general business conditions, and market growth rates in the client/server and Internet software markets, and other factors described in the companys S.E.C. reports on forms 10-K, 10-Q, 8-K, and the Inprise. . ."
This auditorium is currently quiet. Chat has been disabled to keep the noise down. You will not be able to see other users also logged into this auditorium. To ask a question, use /ask and type in your question.
Why would a C++Builder developer use ActiveX when there are other component solutions available? Are there any unique advantages to ActiveX?
That's a good question, and it can be answered in one of two ways. If the question is 'why is COM better than CORBA', I'm not going to get into it ... if the question is 'what are the advantages of ActiveX', it's pretty straightforward: ActiveX provides a set of interfaces that allow visual objects to be hosted within other applications. That is, it's relatively easy to do remote procedure calls with CORBA, but only ActiveX gives you a pre-defined mechanism whereby container applications and controls can communicate in such a fashion that it appears seamless to the end user.
Consider the stereotypical case of a word document displayed in a web browser: it appears more or less like it's one application. That's where the power is.
How would you compare the COM related wizards in BCB to the ones in VC++ and COM development in general on BCB/VC ?
It depends on what you are doing, of course. The VC wizards are better at hiding the complexity from you; just a set of pre-selected options, pick some properties, and run. But that's a double-edged sword, too.
The primary benefits, I think, of the BCB implementation come in two areas: (1) visual type library design (instead of having to generate your type library with IDL); and (2) the immediate ability to convert any component, anywhere, into an activex control. That's a tremendous advantage --- the same class you were using in your application already, converted into an activex control at the drop of a hat.
Can we expect ALT3.0 in the next version of Builder?
Is there no way that visual containment can be done in CORBA as in ActiveX?
It's doable. I'm not a CORBA expert (there's a certain amount that it's impossible to avoid knowing about it when you work with COM, but otehrwise I try to avoid it; COM is enough for one person to handle) ...but I digress. It's doable. But there's no predefined support that is guaranteed to work across all systems ... that is to say, OLE defines certain interfaces that most modern applications support (on the container side), so you know if you are writing a control that supports the control-side interfaces that you are more or less guaranteed to get the support you want from the applications you expect to host you. While CORBA is more successful as a cross-platform data-remoting standard, it doesn't have a standardized mechanism for visual containment ... so you could write your own control and container architecture using interfaces you defined, and it would work beautifully, but it wouldn't extend to other applications.
You say "the BCB implementation" -- Does that mean of ActiveX or the VCL?
ActiveX. But part of the BCB implementation of ActiveX is the glue that puts it and the VCL together --- so, because of the VCL, and the glue that we put in to bind it to the ATL, you can easily generate AX controls and AX forms around the VCL controls.
Can you give us a hint of what new COM/COM features we can expect in the next version of Builder?
I can tell you some of the things I've been working on.
I've spent a considerable amount of time with the MIDAS 2->MIDAS 3 changeover, and with providing the archictectural support needed for COM+. The thing I'm happiest about is the ability to implement random interfaces using a wizard.
I don't want to go into too much detail at this time, however.
What areas of COM development in BCB do you think need beefing up?
That's an awfully broad question, isn't it?
I should preface this by saying that the fact that I think something needs beefing up does NOT necessarily mean that it will be beefed up in version 5. It simply means that I'm looking in that direction.
I really think we need to be able to create servers that don't require the VCL. We're almost there, and I'm deliberately not adding code that would make that harder, but there are still some hurdles.
I would like our container support to be better. There are a number of optional container interfaces that we don't implement, and certain boneheaded controls don't bother asking before assuming that we implement them; this means that when you import those controls, they don't behave correctly.
I want our IDL generation to be beefed up. I'd love it if we had a standalone type library editor (although this is more difficult than it seems to be, even at the sixteenth glance).
I want to turn the question around. What do YOU think needs to be beefed up?
How long (approx) will we have to wait for the next Builder? Will it still lag behind Delphi5?
I cannot commit to any release dates but since Delphi 5 has shipped, it will obviously be lagging behind it.
Will ActiveX be implemented in Kylix? I've heard that there are some attempts to port ActiveX to Linux. Could be interesting for cross platform...
I can't answer that question.
What I can tell you is that there are several DCOM ports to Linux that seem reasonably stable. Most of them are only partially implemented, so I'd be concerned about the possibility that expectations might be wrong --- things that work fine under NT might not work at all under the DCOM ports.
Do you think implementing AX support is important for Kylix? Whether or not we do it is going to depend heavily on whether or not there is demand for it.
BCB4 only generates code from the main interface in your type libraries. A project of a reasonable size will have many interfaces. Will BCB5 generate code for all interfaces?
'Only generates code from the main interface'. You mean, we only generate wrappers for the default interface,and we just give you the interface definition for the other ones?
I haven't added code to make it generate more wrappers: in many cases we already generate _too much_ code (have you tried importing excel 8 on your machine?).
This isn't too difficult to work around, though. If you're going through a vtable interface, shoving your interface in a TComInterface template wrapper is pretty easy.
The place where we really fall down on this are disp interfaces that aren't default on any coclass. That's harder to do by hand. I can look into ways of broadening that (maybe a tlibimp option?), but I don't want to make any promises.
The ActiveX support is great, but what about building document servers? Y'know: inplace activation and all that stuff? Currently, my options seem to be either to use MFC (shudder) or write all the interfaces myself.
TOleContainer and TOleControl provide implementation of some of the stuff you need (IOleInPlaceActivation among them); you should be able to just rip that code out and use it. Otherwise ...
I'm skeptical about putting time and energy into wizard support for document servers. I think it's better to spend the time and energy into COM+ support.
I meant lagging behind Delphi 5 in terms of features/functionality?
Oh, I get it now . Well, I contend that Builder has an equivalent amount of features and in most cases more functionality. In many ways the ATL gives you more functionality (at least more control) but at the expense of ease of use.
If you asking will we ever use DAX in Builder, I can safely say, "No". We are committed to using the ATL.
A lot of people ask me about dispinterface event sinking in BCB. D5 already has the TOleServer class for this, will BCB 5 have something for this, too?
Hi Binh. :)
We looked at trying to provide the same functionality using C++ style template classes; there were problems involved in the way templates and the component palette and the VCL interacted. It wasn't our first choice, but eventually we decided to use TOleServer in BCB, as well.
Pardon my ignorance, but what is DAX?
DAX - Delphi ActiveX. It is built into the Delphi language which allows for simpler syntax and more hiding of the complexities of COM.
Do the VC++ wizards handle connection points better than BCB does ?
I assume you're talking about client-side connection point handling?
VC6 vs BCB4? Definitely.
VC6 vs. BCB4 UPD1? Questionable. Bruneau added significant server-side event support in that release; it's just neither flashy nor documented, buried down in the generated source code.
VC6 vs BCB5? definitely not. As I said in my answer to Binh, we get TOleServer: You can import your server, get a component for it, put it on the palette, and then you have automagic event support via the object inspector (the standard VCL event mechanism).
ActiveX support for Kylix could be useful for cross platform with Windows if it was solid and done to a robust level.
There's no question; it would be useful. But how useful, to how many people, and where do our resources belong?
I'm not saying we won't do it; I really haven't investigated how expensive it would be, as my attention is on BCB5. I just want you to know that there's a cost-benefit analysis that will have to be done, and until it's done, we won't be making any decisions. :)
Are there any plans for Builder specific COM articles on the community site?
Yes. As Developer Support generates content (TI's and FAQ's) about COM and Builder they will be routed to that street. Eventually, we will allow the community to submit articles as well. If you have something you would like to publish in this area, you can contact me for the time being. Or, if you have a specific topic you would like to see addressed you can contact me on that as well at firstname.lastname@example.org.
On what COM support needs beefing up -> How about more ATL related wizards so that we, too, can take more advantage from ATL like the VC guys ?
I'd originally wanted to drop stock property support into BCB5; it got dropped because I decided that sleeping once in a while would be a good thing. I also considered adding support for OLEDB providers using the ATL, and got halfway through implementing IMDB support before MS removed IMDB from win2k. (*sigh*)
Which ATL features in particular would you like us to support that we aren't currently?
Is there any likelihood of seeing a Visual Studio-like bundle of the Holy Trinity (Delphi, BCB, and JB) of Borland compilers?
This is a forward looking question that can only be answered by our Marketing team. I believe a Marketing chat will happen in the near future. That will be the appropriate place for this question.
It would be nice with a property with parameters like HRESULT _stdcall FieldByIndex([in] short Index, [out, retval] IField ** Value ); to get an indexed __property line generated.
That would be nice. It's a more complicated technical problem than you would think, however.
If you're typing this in the text page of the TLE, then I imagine we can do it; otherwise, you're hosed, because we can't simply assume that a double-indirection final parameter represents a property.
What you _really_ want is what Delphi gives you: a wrapper that checks the HRESULT and throws on failure, and converts the logical return value of the method call into a real return value. That's easy in Delphi because it's built into the compiler; we would have to provide a wrapper class for that in C++Builder.
Excellent on TOleSever in BCB5! I have another question: Since you guys seem to bring the Delphi stuff into Builder, sometimes things that are defined in the Delphi units produce conflicts when you include the raw SDK .H files. For instance, if IFoo is in ActiveX.pas (ActiveX.hpp) and its also defined in an SDK .H file, its a bit difficult to include the SDK .H file into your project and use it (because the SDK .H files usually are not namspaced). Any comments?
There are compiler directives you can use to ask the Delphi compiler, when it generates HPP files, to not output particular references. There are other directives you can use to ask it to output strings.
So, usually, when I encounter these, I go into the .pas file, tell it not to emit the type declaration, and then tell it to output an include for the relevant header.
This is only a partial solution, as sometimes the Delphi unit will behave badly if you do that; in those cases, there's nothing really that can be done. But usually, if we know about them, we can work around them.
If there are particular conflicts that you are aware of, please submit bug reports, or send me mail. We want as many of these as possible to work. :)
ATL features like MMC snap-ins and things like, I guess, what VC calls Lite HTML control might be good additions.
I don't know anything about the lite HTML controls, but as for MMC snapins: I'd like to do that. It would probably take close to a month's worth of work to do it right, though.
I was always under the impression that Delphi and C++Builder shared the same back-end compiler, but your comment about needing to provide a wrapper class in C++Builder for a Delphi compiler feature seems to indicate otherwise. Which is it?
They share the same _backend_ compiler. But the _frontend_ compiler is different.
[Terminology check: the 'frontend' takes code in the given language and compiles it to an intermediary code, usually called p-code. The 'backend' takes the p-code and converts it to machine code or asm code depending on the context in which it was invoked].
Delphi's native COM support is at the level of the frontend. C++Builder's frontend knows nothing about COM --- and won't; the compiler team is reluctant to add new features not required by ISO, and will only do so if it's essential for the functioning of the product.
I have a suggestion. In BCB5, I think it would help a lot if you added the Delphi-style safecall (automatic HRESULT) checking for COM clients and throw a native exception. This will reduce a lot of that manual HRESULT checking and will make programming easier.
This would have to be provided by (yet another) wrapper class.
It's definitely a good idea. But I'm not certain how it would fit into the existing framework, and I don't want to completely renovate the framework again; some sort of consistency between versions is necessary.
It's definitely an option. But it requires more thought, and I don't want to just jump into it blindly.
I am using BCB4 trial version and the TLB editor seems to have a small bug. The tool bar buttons on it sometimes disappear when I resize it -- especially if text labels are on.
Please submit bug reports to our developer support department at
We will no longer be accepting new questions for the speaker(s). We will continue to answer the questions that have already been accepted.
As the compiler is so ANSI compliant, how hard is it for you to get things like ATL to compile?
The ATL isn't ANSI-compliant;
it does ... unfriendly ... things like declare GUIDS via declspec(__selectany); it doesn't use the correct scoping of for-loop specifiers, etc.
There's a document up on the web that explains the changes we made to ATL 2.1 to get it to work in BCB4. The changes to ATL 3 were simpler, for the most part (now that we support the new language "extensions" it depends on), with one small caveat: it attempts to declare all sorts of static data, including pointers, inside of headers. The compiler allows this, but the precompiled header mechanism doesn't (for good reason; the chances that gives you to shoot yourself in the foot are tremendous). So I had to break all of these declarations out and put them in a library, which took about a day and a half.
When we ship, I'll post a list of the changes I had to make, and when VC7 comes out, I'll post an explanation of how to get ATL4 working, as well (if we can do it; I haven't seen ATL4 yet).
Please tell us ( if possible in months ) how long to wait for BCB5?
It will ship when it is ready. I cannot really say how many months that will be as it depends on the quality of the product. I understand how frustrating it is not knowing (and how anxious you must be) but be assured that you will be very happy with the quality and features in our next release.
Thank you for joining us today!
The next live moderated chat on the C++Builder compiler is currently scheduled for December 8th at 10 am Pacific Time (1800 GMT).
Hope to see you then!
Could not retrieve comments. Please try again later.
Free 30-day trial! Develop for Windows, Mac, Android, iOS, devices and gadgets!
More social media choices:
C++Builder on Google+
@RADtools on Twitter
Server Response from: ETNASC02