I'm going to take a stab in the dark here and follow David Lock's lead and solicit feedback from all of you! I am responsible for quite a few more areas of Delphi and C++Builder than David since I've been with the company for over 12 years, but what I'm specifically looking for feedback about is our COM/ActiveX features. COM isn't going away anytime soon, in fact it is my belief that more of you are looking at COM when you are moving your applications to .NET. I want to know what your pain points are, what features you'd like to see, and what bugs are blocking you. Please respond to this post or email me at codegearalias@gmail.com with the word "blog" anywhere in the message (I've taken extra precautions as to avoid spam unlike David).
skip to main |
skip to sidebar
This is my blog about software development, mountain unicycling, Photography, and stuff I find interesting.
Search Site
Geographic Distribution Of the Site"s Readership
Recommended Reading List
These are books I've read and own, and think highly of, not some generically pre-populated list.
Monthly Archive
- November (1)
- November (1)
- March (1)
- December (1)
- November (4)
- August (2)
- July (3)
- May (1)
- April (2)
- February (1)
- January (2)
- December (3)
- November (2)
- September (1)
- August (1)
- July (4)
- June (3)
- May (2)
- April (1)
- July (1)
- June (2)
- March (1)
- January (1)
- September (1)
- August (5)
- June (1)
- April (5)
- March (4)
- January (3)
- December (3)
- November (1)
- October (1)
- August (1)
- July (3)
- June (1)
- April (2)
- March (2)
- January (4)
- December (3)
- November (1)
- October (1)
- August (1)
- July (3)
- June (6)
- May (2)
- April (3)
- March (3)
- February (1)
- January (1)
- December (16)
- November (7)
- October (14)
- September (8)
- October (1)
- May (1)
- September (1)
- July (1)
- June (2)
- May (1)
- April (1)
- March (3)
- February (3)
- December (2)
- November (5)
- October (1)
- September (5)
- August (4)
- July (2)
- June (3)
- April (7)
- March (5)
- February (1)
- January (1)
- December (3)
- November (5)
- October (2)
- August (3)
- June (9)
- May (2)
- April (1)
- March (2)
- February (8)
- January (4)
- December (5)
- November (4)
- October (8)
- September (6)
- August (9)
- June (2)
- May (6)
- April (4)
- March (2)
- February (4)
- January (11)
- December (3)
- November (7)
- October (2)
- September (8)
- August (1)
- July (16)
- June (3)
- May (6)
- April (7)
- March (6)
- February (3)
- January (11)
- December (10)
- November (18)
- October (7)
- September (5)
- August (26)
- July (24)
- June (19)
- May (15)
- April (7)
- March (15)
- February (14)
- January (15)
Whoa there you just hit bottom. You can find more stuff in the monthly archive.
All written material and photographs on this website are © 2007-2010 Chris Bensen or copyright their various creators. All rights reserved.
The views expressed in this blog are my own and do not necessarily reflect the views of Embarcadero Technologies.
The views expressed in this blog are my own and do not necessarily reflect the views of Embarcadero Technologies.
6 comments:
1)
Many third party COM or ActiveX controls that will work fine with Delphi 5 may not work correctly with Delphi2007. I have been told by another programmer these are
mainly controls that were compiled with Visual Basic. This is possibly the case.
What is perplexing is if I import the control with D2007 (it is an involved, convoluted process) and create a TLB; I can get the controls to work, kind of. I compile my code in D5 using the control and load the D5 project into D2007. The controls may appear on the project's form and work fine. That is, the TLB appears to be created correctly but the objects do not transpose to the Tool Palette for some of the ActiveX tools I tried to use. The control 'works' even though it appears impossible to get the controls into the Tool Palette on D2007. Once D5 code is converted to D2007, the program will run in D2007 but it is impossible to modify the code easily in Delph2007
because the tools are not recognized (that is do not appear on the palette) even though the type library is usable. Yuk.
2)
Steve Trefethen recently blogged about getting existing controls into a new package. His note helped with some things but not others. The steps there really did not work
correctly. His original steps were intended for building a control with Delphi. He indicated importing a control was similar, without going into detail. I think the following is what he intended (the commented out lines (//) are my 'deletions.') but there still appear to be some missing steps.
1. Start the IDE
2. Select File|New|Package
3. Select File|Save As and give your package the desired name
// 4. Select View|Project Manager
// 5. Right click the package node and select Options then be sure to fill in the
//Description for this package as it will be used in the Install Packages dialog
// 6. Select Component|New VCL Component... which will display the New VCL Component
//Wizard (see note below)
// 7. Select TButton as the ancestor and click Next
// 8. Leave the defaults for Classname etc. and click Next
9. Select "Add unit to Package1.bdsproj project"
10. Select View|Project Manager and right click Package1 and select Install
Prior to step 10, I think one should rename Package1.bdsproj? I think so.
The procedure steps do not appear to work when installing an ActiveX/COM control to the Tool Palette all the time. Also, it appears to have some steps missing As indicated above, it is possible that ActiveX controls created in VB won't install correctly, at least some of them. Is this correct?
3)
Hopefully an explaination of how to get COM and ActiveX controls to the tool palette is being included in the latest Help files. Transitioning from D5 to D2007 was a shock, primarily because of difficulties with third party controls I still have not totally
resolved. Some of these have D2006 versions which I tried to use, some are ActiveX / COM.
4) Disappearing controls..they appear to be loaded on the palette, later they are gone.
Appears to be a Path issue. How about some guidelines on using paths and ways to manage third party controls?
5) It took a while to find out where the bpl files are put after they are created (My Documents/RAD Studio/5.0/Bpl). Should not the IDE tell you where they are after it build's the package from an existing COM/ActiveX?
It was not easy with D5 to work with third party controls but there, some of the work was done for you with the IDE; with the
original release of D2007 it is totally up to the programmer and it is VERY difficult without paper documentation. Look as I could, Help was useless on this issue. Googling was better but what was available was for previous Delphi versions so that was not correct either.
4) Thanks for providing a place to voice these issues. You appear to have a lot to do.
I usually avoid to use ActiveX controls, although I was "forced" to use the Tom Sawyer's graphic engine (http://www.tomsawyer.com/). Delphi 7 had some issues to import its typelib, Tom Sawyer includes corrected file, but I am afraid if they stop supporting Delphi we are left on our own.
The type library editor... I used to program COM servers a lot in the D7 days... The editor did CORRUPT the type library too many times for me! Now using BDS 2006 but seldom program COM...
I heard that using M$ Office COM servers in .NET is a bit troublesome since the assembly will link to a SINGLE version of the Office assemblies? If this is the case then I think a custom wrapper Win32 COM server to be used by D.NET application would be great freeing it from linking to specific Office version.
We tried using COM for Win32/.NET interop a couple of years ago, and the whole thing was one enormous pain point. The biggest thing was that COM registration is machine-global, so it was impossible to have more than one version of our application installed on the same computer at once. And we HAVE to be able to install multiple versions, for our QA and Support departments (though clients would seldom or never do this).
Keeping the type libraries up to date as we modified our code was also a big pain point, although with msbuild that might be easier to automate today.
We don't do COM now, because it was just too unworkable. Our current generation of Win32/.NET interop consists of two pieces:
* A Managed C++ DLL to expose a third-party .NET zipping library via unmanaged exports. This "glue" code is extraordinarily hairy, especially in the parts where we hook .NET events from Win32, but once we got it working, we didn't have to touch it again. (One of my coworkers blogged about the details; see http://excastle.com/blog/archive/2007/06/02/43091.aspx if you're interested.)
* A .NET TCP server that shells out to Win32 console apps and communicates with them via command-line parameters and pipes for STDIN and STDOUT.
We won't touch COM again unless there's some way to deal with the versioning problem, but that really limits our interop options. We've looked into Hydra but it's not consistent (e.g., the way Win32 exceptions are carried back into .NET is not consistent with the way .NET exceptions are carried back into Win32), and we haven't needed it badly enough yet to work out the kinks.
If CodeGear could provide some way to define interfaces that can be automatically marshaled between Win32 and .NET code, and take care of the glue, and work on Windows 2000 and later (so no XP-only in-place COM activation), we would bite; I'd rather not deal with COM but I would if it worked. If it could automatically marshal records-with-methods too... heaven. :-)
The Transactional Data Module wizard is missing since Delphi 2006.
Thanks -
I have been using Delphi to create commercial ActiveX controls for a couple of years and have had no problems whatsoever -
With all the progress that has been made in the world of Installers such as InstallShield, nowadays, deploying an ActiveX to a client is very easy ..
I just recently ported my ActiveX components to Delphi 2007 and they still work like a charm.
Post a Comment