Do you know any good TLB editor (even commercial) that can be used instead of the one which comes with Delphi? It gives headaches in a lot of situations (big TLB, rename an entry ... etc.)
Thanks!
As I already mentioned in this question the Type Library support is really really buggy, especially in Delphi 2005 - 2007.
In Delphi 2009 and 2010 it got better, although there are still many bugs (try to rename a class). BUT since Delphi 2009 the editor uses the RIDL text format instead of a binary format and so you can (and often have to) manually edit the TLB when the editor did something stupid.
To answer your question: No, it doesn't make sense to replace the editor, because you would loose all the automatic RIDL to Delphi code conversions.
We opted for an IDL -> (midl) -> TLB -> (tlibimp) _TLB.Pas workflow. Manually updating an IDL file is a good bit different from visually editing a TLB file, but as programmers we prefer to type out our interfaces anyway.
This workflow is from the pre-RIDL era, so we might update in the near future.
The TLB editor from Delphi really sucked, but it got a major overhaul in Delphi 2009.
If updating to a newer version is an option, you can try to migrate to Delphi 2010 and see, if that solves your problems.
Related
There is a code base in delphi 2006 with no development for last many years. If the development needs to be activated what are the options.
Continue developing in 2006. (Not sure of IDE support etc.)
Migrate to Delphi XE2. (Not sure of what it takes)
Recode it in Java.
It seems the second option is more viable but what it would involve to do that? I read some things on Unicode support and also not sure of graphics library support.
Just to put thing in perspective, I am a Java programmer all along with experience on C/C++. However I am trying to understand it more from the perspective of what is the least resistance path to go to market strategy.
Thanks in advance.
I cannot say anything about recoding it in Java. Depending on whatever the code base does, it might be a good option, given that you say you are experienced with Java (and, I assume, not with Delphi).
Regarding Upgrading to Delphi XE2:
Check whether any 3rd party components have been used.
If not, you will probably be able to upgrade to Delphi XE2 with very few changes.
If yes, check whether the source code of these components is already available.
If not, you will have to buy new licenses of these components (and this time take the license that includes the source code!) if you want to upgrade to Delphi XE2. If you are really unlucky, the company who developed these components has gone belly up. Then you are either stuck with Delphi 2006 or you will have to find a replacement for these components.
If you already got the component's source code, you might still want to check whether to upgrade them to Delphi XE2. It might save you some headaches. Upgrading well written components is not a problem for an experienced Delphi developer (I have done so countless times over the years), but might prove nearly impossible for somebody who doesn't know the possible pitfalls.
The only breaking change between Delphi 2006 and XE2 (actually it happened between Delphi 2007 and Delphi 2009) is the switch to Unicode strings. Switching an existing code base might be painless or a real pain in the lower back, depending on how well written it is to begin with and how it (ab)used strings.
Another option you have not yet mentioned, might be upgrading to Delphi 2007, which basically was more of a bugfix to Delphi 2006 than a real release in its own right. If I remember correctly Delphi 2006 packages worked with Delphi 2007 without even recompiling.
A year ago I moved from 2006 to XE (not XE2). This was quite painless. The biggest thing was unicode. But even that was relatively easy (in my specific case probably). Most is handled by Delphi in a correct way. Biggest problems were the import components, especially when character strings were used as byte strings, which in my field (music, midi) is the norm. There is a white paper on strings conversion on Embarcadero.
I only use components with source available. If you don't, you might have have to repurchase the licenses.
It is a long jump taking 2006 to 2011/2012!
But it is possible if you consider that:
You have to convert String variables using the new conversions methods ;
You have to check all the versions between 2006 and xe/xe2 to know how the libraries have changed, bacause some have been spplited, others merged, and a few deleted ;
You have to buy/download the upgrade (if any) of your 3rd party components.
If you do that 3 things, the applications will compile just fine.
It's always easier to upgrade the IDE than rewriting the code, if there's any complexity in code beyond trivial cases like "Hello, World".
Big road blocks in Delphi 2006 might be: old components without source code, unicode issues, possible use of obsolete technologies (BDE mainly), and possible some low level hacking, like using undocumented features.
You get old versions of Delphi free when you buy XE2 licence. However Delphi 2006 is not there. Delphi 2007 is almost same (but better). It may even be possible to use D2006 binary packages with Delphi 2007.
When rewriting, first task for you is to find out what the software actually does. Line by line. Then you need to duplicate that in Java, hopefully in Java style, and then you need to verify against the old software that the functionality is actually there, duplicated.
So, you can choose between complete rewrite or something between recompile and partial rewrite, if there's problem with old components.
Read also this, old but good text: Things You Should Never Do, Part 1
That said, you need business reason for rewrite, and someone willing to pay for it.
I am interested to re-evaluate Delphi 2010. The main issue seems to be the ascii to unicode conversion. Any tips or resources about this that you have found useful?
Many thanks.
Edit:
At this point my recommendation for those that want to upgrade would be:
http://www.embarcadero.com/images/dm/technical-papers/delphi-in-a-unicode-world-updated.pdf
Is WideString identical to String in Delphi 2009
What is the compiler version for Delphi 2010?
http://chee-yang.blogspot.com/2008/10/delphi-2009-unicode.html
GIF issues:
Note that Gif (by Melander) and Png (by Martijn Saly?) images are now incorporated in Delphi 2010. You will have to use a conditional in order to use the right GIF unit:
USES Windows, SysUtils, Graphics, blabla
{$IFDEF VER150}
, GIFImage, {Delphi 7}
{$ELSE}
GIFImg {Delphi 2010}
{$ENDIF};
Also you need to "fix" the PNG provided by Embarcadero:
http://talkdelphi.blogspot.com/2009_03_01_archive.html
Other things that you need to know is that you really have to backup your project before opening it in Delphi 2010. Delphi 2010 will change your DFM file even if you don't press the Save button. The form will lose data and it will not compile in D7.
UPDATE Delphi XE
I have finally purchased Delphi XE. Delphi XE proposes some new features but, unfortunately, quite few of them are not working at all (background compilation, UML modeling, code insight, etc). Other features have been downgraded (the help and, for example).
The IDE is also not as stable and fast as Delphi 7 and the toolbar has real problems (better don't customize the IDE). There is also a nasty bug where the IDE has 100% CPU utilization (see my other posts about all these issues).
I hope that in Update 2 and 3 they will fix some of the most stringent issues.
Anyway I think I upgraded too soon because now Embarcadero announced the 64 bit compiler, so probably I will have to pay again a lot of money to upgrade to the next version of Delphi in order to get that compiler. For those that are still thinking to upgrade to Delphi XE I would recommend to trial Delphi XE HEAVILY.
Conclusion:
Delphi XE brings LOTS of new features, but obviously you won't be using ALL of them.
The stability of the IDE is not better.
It helps you build more up to date applications (modern UI open/save dialog, application manifest).
Support for unicode.
UPDATE Delphi XE7
The difference between XE and XE7 was not that huge as the upgrade from Delphi 7 to XE. The IDE is as stable as before (lots of crashes and random access violations in RTL).
UPDATE Delphi Rio
Considering the amount ot years since the last update, I could safely say that the difference between XE7 and Rio is barely visible - except for those that are interested in cross platform apps (Mac, Android but not Linux!).
PROS
True high DPI support (really Embarcadero? After so many years?).
IDE does not crashes so often as it used to crash in XE7.
VCL themes finally (seem to) work.
Most stable IDE until now (still crashes if you open a project group with more than one project in it).
Almost full cross-platform support (you need to purchase the more expensive Architect version to get Linux). Fortunately, for me, this is a bit too late. The projects where I needed cross-platform were already started under Lazarus.
Upgrading the code was super easy.
CONS
Some HIGHLY advertised features like dark themes don't work at all!
The Insight still buggy: new language features (like declaring inline variables) not supported by the IDE (the code will have that wiggled underscore red lines). This issue will probably never be fixed.
Another super annoying IDE issue is that the compiler will still show the last hints/warnings/errors EVEN after you fixed them. Looks like the log data remains in some kind of cache.
Overall it is the most stable IDE until now, but still I wonder (especially if compared to Lazarus) if it worth that pile of money.
Conclusion over the years:
Delphi is such a nice and clean language. And the Delphi compiler speed makes any C++ compiler to look like a toy for kids.
I still feel ashamed people look down on me when I say that I am a Delphi developer. Delphi as a language is extinct now. Just look for Delphi jobs in Germany and only 74 positions are listed (but most of them are mixed with C# and others). C++ has over 1500 positions! Borland and Embarcadero helped a lot to kill Pascal. They do offer a free (even though crippled) version of Delphi now, but the damage was done. It is to late to resurrect Delphi now.
I think three main issues lead to this state:
Borland abandoned Delphi (Delphi lagged behind compared with other languages).
Embarcadero took over but disrespected the customers (over-buggy, over-expensive product).
MAIN ISSUE: The language was not promoted (at all) over the years. No sane company will spend thousands of dollars for a license of an already dying language. And the lack of a free license TOTALLY outcast the new generations of programmers.
Therefore, we are on StackOverflow, wondering each year if worth investing money in a new Delphi license.
Update
Finally, Emba released a free (aka Community) edition and boy you can see the effects.
For the first time in years, I don't feel ashamed to say in public that I am the user of Delphi (a dying language).
We have created a web page specifically for this very issue:
http://www.embarcadero.com/rad-in-action/migration-upgrade-center
There, you can find webpages, documents, webinar replays, etc. which all cover the issue of migration.
The first thing people say is "I have a huge codebase, and migrating to Unicode will take forever" and almost without exception they discover that "forever" really is a much shorter period of time than they originally thought and that the new features of Delphi 2010 make it all worth it.
The biggest problems are with 3rd-party libraries and VCL. If they're not on D2010, it can be painful. The Unicode issue comes up if you are doing calculations with the length of strings or PChar arrays, assuming one byte per character. You can usually get away with treating everything as old-style AnsiString / AnsiChar. But then you don't get the benefits of Unicode. If you don't have anything that would be hard to do in Unicode, just do everything in Unicode and you'll be much further ahead than if you have to worry about switching back and forth.
Converting code to unicode doesn't take that much time in itself as long as you didn't do anything "funny" with your strings. I converted close to 1m lines of code + the database in less than 2 weeks. The guys at codegear did a very good job at doing it a lot simpler.
Your code might recompile in D2010 without any changes (But with quite a few tons of hints/warnings).
The worst problem from the conversion comes from calls to Window's API that were incorrectly done. For exemple, the function GetComputerName that ask you the size of the buffer in TChars(as specified by the API). In Ansi, TChar = 1 byte, so Length = SizeOf. In Unicode, it's not true anymore. Worse, the call to the API might not fail. It will just overwrite some valid part of memory and will crash just much later.
Oh... And there is also those slight differences between Ansi and Unicode in Windows API. For exemple, the lpCommandLine of the CreateProcess is read-only in the Ansi version, but read/write in the unicode version. So using a constant as parameter worked fine in Ansi, but will crash in Kernel32.dll in Unicode.
Overall, it depends a lot on the quality of the code you are working with. Bad code might be very hard to port to D2010. Good code should be pretty easy.
and read the resources that Nick Hodges linked to, they are pretty helpful.
For Unicode conversion issues, your best bet to see the problems people have encountered and what others have done is to get Cary Jenson's White Paper: Delphi Unicode Migration for Mere Mortals.
Also I'd highly recommend Marco Cantu's "Delphi 2009 Handbook" that describes all the changes in the Major 2009 release that includes Unicode and Generics and more. Much of his Unicode material from that book is in his White Paper: Delphi and Unicode.
We have upgraded from Delphi 7 via Delphi 2007, 2009 and now 2010! The following are the biggest issues we have found.
Threads have changed, with Resume and Suspend being deprecated.
Unicode
The structure of projects have changed and are not backwards compatible
The structure of dfms have changed and are not backwards compatible
Hope this helps.
I agree with Chris - the biggest problem in migrating our code to 2010 was getting all of the 3rd party libraries working. A number of them needed minor source edits here and there and had to be installed from the modified source. Still, that said it wasn't more than a day or so of getting things sorted out.
The only other problem we've had moving to 2010 involved one small section of code that went buggy because of a change in the way 2010's ProcessMessages works. It was an old piece of code that probably shouldn't have been written the way it was to begin with (ProcessMessages and Sleep() inside a while loop waiting on an OPC variable change). It worked in 2007 but in 2010 it somehow devoured system messages and locked up the OPC server. For us it was a small fix, but like Ken said it will likely depend on the quality of code you are porting. 2010 seems a bit less tolerant of poor practice and ugly hacks.
View this Embarcadero webinar on how to migrate from older editions of Delphi with some stories of what to look for and how to update your code (including tools and resources to help you along the way), on this link: https://community.embarcadero.com/blogs/entry/migrating-delphi-case-studies
We recently converted our long-running Delphi project to Open Source. Multiple people have contributed patches already, which is great, but unfortunately forms and frames when saved with Delphi 2006 (and later) contain new properties in the .dfm that are not handled by older versions. Forms are handled quite gracefully by the IDE ("ignore propery?"), but frames are loaded at runtime and result in errors. Not an option, as far as I'm concerned.
I now removed those properties from the .dmf files by hand, but I am really wondering if there is a more elegant solution. There is no way to save in a backwards compatible format from the new IDE's, is there? Are there existing tools to strip the nonsupported properties from the .dfm's ? Any other elegant solution I am missing?
Normally, with a commercial project, I'd just upgrade the project to the most recent version applicable... but as this is open source I really don't want to loose out on those developers still working on Delphi 7. That includes myself, actually.
The JEDI JVCL project uses a little utility dc.exe (delphi cleaner) and a list of properties in DFMs that are not present in older versions of delphi, mine contains the following text:
*.PopupMode
*.PopupParent
*.ExplicitLeft
*.ExplicitTop
*.ExplicitWidth
*.ExplicitHeight
*.BevelKind
*.BufferDocument
*.DoubleBuffered
*.ParentDoubleBuffered
*.DisableHyperlinks
*.AlwaysEnquoteFloats
*.PixelsPerInch
I run this dc.exe utility from a batch file which cleans my dfms before I commit
changes to subversion. The syntax in my batch file for this is:
dc.exe -s -fd10.txt *.dfm -i
You can grab my stuff at:
http://sites.google.com/site/warrenpostma/files
You can try Andy's DFMCheck. It can automatically open and close all forms and frames in a project, which makes the IDE remove unknown properties (as Marco wrote).
Well, for sake of completeness:
Open the dfms in the oldest Delphi supported, let it remove all unknown properties, change a property and save.
For your purposes, Warren's solution is better, but it can be a workaround. I did it for a while when we were dual D7-D2006ing.
I used to work in Delphi 6, and got very used to having CodeRush's various helpful IDE additions. Many are now in the IDE itself, or I've managed to replace with something else, but the one feature I REGULARLY find myself wishing I had in Delphi 2007 still, is the ability CodeRush had that added little "connecting lines" between components that were linked to each other (lines showing the connections between TDataSets and TDataSources, for instance).
Does anyone make something that does that in the newer Delphi IDE?
=== * LATER NOTE / Clarification * ===
Andreas is correct in his comments below... "I don't think that he meant structural highlighting which works on the source code. He wants "connection lines" between components in the form designer."
He also says "as far as I know there is no such tool for Delphi 2005 or newer".. which is a bummer if true. (...and if that IS the case, what's the best place to make Delphi IDE feature requests?)
I don't think it exists. The best place to make form designer feature requests is here.
another freeware/opensource option would be to look at CNPack which supports structural highlighting and runs well in Delphi 2009. The library contains many other enhancements to the IDE also, some which are duplicated in other packages such as GExperts. I run both CNPack and GExperts in both 2009 and 2006 without any problems.
You want Castalia, which works fine here on my D2007 for structural highlighting.
Castalia from Twodesk
In the company that i work, we develop all the GUI in C#, but the application kernel is mainly developed in Delphi 5 (for historical reasons), with a lot of components made in COM+. Related to this very specific sort of application a I two questions:
Experienced guys in Delphi and/or COM, do you have any workrounds to work with the buggy TLB interface ?
Some of the bugs are: IDE crashing during edition of a large TLB, lost of methods IDs, TLB corruption, etc.
Here, we haven't found any good solution. Actually we tried do upgrade do the new 2007 version. But the new IDE TLB interface has the same bugs that we found before.
How do you control TLBs versions ? The TLB file is in a binary format and conflict resolutions are very hard to do. We tried to do it exporting the interfaces descriptions to IDL and commiting into CVS, but we didn't found any good way to generate TLBs from IDL using Delphi. Additionaly, the MIDL tool provided by Microsoft, didn't parse correctly the IDL files that we exported from delphi.
I think you should have a good look at Delphi 2009.
Delphi 2009 has changes to the COM support, including a text-based replacement for the binary TLB files.
You can read more on Chris Bensen's blog.
In the distant past (before I started working for CodeGear) I gave up on the odd Delphi-ized IDL language that the IDE presented, and wrote my own IDL and compiled it using MS midl. This largely worked; the only catch, IIRC, was making sure dispids (id attribute) were correct on automation interfaces (dispinterfaces) for property getters & setters - there was some invariant that tlibimp expected but midl didn't guarantee.
However, now that Delphi 2009 uses a safe subset of midl syntax, and includes a compiler for this midl in the box and integrated into the IDE, these problems should be a thing of the past.
We have also just installed Delphi 2009 and it does seem to have improved the support for Typelibraries. However I have worked with COM and type libraries for quite some time and here are my general gotchas that I have found over the years. I would agree its pretty buggy and is all the way up to Delphi 2006 (our version prior to using 2009).
Always have every file writeable before opening. This may sound obvious, but when working with source control sometimes we forget to do this and try to remove readonly flag after opening a file - Delphi cant deal with this. Ensure tlb is writable before opening.
If editing a standalone typelibrary you MUST have a project open. For some reason if you open a type library on its own it will not save. Create a blank project and then open your typelibrary. For some reason this allows the type library to be saved.
If your type library is used by an application or COM+ ensure that application is shut down or COM+ disabled before opening the type library. Any open apps will prevent the type library from being saved.
However I think your best solution is probably an upgrade. You get Unicode support too.
Using Delphi 2009 has greatly taken much of the pain out of huge TLB files, and conversion of our existing objects was painless, but our com objects don't use any third party libraries.
We will be migrating our gui applications over once the library vendors release supported versions.
Same experience with the TLB interface here: we simply stopped using it.
We work with several separate IDL files (hand-build) for different parts of our framework, making use of the #include construct to include them into the IDL of the actual application, then generate the single tlb using MIDL and tlibimp it. If the application has no IDL of it's own, pre-compiled version of the different framework TLB files are available.
Whenever the framework enters a new version, a script is run to re-generate the GUIDS on all necessary interfaces in the IDL files.
This has served us well for many years, and for us to move over the new Delphi 2009 IDL/TLB toolset will have to be not only integrated into the IDE, but also versatile when it comes to automated builds and whatnot. Can't wait to get my hands dirty with some experiments!