Description Delphi 2005 Update 1 Release Notes This file contains important supplementary information that may not appear in the main product documentation. Borland recommends that you read this file in its entirety. For information about installation, deployment, and licensing issues, see the Install, Deploy, and License files located, by default, at C: Program Files Borland BDS 3.0. Contents.
General Notes. This update contains fixes and improvements for a number of areas in the previous release of the product. The full list of changes is available in a separate file.
What s New in Delphi 2005? With Enterprise Core Objects II in Delphi 2005 it's now possible to develop applications that use existing databases for. Delphi 2005 introduces four new DB Web controls. Note that the DB Web controls are only available in the Enterprise or Architect edition of Delphi 2005.
Installation Notes International users, please see the section for important information regarding installation. This is a self-executing update.
Double-click the file to begin the installation and follow the prompts. Delphi 2005 must be closed before installing this update. You will need the original Delphi 2005 installation media to install this update.
You will be prompted for both Delphi2005Disk1 and Delphi2005Disk2 disks while installing this update. This update can not be removed after it is installed. Verifying That The Update Was Successful The final dialog of the update installer indicates whether the update was successful. You can also verify using one of the following methods:. Open the Windows Control Panel, click Add/Remove Programs, and then choose the Borland Delphi 2005 product. Use the 'Click here for support information' link and verify that the version is 9.0.1.
Open the registry using regedit and navigate to HKEYLOCALMACHINE SOFTWARE BORLAND BDS 3.0 and verify that the 'ProductVersion' and 'UpdatePackInstalled' string values are 9.0.1 and 1 respectively. If you have installed all personalities,you can open Delphi 2005 and use 'Help About' to display the About Box. The product name and version should be 'Borland Delphi 2005 version v9.0.1761.24408 Update 1' Updating International Product Versions This update applies to all language versions of Delphi 2005.
International users may have to swap disks repeatedly to install this update. To work around the disk swapping issue:. Select a location with sufficient space to hold the contents of the Install directories of Delphi 2005 disc 1 and 2 (approximately 900 MB). This could be on a local drive or a network share. Create a directory to store the files (e.g.
C: Program Files Delphi2005 SetupFiles Install) and copy the contents of the Install directories of disc 1 and disc 2 to this area. After doing this process, launch the update 1 install. When prompted for the location of the source media, click the 'Browse' button and browse to the location where the original media setup files were copied to (e.g. C: Program Files Delphi2005 SetupFiles Install). After doing this, the update 1 install should install files without asking the user to swap CDs.
Changes In This Update. For a full list of changes in this update, please see. Known Issues. If you have installed only the Win32 personality, you will see a crash on exiting the IDE.
To fix this issue, please open regedit and add a new string entry, '$(BDS) Bin dotnetcoreide90.bpl'='.NET Core IDE Package' to HKEYCURRENTUSER SOFTWARE BORLAND BDS 3.0 KNOWN IDE PACKAGES registry key. Please read the warning at the end of this file before editing your system registry. Files installed by this update This update adds or updates the following Delphi 2005 files. After successfully installing this update, the timestamp for the files listed below will be changed to 9:01 AM.
Quote I think data-aware components have their use I've heard too many horror stories and encountered too many nightmare creatures arising from them to have even a speck of faith in them:/ On the scale of bad programming practice, I rank them right with 'goto' (the development speed 'gains', the maintainance bugs and flexibility issues being strikingly similar). I have never encountered a development project that chose to NOT use data-aware controls that didn't have reams and reams of unnecessary mapping code and corresponding bugs to go with it. The data-aware controls IMO, though not without problems are a fairly elegant way of producing a Document-View pattern into a UI. Now mind you I am talking about DataSet aware and not database aware. I never connect my UI directly to the database and always use ClientDataSets. Most applications I write this way have almost Zero code in the UI with all the data handling happening in the Controller (my version of an MVC / Document View pattern). Ultimately there has to be a mapping from data to controls.
Either you use a good one out of the box, or build a good one yourself or write a mangled off the cuff one with no plan. I'm not saying that a good OPF or other solution might not be better, but in my experience most projects that don't use data-aware controls because they are 'BAD' end up implementing something far worse. Quote Interesting. I have never encountered a development project that chose to NOT use data-aware controls that didn't have reams and reams of unnecessary mapping code and corresponding bugs to go with it. The data-aware controls IMO, though not without problems are a fairly elegant way of producing a Document-View pattern into a UI.
Now mind you I am talking about DataSet aware and not database aware. I never connect my UI directly to the database and always use ClientDataSets. Most applications I write this way have almost Zero code in the UI with all the data handling happening in the Controller (my version of an MVC / Document View pattern).
Ultimately there has to be a mapping from data to controls. Either you use a good one out of the box, or build a good one yourself or write a mangled off the cuff one with no plan. I'm not saying that a good OPF or other solution might not be better, but in my experience most projects that don't use data-aware controls because they are 'BAD' end up implementing something far worse. I've been puzzling about the conceptual aspects of data-aware controls recently. I have had a long hard think about it. Beginning with the view that they were always bad, I now have a much more sympathetic view. Actually, more than just sympathetic.:).
I believe if you are writing any business application where you have your stock CRUD screens with some business actions, the data-aware method is the only method of saving you a substantial amount of time and pain. Whatever your strategy, if you opt away from data-aware controls, you will inevitably attempt to re-invent them. And most often, the reinvention will happen at the wrong abstraction level.
Delphi 2005 Download
Causing problems where you cannot decompose the user artifacts into meaningful atomic sub-components (when you need them). (Think Lego(tm) blocks - the bigger the blocks, the less versatile they become.) IMHO, data-aware controls are nothing but implementations of the MVC philosophy at the most atomic (optimal) user artifact level.
Based strongly on the observer pattern, the idea is to represent (tabular) data into existing controls. In most cases, these would be controls like combo-boxes, lists, edit boxes and grids. And because they are atomic, they lend themselves to be optimised for efficiencies like client-side 'lazy loading' of data, caching etc. There is, however, an interesting tangent to the discussion of data-aware controls when attempting to reconcile OO semantics viz. Data-aware controls are usually associated with a concept called Table-Oriented programming (TOP) because they usually deal with the manipulation and representation of tabular datasets. A concept which is not necessarily /against/ object oriented design, but is usually construed as such - IMO, incorrectly. In the end, I think data-aware controls are about pragmatism.
They shine in that department! Another thing. I fell into the trap of thinking of the MVC pattern in the same peer group as other more decomposed patterns (like the Observer Pattern). The MVC pattern is a /composite/ pattern based primarily on the Observer Pattern. The philosophy of MVC is to separate the data from the representation and the semantics of getting the two to interact. So, like any old illiterate, I attempted to classify the MVC 'pattern' as another separate and distinct one - such as the observer.:) (Duh) Big mistake. (I hate the elitism that goes around with the nomenclature around OO patterns.
I think they have failed, to some extent, in the primary purpose of serving as a commonly understood taxonomy. But then, I am getting bombastic as usual. And to add, any time I see OPF's talking about how they've developed their own OPF-aware controls, I shudder! Let those who think they can write a good OPF by all means do so, but leave the UI controls to the gurus like Developer Express! This in my mind is where pragamatism can really go out the window with a desire to be 'purely object-oriented'. And as you've indicated a table-oriented approach to visually mapping to your UI is not the antithesis of object oriented design. Quote Exactly.
And to add, any time I see OPF's talking about how they've developed their own OPF-aware controls, I shudder! Let those who think they can write a good OPF by all means do so, but leave the UI controls to the gurus like Developer Express! This in my mind is where pragamatism can really go out the window with a desire to be 'purely object-oriented'. And as you've indicated a table-oriented approach to visually mapping to your UI is not the antithesis of object oriented design.
You know, what's interesting is that the whole debate of XML-based versus Relational representation of data in the realm of (server-side) databases has now shifted towards the client-side. The /exact/ arguments of the inadequacies, lack of elegance etc that have been debated to death on comp.databases are now rearing their heads on the client-side. (They did their rounds in the middle-tier, we debated statelessness versus domain objects to death there, for instance, now we are ready to take this war to the client-side.):). Quote Ultimately there has to be a mapping from data to controls. Either you use a good one out of the box, or build a good one yourself or write a mangled off the cuff one with no plan.or you use a more object-oriented approach and pass typed data/classes to the components instead of just records of string/integers/etc. Whose exact presentation/data entry will be determined by whatever component got dropped in the UI.
For instance, you can map to the UI is an 'item', a 'batch' or a 'document' reference, instead of an untyped String or ID whose meaning will be determined by what TDBLookup (or whatever the name of that hellish combo component is) is looking up (and messing up, the day the looked up table becomes too big). Even with no code in the UI, the dataset approach means you will in practice still have a whole lot of business rules implemented in the UI: what's in the UI will decide what a particular dataset field means, how it is presented, how it is edited, etc. And all things that happen after the data has been read and before it is updated. Using data-aware components in Delphi is a bit like restricting yourself to 'record' type with variant fields in that post-OOP age. Quote In the end, I think data-aware controls are about pragmatism.
They shine in that department! Well, one can not deny they're a bit like using variants on the pragmastism front: you sacrifice clarity, structure, maintainability and strong typing to get the ability to mess things as you desire, and gain some automagical wonders. It has the same appeal as VB: no-fuss-gets-things-done, but be ready to cough good money if you want to maintain, evolve, or just get yourself out of the old-fashionned record-based-UI-with-navigator-control paradigm.