Nick Hodges gives five reasons for ISV's to use Delphi in his blogpost Delphi: The choice for ISVs.
I totally agree with them. Under the motto 'Spread the word' I decided just to copy them here:
Go, Go, Go, Go, CodeGear!
Programming blogs containing .NET, C#, LINQ, Objective-C and Delphi experiences
Nick Hodges gives five reasons for ISV's to use Delphi in his blogpost Delphi: The choice for ISVs.
I totally agree with them. Under the motto 'Spread the word' I decided just to copy them here:
Go, Go, Go, Go, CodeGear!
My first impression of the website is that it is a very 'clean' website with clear navigation.
Good job CodeGear!
On Bitwise Magazine there is an interesting article 'Free, Free At last' with a list of IDE's which are all for free!
Among them of course the Turbo's.
Surprisingly, there is now quite a range of first rate development software that can be yours (legally) for a total outlay of Zero Dollars - which, at the current rate of conversion, coincidentally works out at precisely Zero Pounds, Euros and Yen too!
One particular IDE of interest for me is the PHP IDE, called qstudio, from Quadram software. This is an IDE for PHP development which looks amazingly like Delphi. QStudio is to be released this december, so keep an eye on it!
Office 2007 introduces a complete new GUI interface. One of the eyecatchers is the so called Office 2007 ribbon.
Today devexpress announced the availability of the Ribbon control for both the .NET users as the VCL users (currently in Beta). For VCL users there is also (among others) the Toolbarpager control from TMS Software.
According to Julian Bucknall's blogpost the ribbon can only be used if you obtain a license from Microsoft. (A vendor's license does not cover a user license)
Quote from Julian's blogpost:
To summarize, if you want to use a ribbon in your applications (whether you decide to use either our .NET or our VCL components or, horror, someone else's :) ), you will have to sign the Office UI licensing agreement with Microsoft. This no-cost license is a royalty-free agreement between yourselves and Microsoft that enables you to take advantage of the intellectual property (IP) that they've embodied in the new Office 2007 UI (including copyrights, trademarks, and patents). Part of this license is a remarkable document: the Office UI Design Guidelines that describe, in almost excruciating detail, how the ribbon and its associated controls must work and must look in an application in order to satisfy the license.
Microsoft has invested a lot of money in creating the ribbon, so in a way it is generous that they allow us to use it at no cost, although I personally find it a bit strange to license a GUI (Just a bunch of pixels on the screen, isn't it?) and earn nothing with it. What is the deal? What is the catch?
Can't figure out Microsoft's intention with this except that all ribbons should work according their guidelines.
But how will Microsoft prevent a from scratch build ribbon with little different functions and ways?
More information can be found here:
Jensen Harris blogpost : Licensing the Office 2007 user interface
The announcement by Microsoft.
The Microsoft office UI guidelines preview. (PDF 1,4 MB)
One of the great things about Delphi is the fact that there are a lot of awesome third-party components out there. Commercial, Open sourced and freeware, you name it, there are good quality components plenty in each category. And as a tradition they (mostly) come all with sourcecode.
The benefits of third-party components are obvious but depending on the component set. There are components that give your application a modern look, while others solve a particular programming problem like communication protocols.
But it all comes down to the fact that using third-party components gives you the benefit of "dealing with the meat, instead of beans".
Besides that, if your vendor adds some nice new feature to a component, you can add that feature to your application by simply upgrading your components.
A disadvantage of third-party components is the fact that you become, sort of, dependent on the vendor.
Upgrading to a new Delphi version means upgrading the components. In other words you can only upgrade if you have all your components upgraded. So a lazy vendor can frustrate your upgrade plans.
What if a vendor goes out of business?
As said most components come with sourcecode, so in the worst case you can maintain the code yourself, although that was not the deal of course.
These are some consideration we made before using/buying third party components:
Our 3-rd-party favorites are:
Conclusion:
Third party components are great. Buy/use them only if they come with source code. And last, but not least use them wise!
What are your favorites?
This is the moment, well last night (here in the Netherlands) was the moment. The Borland Developers Tool Group (DTG) becomes Codegear. See the original press release.
Have not yet read all the details, but it seems it is a separate company yet owned by Borland which will be independend by the end of next year.
For a (long) list of blogpost and comments see www.delphifeeds.com
Go CodeGear!
According to Tim Anderson's blogpost Microsoft has a special session at the Tech-Ed in Barcelona targeting Delphi developers.
Quote from Microsoft session:
Even if you are not considering .NET now, at some point you will have to move to .NET with new code, or to port existing code. Staying with Win32 may be viable in the short term, but not the long term.
Well, I am not sure what to think of this. There might be some point in time (who knows?) that you will have to move to .NET, however there are no signs on the wall that Win32 is being abounded real soon.
Delphi developers can still make awesome Win32 applications, which have plenty of opportunity to be ported to .NET at some time in the future with minimum effort. (I have blogged about the possibility's here ).
Delphi is all about being able to choose.
In a recent project the end-user should be able to do some settings of a specific control. The control, an InstrumentMeter, has a lot of properties, and only some properties, like color, scale etc. had to be customizable by the end-user.
A very common way to let a user edit properties is to use a RTTI property inspector. The user can then edit properties in a Delphi way. I use the Devexpress RTTI inspector, but there are many alternatives outthere. The RTTI inspector object has a property to link the 'to be inspected control' called InspectedControl of type TPersistent.
Because users may only edit some of the properties I could not set the control there, because all the published properties would become editable.
So I decided to make a wrapper class for the control, which published only the necessary properties and 'links' them to the InstrumentMeter control.
(You can inherit a control and publish only those properties that you want to, but this works only inside of Delphi)
I decided to inherit this class from TPersistent, so that I could set it in my RTTI Inspector.
The class looks somewhat like this:
type
TInstrument = class(TPersistent)
private
public
//the InstrumentControl
property InstrumentControl : TInstrumentControl;
published
//All enduser props
property Kleur: TColor read FColor write SetColor(const Value : TColor);
property ...
end;
Properties set by the user (for instance Kleur) must be saved to a database. I could of course extend a table with fields for all the properties, but having several types of instruments this would give a lot of extra fields.
Why not persist the TInstrument object?
Yeah great idea, stream the object into a blobfield of the database. This can be done easily with a TComponent class, but how do you do this with a TPersistent class?
A TComponent class could be streamed with the TStream WriteComponent method like this:
MyStream.WriteComponent(AComponent);
This stream then, could be saved into a Blobfield and later on read with the TStream ReadComponent method.
I realize that I should inherit from TComponent so that I would not have a problem streaming, but hey let's persist on the TPersistent for now.How to save a TPersistent to a stream?
As far as I know now, this is not possible.
The only way to do this, as far as I know, is to use a DummyComponent (TComponent) with a property holding the TPersistent object, and then streaming both in the database. That works fine!
The code looks like this:
type
TDummyObject = class(TComponent)
private
FPersistent: TPersistent;
public
//Property for holding my Persistent object
property Persistent: TPersistent read FPersistent write FPersistent;
end;procedure SavePersistentToStream(APersistent: TPersistent; AStream: TStream);
var
DummyObject: TDummyObject;
begin
DummyObject:= TDummyObject.Create(nil);
try
DummyObject.Persistent := APersistent;
//write the component into the stream
Stream.WriteComponent(DummyObject);
finally
DummyObject.Free;
end;
end;
procedure LoadPersistentFromStream(APersistent: TPersistent; AStream: TStream);
var
DummyObject: TDummyObject;
begin
DummyObject:= TDummyObject.Create(nil);
try
DummyObject.Persistent := APersistent;
AStream.ReadComponent(DummyObject);
finally
DummyObject.Free;
end;
end;
Writing this I decided to inherit from TComponent anyway (why not?) but the question remains, are there other ways to persist a TPersistent?
We have had the 24 Hours of Delphi, The Delphi Hour weekly podcast, and now we also get two weeks of Delphi!
Two weeks long every day one hour live Delphi and C++ Webinars!
This webinars are highly interactive, you can contact the presenters by e-mail, skype etc.
Starting 6 nov. - 17 november.
For details check out the Borland Developer Network.
OK, you think you found a bug, you report it very carefully in Quality Central and write something about in a blogpost, all because of the fact that the bug was caused accidentally.
After that you expect some confirmation of people who encounter the same problem. It happens that no one else so far, including some coworkers can reproduce this bug.
Huh, time to investigate some more. For those who did not read the blogpost, the bug happens when you type, or paste, the string =: in a class definition. Memory is freaking out upto 1,9GB.
Investigate
Looking more carefully to the Windows Taskbar it appeared that 1,9GB is used by Windows, but only 15MB by BDS.exe. No other processes use even more memory then BDS, where did approx. 1GB memory go???
As someone suggested I did stop the Error Insight feature but had no luck, the bug is still there.
The solution
After turning off most of the BDS features the problem still persisted, and I asked myself why to put so much effort in a bug, which only happens by accident.
Anyway I found the part that causes the problem : Castalia 4 BE.
After turning off the 'Enable Delphi parser' option the bug was gone.
Conclusion
This bug is caused by Castalia in combination with BDS. QC Report updated. (Pooh it isn't me :-) )
Can someone please confirm this? (After confirmation I will drop an email to Castalia about this problem)
What is causing the huge amount of memory while no process owns it?
Well all this trouble for a bug which was not meant to be a bug...
Today I encounterd, by accident, a 'bug' in Borland Developer Studio using the Delphi personality. I do quote the bug here, because actually it is not a bug, but on the other hand it is a bug. (How about confusion)
Accidently I pasted a string in de class definition of a form. The pasted string happened to be part of a query with a parameter in it.
"WHERE somefield =: SomValue "
After this BDS increased its memory usage upto 1,9GB!
This is definitly a bug, but what is the chance that you encounter this bug?
Actually almost zero. I mean who types a '=:' in a class definition? Well ahum I do.
I assumed this bug has something to do with Error insight, so I reported it in Quality Central where you can find in under QC36020.
Main issue here: Is a bug a bug until he (or she) is discovered?
Go try it yourself!
Steps to reproduce:
1. Start BDS2006
2. Create a new VCL application
3. Type =: in, for example, the private section of the TForm class definition
According to Chris Pattinson (Borland/DTG) in this newsgroup thread the command line compiler for registered users of Turbo Professional is now available for download here.
It seems that the command line compiler is needed to install third party components like Developer Express and JVCL.
Not only the weather, here in the Netherlands, is hot (at least for this time of the year) also BDS2006/Turbo hotfixes are hot. Allen Bauer posted a hotfix-roll-up containing all the hotfixes in one setup. New hotfixes are also added so the total count of hotfixes is now nine. For more information you can also explore this BDN article.
You can only apply this hotfix-rollup to the Turbo Editions, or BDS2006 with Update 2 installed. Previously installed hotfixes (1-6) have no effect on this rollup. I installed the rollup on BDS2006 Update 2 with some hotfixes (1-6) pre-installed and found no issues.
Hot fix 9 addresses some memory leakes of the IDE (QC 22481). I have not seen (increased) memory usage after applying this hotfix yet, so hotfix 9 is a must have!
You can get the hot-fix-rollup at several places:
Codecentral
Allen Bauers weblog
Turbo Explorer Download page
Last week the Turbo Explorer editions have been launched. Nothing new here or you must have been living under a rock.
Although I'm personal not intrested in getting the Turbos because I use BDS 2006 I can certainly feel the excitement about it and will advocate it as much as possible. Here are some intresting blogposts from the last week:
Turbomerger is an utility by Andy which allows you to build your own Turbo Explorer Studio so that you can use all personalities (Delphi Win32, Delphi .NET, C++ and C#) on one machine. It seems that this is allowed and that it was only a technical problem to be solved. Great stuff!
ISO Images are set online according to Daniel Wischnewski's blogpost by Delphi Praxis so that you burn your own installation CD's. Even CD labels are provided in PDF format. I think we all should burn a couple and give them away to intrested developers.
Turbo Delphi Explorer from Square one is a document by Jeff Duntemann which might be, according to the website, the beginning of a new book. Jeff Duntemann really inspired me back in the 80's with his Complete Pascal series. His books are a good read and funny. I remember his book on Delphi 1 which included a real novell starring 'Ace Breakpoint'. Intresting to see new work from him.
Bitwise magazine started a new serie 'Introduction into Delphi'
www.turboexplorer.com is the official home of the Turbos. Stay tuned to this website for more information. You can download the turbos here or go to one of the available mirrors.
More Turbo info from Borland:
Places to buy Turbo Professional
The Turbo Editions FAQ
This is more like a test blogpost, using the new Microsoft Windows Live Writer application.
WLW supports many blog engines like Blogger, dasBlog and of course MSN Live spaces and many more.
WLW is a WYSIWYG editor with all the standard editor functions and more, like spellchecking and the possibility to insert a map using Microsoft Virtual Earth. I tried to show you where I live, but it gave me an error :(
It is obvious that WLW is written in .NET, startup time is a bit slow, but when it is running it is quit snappy.
Developers are able to extend the capabilities using the Windows Live Write SDK.
All with all a nice tool for writing blogpost straight from the desktop. And if you can read this is, it must be working for blogger.com :-)
They come in two editions: Explorer, which is free! and a professional edition!
This is really exciting news!
Some press releases can be found here:
The Turbotools press release
Interview with DavidI on eweek
And another one
These are pretty much economic reasons, my clients wants me to build good applications as fast as possible. This does not mean that I don't do .NET clients applications, if the situation or a client demands it then that is the good decision and I build .NET clients.
Delphi helps you to make the right decision, and whatever you choose it is always the right decision!
So suppose I choose for Native:
In the worst case scenario where Win32 will not be able to run in the future (that truly would be the end of the world ;-) ) Delphi gives me the possibility to:
Not be able to look into the future, this (and of course Delphi's great history) gives me enough confidence to take such a decision.
Of course keeping it all compatible comes with a price. It demands more resources from "DevCo". For instance the Delphi developers can't use Delphi for .NET 2.0 Developement yet. (see the roadmap)Delphi Longhorn
Release: 2008
The image of the roadmap shows a Delphi Vista (mid 2007) and a Delphi for Win64 (2008) which are not mentioned in the article itself. Delphi for Win64 however is mentioned in the release of Highlander so the roadmap image seems not to be in sync with the article?
11-06-2006 Update:
About 64 bit code generation which was stated in the article like this:
"In addition, 64 bit code generation will be added to the Delphi native code compliers to support native 64 bit development and debugging"
You could conclude that this would be in Delphi Highlander early 2007. But as I said this conflicts with the image.
John Kaster has updated the article, where it now says:
64 bit code generation will be added to the Delphi native code compilers to support native 64 bit development and debugging after the initial Highlander release.
IMO this means that it will not be in the initial release of Highlander, but it will be added shortly after the release. It also means that the image is still out of date!
MyConnection := BdpConnection.Create;
MyCommand := BdpCommand.Create(AQuery);
MyCommand.Connection := MyConnection;
try
MyConnection.Open;
MyDataReader := MyCommand.ExecuteDataReader;
while MyDataReader.Read do begin
Response.Write(MyDataReader.Item[0].ToString);
end;
finally
MyDataReader.Close;
MyCommand.Close;
MyConnection.Close;
end;
More info on BDP can be found in this BDN article Borland Data Provider 2.5 features.
Bottom line Borland DataProvider rocks, but be carefull out there...
These post have a 'fly on the wall approach' giving some insites in what is going in the Borland meeting rooms. Although it keeps us from real facts it is good to see how everything is going down there.
So far, as far as a fly can tell, it still looks very good for the future of Delphi.
David I offers some additional perspectives on the spinn-off.
After reading all this stuff I (still) feel pretty confident that Delphi will come out as a stronger product than ever before.
1. BDS2006 is awesome
In fact after two months using it, I can not think of going back to Delphi 7. The new editor features are really accelarating my production.
To name a few IDE highlights:
2. BDS2006 has some minor bugs and quirks
Before this post is looking like an advertisement for the new DevCo, let's look at some minor bugs, quirks and strange behaviors that I encountered. But beware nothing here is a showstopper.
IMO It is quite natural that a product as complex as BDS2006 has some quirks.
Disclaimer:
If I say bug I mean that I think it is a bug, so it could be my mistake after all. Still investigating some 'bugs' to put them in QA.
If I say annoying, I mean that it is annoying to me, so not necesserally to you also
These are the things that annoy's me the most. OK sometimes there is another this and another that but in general BDS2006 rocks.
3. Delphi 7 and Delphi 8 made it on the 'Uninstall list'
No need to keep Delphi 7 and 8 for downgrade anymore. Put them on the 'Uninstall list' period!
4. The future of BDS2006 is...
And then there was the announcement that Borland is spinning of the IDE business.
First thoughts after the shock:
Now after a couple of weeks I think spinning of the IDE business is the best thing to happen to Delphi in ~11 years.
What if the deal succeeds with Borland's intention to get a buyer in the best intrest of Delphi?
If that happens Delphi's future will be brighter than ever before!
What if the deal fails and someone kills Delphi?
I could use Delphi for many years to come, or change to another tool (although I can not think of another one right now, but someone will jump in the gap)
Or I just good start my gardening company with a big, I mean really big 4-wheel drive!
But for now go Delphi!
procedure LoginWithPostData(AUserName:String;
APassWord:String; LoginUrl:String; AWebBrowser:TWebBrowser);
var
varPostData, varHeader : OleVariant ;
x : variant;
postdata : string;
arPostdata : array of byte;
i,l: integer;
bch : byte;
begin
postdata := 'UserCode='+AUserName+'&PassWord='+APassWord;
SetLength(arPostdata, Length(PostData));
for i := 1 to Length(postdata) do begin
arPostdata[i-1] := Ord(postdata[i]);
end;
varPostData := arPostdata;
varHeader :=
'Content-Type: application/x-www-form-urlencoded\r\n';
AWebBrowser.Navigate(LoginUrl,EmptyParam,EmptyParam,
varPostdata, varHeader);
end;
The database is used to provide the content of the website. At first I used a SQL Server database and found out that having two text fields (memo fields) in the SELECT clause causes the text fields to be truncated to 1024 chars. This is inconvient!
[update: Problem solved, see below]
I keep a permanent link to this papers on this blog.
It seems that BDS2006 opens units, necessary for debugging, on the fly and implicit closes them when the debug session ends. (This is an editor option) If you stop debugging in such a unit Delphi keeps that unit open. Ain't that great?
I remember debugging a C# project in Visual Studio 2003 where I ended up with an endless list of tabs which is very annoying in my opinion. In VS you have the tabs for design and code besides each other on top of the editor. BDS2006 (and previous versions) have an extra tab at the bottom of the editor for switching between design and code. So in BDS2006 you always have the half amount of tabs in the top tab control compared with VS2003.
So these small features in BDS2006 are great! It gets even better if you popup the context menu on the tab. If you don't want BDS2006 to close the debugged units implicit(an editor option) you can close them by yourself using 'Close all pages opened while debugging' option. Hack you can even close all pages except the one that is active.
Small things, great stuff!
Developer and SalesMan inherit the behavior from Person. Developer and SalesMan are specializations of Person. Implementing this model in a VCL Win32 application using TDataSet would consider a lot of work. For instance the, in fact one-on-one relation must be maintained in the database. A person is either a Developer or a SalesMan, a person can not be both. (if you don't agree you should read this blogpost :-) )
Anyway implementing this becomes, even in Delphi with TDataSet, more complex. In ECO it is a very straight forward process.
Create the windows (ECO) application
Drop three datagrids(dgPerson, dgDeveloper, dgSalesMan) on the form and three ExpressionHandles (ehPerson, ehDeveloper, ehSalesMan) And oh, don't forget to compile first!
Setting the ExpressionHandles
ehPerson:
Name->'ehPerson'
Roothandle->rhRoot (Don't forget to set the Roothandles EcoSpaceType property!)
Expression->Person.AllInstances (Use the OCL Editor here)
ehDeveloper:
Name->'ehDeveloper'
Roothandle->rhRoot
Expression->Developer.AllInstances
ehSalesMan:
Name->'ehSalesMan'
Roothandle->rhRoot
Expression->SalesMan.AllInstances
Setting the datagrids
dgPerson:
DataSource->ehPerson
dgDeveloper:
DataSource->ehDeveloper
dgSalesMan:
DataSource->ehSalesMan
To make things complete drop two buttons for the Developer and SalesMan grid. Connect the roothandle property to ehDeveloper and ehSalesMan and set the for both buttons the property ECOListAction to Add.
Well this is pretty much it! You can see that the grids have all the appropiate attributes for their classes. By running the application we can test it:
Guess what: We did not code at all!
With this dialog you can add or alter parameters in a very easy way. Other 'My favourite' refactorings are:
The new and improved refactorings in BDS 2006 boost productivity, no doubt about that. This and the other editor improvements, like Live templates, made upgrading to BDS2006 worthwhile.
Set the property DataSource of the customer grid to ehCustomers. Notice that the grid shows the column name already!
ECO has some strong listactions build in to invoke operations directly on your objects. Set the property ECOListAction of the button right from the grid to 'Add'. And the Roothandle to ehCustomers.
Run the application.
OK this works. So far pretty easy, isn't it? Well now we want to see the projects of a specific customer in the other grid.
Here we need the CurrencyManagerHandle. Drop a CurrencyManagerhandle on the form and set the properties as follows:
The currencymanagerhandle will select a single instance of a customer (iow the selected customer in the grid).
To get the projects we need to drop another Expressionhandle, with the following properties set:
Connect the projectgrid to ehProjects and assign the button for the Add list action.
Run the application.
Well this was pretty much it. Set the property Autoform on the grids to true and you already have a complete working application.
Conclusion:
ECO is a new way of programming (to me it is) .The way to use it is a little different compared to the database-driven approach although the main concept is the same. Keeping the business rules (like the relation) in the model is a strong benefit for the ECO approach. This was 'my first ECO application', and it was not all that hard. One thing to remember is to Compile your application often, this is needed for the designtime support I guess, otherwise you will sometime s look for property values you need which will not be there.
This ECO adventure will be continued...
Using an image as your UIBarButtonItem in your navigationcontroller bar can only be achieved by using a common UIButton as the BarButtonItem...