Has anyone been able to convert the StringAlignGrid by Andreas Hörstemeier from Delphi 6 (his latest release) to work under Delphi XE?
I have several projects that use StringAlignGrid extensivly and I would rather not convert to another grid if possible.
Steve...
The source is freely available, so if you need to get this working straight away, you could just attempt to do it yourself.http://www.hoerstemeier.com/files/grid21.zip
I've quickly loaded the source and it's not that hard to do. I've got a version that compiles here, but I don't really have the time to test it. It took me about 3 minutes to get it working, so I suggest you just do what I just did:
ah_def.inc needs to be changed add XE; Otherwise you'll get a lot of code that's meant for pre-delphi 3. That fixes most of the compiler errors.
there's a conditional define in ah_def.inc that defines ShortString. If it's defined, you'll get String instead of ansistring.
A couple of PString variables that need to be changed to PAnsiString (unless you want to have unicode)
two PChar's that need to be PAnsiChar.
If you do make it work, don't forget to send your version to Andreas.
I faced this problem in the past for another component. Contacting the author was the solution : I received the sources for free accepting a confidentialty agreement.
Related
I have problem to build my project. I am using delphi 2010.
when i try to build my project this error shows up. "F1026 File not found: 'System.Action.dcu'
I've tried to find solution for this error, but i can't find anything that really fix this.
any idea?
First of all, I am going to assume that the error message actually refers to System.Actions.dcu (as per the question title) rather than System.Action.dcu (as per the question body). It's always best to use copy/paste error messages so that they are transferred verbatim.
You are using code written to target a later version of Delphi. Not only does Delphi 2010 not have unit scope names, i.e. System.<unitname>, but it does not have the Actions unit. If memory serves correctly, unit scope names arrived in XE2 and the Actions unit in XE3.
The code you are compiling has a unit the uses System.Actions. Find that unit and work out where it came from. Then you'll need to work out how to proceed. Can you get a version of code that supports your older Delphi version? Can you port the code to your Delphi version? Can you find an alternative library? Only you can answer those questions, I'm afraid. We cannot give advice at the moment since we do not know anything about the code that is causing you problems.
I've just downloaded from SVN the DUnit2 code base.
Does someone has compiled it successfully?
What steps/prerequisites I've to follow in order to compile it?
Do someone knows if an already compiled version exists?
thank you
fabio vitale
In the projects directory, find the subdirectory corresponding to your version of Delphi. In it, you should find a project-group file, either DUnit2ProjectGroup.bpg , DUnit2ProjectGroup.bdsgroup or DUnit2Delphi<version>.groupproj. Open it and compile all the projects in order.
Using DUnit2 is pretty much the same as using DUnit.
In case someone else stumbles over this question while trying to make DUnit2 run on Delphi XE (or XE5):
TL;DR:
Dunit2 (official SourceForge source, revision 101) doesn't currently (being as of this writing on 2015-06-01) build successfully on either Delphi XE or XE5.
To make it build on XE or XE5, go get the patch I posted here
Apply it to the source tree. It should now compile and you should be able to open the .groupproj and build all the contained projects successfully.
The patch may be applied with and was created with TortoiseSVN (in case it matters).
Longer version:
Amazingly tonight (2015-06-01) I followed the same steps as Fabio (in 2012 no less) and ran into exactly the same issue (E2010 Incompatible types: 'Pointer' and 'Integer') trying to compile DUnit2 (revision 101 trunk checked out directly from SourceForge) on XE and XE5.
I've come to the following conclusions:
1) There's multiple issues with the head revision with respect to both XE and XE5.
2) The key issue above that Fabio mentions can be fixed by replacing IntPtr with Pointer.
This doesn't actually seem to make any difference in the code as far as I can tell, and the test suites also pass fine on both XE and XE5 after this change, though caveat emptor - I've not looked too carefully either (and also subject to caveats below.)
3) Project search paths being out of date [XE]. Just needed updating/fixing.
4) Missing $DEFINES for XE5 and others, despite some other code being quite aware of XE5
5) Some enhanced TRect stuff that's not available on XE. (The amount is relatively small and relatively trivial to inline to more basic expressions that will compile and is available on XE so was by no means show stopping.)
(Re 3,4 & 5 -- Sadly I get the impression the codebase isn't very well tested against multiple compiler/BDS targets.)
6) Some kind of Application.OnIdle/GUI testing bug (run T_TGUITestCase tests to see it) whereby the GUI automation tests would block unless you keep "feeding" the Windows Message queue by say moving your mouse or pressing the shift key to trigger Application.OnIdle events (repeatable on my Windows 8 XE5 and XE binaries).
Now speaking off the top of my head, and from vague memory from many years ago, I seem to remember having run into this before, and that it is down to a subtle change in behaviour either in Delphi or in Windows some time ago. -- IIRC in past, it used to be the case that one would would actually still get the occasional Application.OnIdle() call in your Delphi app even when nothing else much was going on on the system, even when you set Done to True. And as I recall, this changed at some point due to either a change in Windows or Delphi (can't remember which) several years ago and one had to be a bit more circumspect about setting Done to False if you didn't want your App to go to sleep entirely. In any case, it clearly was/is an issue on my PC tonight with the current (as of this writing) DUnit code, so I had to patch around it.
I did this in arguably a rather kludgy way, e.g. by manhandling things via providing an OnIdle handler while running GUI automation tests to signal that that the app is not in fact done (e.g. "don't block, don't go to sleep") and then reinstating any prior handler immediately after. There is no doubt a more elegant solution to this, perhaps by posting a message to ourselves to keep the app "alive", but my first attempt or 2 at something better didn't work out and I'm not interested enough to pursue this further. I'd be interested to hear of a better fix though.
I've supplied patches, but got no feedback from the DUnit2 team on SourceForge. So I forked DUnit2 with the full commit history into my Github account. I've applied many fixes there, including the compilation issues with XE & XE3+ and the scriptable self-tests that pause if no mouse action occurs. I'll continue my development of DUnit2 on my Github account [https://github.com/graemeg/dunit2].
Please explain package use (in short sentences with small words (for Dummies)).
I just moved from D7 to XE2 and packages seem much more prevelant, and I seem to need to qualify a lot more things.
In D7 I would say uses windows and now I must say uses winapi.windows.
I find that when I call MessageDlg() I can't pass in mtError, I need to qualify it.
Before I go too far down the wrong road - what's the simple solution?
Can I somehow continue to use my old code with package names which I suspect are terminal (that is, for packages A.B.C I have auses C clause).
Can I add one statement somewhere to do this? Or configure the project.
Sorry to sound so dumb :-(
Package use is no different in XE2 than in earlier versions. What is different is that all of Embarcadero's unit names are now prefixed with new Unit Scope Names ("System", "Vcl", "Winapi", etc) to help designate which units belong to the RTL, the VCL, FireMonkey, specific platforms, etc.
You can update your code to fully qualify everything now, if you want to, but you do not have to. You can instead specify the particular scope names in the "Unit Scope Names" setting of the Project Options instead, then no code changes are needed (other than the usual changes when migrating from one version to another).
These are called unit scopes. Because of the new FireMonkey libraries, and the cross-platform support, it's required that you declare which unit you're referring to for types and function declarations.
You can set defaults using Project->Options->Compiler->Unit Scope Names. This is documented as well.
I have a few Delphi 6 third party components which I need to add to Delphi 2010 to begin my migration. Is it possible? The interface seem a lot different and I can't seem to find a way to do this?
This help...
My components: DBGridEasy, TSerial, Varian Async32.
Thanks a lot.
As has been mentioned this is not straightforward. But you do have options.
Check with Vendor and get update
if you have source you can try to update yourself.
I don't agree that it is neccesarily too complicated to upgrade. Delphi 2009 did add (finally - about a decade after it should have) very good Unicode support into the heart of delphi, but this was done down to the level of almost every built in function.
We upgraded a large (700,000 lines) project in only a couple of days. There is info on the net on what to do, there are a number of functions you need to replace if you use them (such as any funcion with Ansi in the title). Its worth a try at least.
If you dont have the source I'm afraid you have no choice but to contact the vendor, there is nothing you can do since the binary format for each Delphi version is differnt.
I don't know for sure about those particular components, but it probably won't work even if you have the source for them because there were many changes between those versions, such as the string type changing. You would be better off finding out if the vendor has updated them.
The biggest change between Delphi 6 and Delphi 2010 is the changing of the default strings to Unicode in Delphi 2009.
I highly recommend against using any pre-Delphi 2009 component with your upgrade. They will not know about Unicode and you will run into problems.
First, you should see if the new version of Delphi already has the functionality you want built in. Many things have been upgraded over the years. You may find you don't need some of your old components at all.
For the ones you still need, try to find an upgrade, or some other similar component that is ready for Delphi 2009. There are many grids around. I am not familiar with Serial or Async programs to recommend one.
This might already help you: Varian Async was acquired by TMS, the same component is now known as TMS Async32
It is possible to work with a Delphi 5 project in the Delphi 2009 IDE by referencing the Delphi 5 version of dcc32?
If so are there any issues to watch out for concerning the way that project settings (search paths, conditional defines etc.) are implemented in 2009?
Edit: Just to clarify I am also upgrading the project to Unicode but will still need to debug and run releases in the old configuration
It depends on what you're trying to accomplish and what limitations you are willing to accept.
As far as I know, you can't use the Delphi 2009 IDE to maintain Delphi 5 projects directly. For example, even if you stick to functionality that's common between the two, some properties that are not supported in Delphi 5 are written to your DFMs, causing an error at run time.
I've maintained projects and library code that were written in Delphi 2005/2006/2007 that was also being used in Delphi 6/7. I usually edited and debugged these using the latest IDE. I had separate project files for each target version and made sure they all used the same memory manager. Finally, I had an automated build process and unit tests that would strip incompatible properties out of the DFMs (my own DFM Scrubber), make sure all of the targets always compile and run unit tests, which are also recompiled for each target.
All in all, it's more effort and I wouldn't recommend it unless you have a specific requirement to do so.
No. That said, it is still Delphi, and assuming you have source or D2009 versions of any custom components it can be modified to compile in Delphi 2009. The layout of the VCL has changed quite a bit since D5, so expect to have to modify your uses clauses and probably rewrite some small chunks here and there, but it is doable.
You either port your code to Delphi 2009/2010 level (Unicode), or you may as well not install the product.
I suggest you open the project and see where it fails, close the project (without saving anything), find the component versions you need and install them, and once the project opens up in design mode (all components are installed) you can start porting.
Read the Unicode Delphi migration (porting) information available at the website.
Ask your self each time you see PChar, and Char, if it needs to be PAnsiChar, or AnsiChar instead? If you are reading bytes from a disk, a com port, or a network connection, you will need to change from Char to AnsiChar, from PChar to PAnsiChar, otherwise, you might just leave the Char and PChar as they are and they will become Unicode. Always be aware that Char is not a Byte, anymore.
You also must replace explicit references to narrow Win32 API calls with versions without the A (ansi) suffix. Example: CreateFileA might need to become just CreateFile.
W