Blogpost from Windows Live Writer

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 :-)

Turbo pricing

According some webshops here in the Netherlands, the Turbo professional editions will cost EUR 399,00! (That is excl. 19% VAT so: EUR 474,80 incl. VAT ).
The academic version costs : EUR 82,00 (incl. VAT).

I think these are very reasonable prices for a product with no less features as the BDS professional edition.
Note that you can only install one Turbo per PC.

The free Explorer edition is also available on CD for a lousy EUR 25,00!

Delphi man returns with Turbo Man

And how....Devco's answer on Microsoft Visual Studio Express.


They are back...the Turbo Tools, powered by Turbo Man!
More adventures can be found in the Borland museum.

Devco is reintroducing the Turbo tools. According the website www.turboexplorer.com there will be four of them:

1. Turbo Delphi Win32
2. Turbo Delphi for .NET
3. Turbo C#
4. Turbo C++

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

Native vs. .Net - My stake on it

My stake on Nick Hodges (the new Delphi Product Manager) blogpost Battle of the Heavyweights: Native vs. .Net.

If you want to build a .Net client -- you can do that with our tool. If you want to build a native client with an eye towards moving to .Net on your timeframe, then we let you do that. It's up to you to decide. We don't want to make that decision for you.

This shows the real power of Delphi. Where other tool vendors 'force' you to learn and build your applications with new technologys, keeping your exsisting code as legacy, Delphi keeps your existing code as much as possible available, and compatible, for the technologies of the future.
They have proved many times now that they can do that, and I'm sure they will, and can do that in the future. (Win16-Win32-Kylix-.NET)
In the 'every day' job this means that a decision between technologies like Native and .Net are not that important for a Delphi developer. I mean they are important, and have to be taken carefully, but whatever the outcome of the decision might be, the chance that it is the right decision increases dramatically compared to other other tools. (In some other tools you don't have choice)
By using good program skills, like seperating your GUI from you business logic, it can increase even more.
As an independent software vendor, building tools on customer specifications, that decision is either made by my client, or by me. If I have to make that decision (hack most customers even don't know what .NET is), I might choose for Win32 native clients, because of:

1. 10 year or even more VCL Experience
2. I still can build a Win32 client faster with standard VCL and Thirdparty components like Developer Express then using .NET's winforms

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:

1. Make a pure .NET application where I could use all my business logic units instantly and I only have to remake the GUI in whatever it is called by then. (Fortunately I have been able to built up my .NET experience even more by now, so that should not be a problem)
2. Migrate to a VCL.NET application which would be, in the best scenario, painless if all the (third party) components I use would support that.

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)
For me personally it is an overcoming problem, but I can imagine that for somebody else, building applications on client specifications, this might be a problem. If a client now demands .NET 2.0 Delphi is obviously not the choice. (and that would be a pitty, wouldn't it?)
I think this is one of the issues "devco" should work on: "keeping the timeframes as narrow as possible"

So Native vs .NET is no war for a Delphi developer, it is more a smooth evolution.

Just my 2 cents.

.NET 2.0 for Delphi programmers - Book review

Last week I received my copy of ".NET 2.0 for Delphi programmers" by Jon Shemitz. The marketplace is not flooded with Delphi books, so every new book is intresting in it self. This book attracted my attention because of the .NET 2.0 part of the title.
The book is mainly about .NET and C# and what is in it for Delphi developers.

"Your Delphi experience makes .NET easy to learn"

The first part of the book gives an introduction to the .NET technologies like CIL and Managed Code, and how this is implemented/different from native Delphi. There are a lot examples in C# and Delphi to illustrate the different technologies.
Besides chapters dedicated to Delphi for .NET there are also chapters that are dedicated to C#. The last part of the book is about the Framework Class Library (FCL). The FCL is described in great detail.

"..learning the FCL is your ticket to learn once, work anywhere freedom."

This book shows both the real power of .NET and Delphi. We Delphi guys may consider ourself lucky because the Delphi language and C# are so remarkable alike.

IMO this book is a must read for Delphi programmers, even if you don't do .NET that much (yet), it gives great information for both sides of the fence.
It makes the complex things easy to understand to give you immediately knowledge of the material, even if you don't understand all the details yet.

I consider this book a tribute to Delphi!

Delphi roadmap update

Borland's Developer Tools Group has published updated roadmaps for JBuilder and Delphi/C++.

Upcoming Delphi versions according the roadmap:

Delphi Highlander
Release: Early 2007

• -Support for .NET 2.0
• -Additional refactorings and unit testing
• -Delphi .NET support for generic types, partial classes, and nullable types
• -VCL for .NET 2.0
• -ECO for .NET 2.0
• -Seamless project conversion to .NET 2.0.
• -IDE design surfaces for .NET Compact Frameworks (using VCL.NET on CF)
• -64 bit .NET apps written using WinForms and VCL.NET
• -64 bit code generation will be added to the Delphi native code compliers to support native 64 bit development and debugging. (See update belowe)
• -IDE and VCL runtimes to support Unicode.

Delphi Longhorn
Release: 2008

• -VCL for Avalon
• -Indigo

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!

Putting the act to the word

Just before the creation of DevCo I feel it is time to boost Delphi once again. Because, you know what, it still is the best development tool out there for Win32 and .NET development. (And a lot more...)
Although the blogging community is fresh and kicking, a lot of, long time existing, Delphi sites looks to me unattended and out of date. (Not all of course)
Just like a dutch Delphi portal site, delphi.startkabel.nl that I found recently. This site had a thick layer of dust on top of it with broken links and links directing to non Delphi sites or out-of-date data. In my opinion sites like this are very important for the succes of Delphi.

So putting the act to the word (a translated dutch saying I am not sure if this make sense in Englisch) I decided to become the webmaster of this portal. I have done a bit of cleaning like removing the broken links and putting in some new sections like Weblogs, ECO and AJAX. Right now I am still gathering new links and sections.
If you have any link/section suggestion please let me know here and I will add it to the portal.

Code smells

Great article on coding rules on Coding horror blog.
Bottom line: Keep refactoring your code.

"Working clean means constant refactoring"

Saving TWebbrowser content with IPersistFile

With TWebbrowser it is easy to navigate URL's and files on your local disk using the Navigate method.
As discussed in this blogpost TWebbrowser implements a IHTMLDocument2 interface object which can be used to edit the document in WYSIWYG way.

Saving the changes can be done in a few different ways, I will discuss a few here below:

1. Using the innerHTML property
You could retreive the raw HTML from the browser through the WebBrowser.OleObject.Document.documentElement.innerHTML property and then save it to disk.
If you want only the text from the document, and not the HTML, you could use the WebBrowser.OleObject.Document.documentElement.innerText method.
Saving to disk could be easily done using a TStringList object.

2. Through the IPersistFile interface
Although the above method works, there is a much more elegant way to achieve this.
IHTMLDocument implements an interface called IPersistFile which is an common interface for loading and saving objects.
Save the current loaded webpage using the IPersistFiles as follows:

(WebBrowser.Document as IPersistFile).Save('c:\inetpub\wwwroot\MyWebsite\index.html', True);

Besides Save, IPersistFile offers a method for loading files (Load) and a method to find out if the current loaded page is changed compared to when it was last saved. (IsDirty)

For more information on IPersistFile visit the msdn website here.
According this page IPersistFile is new in the .NET Framework 2.0.

Devco's former employee shortlist

Allen Bauer talks about the returning of former Borland employee Steve Shaughnessy in his blogpost Gaining momentum...
The return of a former employee itself is not really news to me, those things happens daily in the real world. The intresting news in this blogpost is when Allen talks about a "short list", he says:

After the announcement that Borland was going to spin-off the IDE and database groups into a separate company, we started talking with several former Borland employees that had left to pursue other opportunities. Steve Shaughnessy quickly made it onto our “short list.”

In other words there is a shortlist out there, with former Borland employees on it which are in contact with the Devco's about other opportunities.

That is very good news, IMO!

Now I wonder who would be on that shortlist?
So this blogpost might have some serious points after all. ;-)

Any way encouraging stuff.

ECO missing gallery items fix

BDS2006 Enterprise edition is missing some gallery items (New - Other) regarding to ECO applications. It misses for example the ''ECO ASP.NET Web Application".

A fix (By Jesper Hogstrom) can be downloaded here.

I just thought I let you know this because it took me a while to find it and there is know easy workaround, except by starting a normal ASP.NET application and adding the 'standard'ECO stuff manually.

Programming the Pocket PC the easy way

While we are waiting for Delphi to support CF development officially, I found a year ago a very easy to use Form Designer application for 'programming' applications for Pocket PC's.
GrandaSoft's XSDesigner was at that time able to produce data collection forms (as they call it) in a very easy straight forwarded way which reminded me to the first 'Wows' after seeing Delphi 1 and it's way to deal with databases. :-)
XSDesigner let's you design database forms which save their data in a Pocket Access database (CDB format) . On the PDA you must install, a sort of runtime, XSForms which you can use to load your forms. One thing that was missing at that time was that you could not program button clicks and events.

Their new release (codename Matador), which is at this moment a public beta, supports now scripting languages to program logic in your applications. They support (for now) VBScript and JScript as languages and an event model. The way it is implemented is amazingly simple, but oh so effective.
Just design your form, script your logic, run it with one click on your Pocket PC, and it all works like magic!. The database is generated automaticly and data can be exported to several formats like XML and HTML.

Conclusion:
Although, it is limited to database forms, and it is limited, in its way, to work with complex datastructures, I find it extremely powerfull and recommend every one intresting in PDA development to give it try. According to their website there will be a free personal version and a professional edition with more features.

Update Delphi Roadmap

According to Daniel Wischnewski blogpost the Delphi roadmap has been updated. (14-03)
You can find it here.

Obvious changes to the previous roadmap are:

• Release date of Highlander seems to be pushed to the end of 2006/early 2007 instead of mid 2006
• ECO IV for VCL.NET suported by Highlander
• Windows Vista seems to be supported by Highlander.

Nick for president...euh DevCo CEO

http://www.lemanix.com/nickblog/CommentView,guid,16a11d72-e872-4928-86b6-cf470e183149.aspx

Speaks for itself, great idea's!

BDP, be carefull out there!

When you need database connection in a ASP.NET website you will use, of course, Borland DataProvider, because it gives you a database independent connection.
Use of the BDP components is very straight forwarded, and very much alike the 'standard' ADO.NET components.

However some things of BDP are a bit different, in the detail sence of the word, that it can make you pull your hair from your head sometimes. BDP also covers a lot that is not in ADO.NET so there is plenty to learn also.

Today such an event occured to me (again). A database-driven website that I'm building uses an Microsoft Access database to hold the content(Yes I know, not the best choice) . I use BDP to get the content from the database and on a local machine a Delphi Win32 app is used to maintain the content. So if the content changes the database must be uploaded to the website.
I noticed during developing that the Access .lck file (LockFile) stayed open, and that of course could be a connection which was not closed properly.
But I learned from the Delphi 8 times to close everything you use to get data from the database.
My way of doing this is somewhat like this:

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;

So believe me I don't leave database connections open lately. Anyway the lock file did not give trouble during the developement.
But now that the website has gone live my Win32 app is not able to upload a changed database because it is used by another process. And that of course is the ASP Worker process, which I can not kill at the ISP's webserver. (Oh Oh)

So after checking all my connections to close(as I told you before I do close them) I found out that it had to do with the Connection Pooling. Of course, that is default set to true and it keeps the connection 'open'. So I turned of the Connection Pooling and everything went fine even the .lck file disappeared immediately after the first refresh.
Now I only need to find a way to free the connection just-before uploading the database. I think that can easily be done following this tutorial at BDN.

So here is my small(and growing?) list of BDP tips:

1. When using Memo fields don't forget that BDP returns by default 1024 characters as set in the property BlobSize of the connection. So if you have more you won't see it until you increase the blobsize.
2. Don't get yourself fooled by the Connection Pooling! Connection pooling makes it look like you did not close your connection properly.
3. Close all that can be closed and you will be fine.

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...

More on "DevCo"

Allan Bauer has some intresting blogposts in his xx Days After spinn off announcement series:

• 16 days after..
• 23 days after..
• 42 days after.. (My Guess ;-) )

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.

BDS2006 evaluate and a four wheel drive

I am using BDS2006 for two months now. Time to evaluate.
I use BDS2006 Enterprise, mostly for Win32 developement and ASP.NET Development. (Delphi .NET and some C#)

BDS2006 in a nutshell:

1. BDS2006 is awesome
2. BDS2006 has some minor bugs or quirks (no showstoppers here!)
3. Delphi 7 and Delphi 8 made it on the 'Uninstall list'
4. The future of BDS2006 is...or get myself a fourwheel drive.

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:

• Live Templates; Great productivity accelarator!
• Refactoring; Even more productive. (Still have not used all the refactorings)
• Together integration; The two way source/UML diagramming gives good insight of my code. Automatic generating documentation is sweet.
• The IDE is fast (PIV 2,4 GHz 512 Mb); Start uptime is OK! Working is OK!
• The IDE is stable. (Must confess I manage to crash it sometimes, although a lot fewer then Delphi 7).
• ASP.NET designer is perfect (Awesome with a capital A compared with the Delphi 8 version that I used. No more HTML disappearing.)
• ECO, although I am still exploring the thing, it seems to be the way to build .NET applications in the future. (No more plumbing around with ADO.NET, can you imagine that?) Now if I only had the time to explore it even more. There should be a book for this...
• Having Win32 and .NET application in one project group is cool and even better extremely usefull, no more switching between applications.

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

• Annoying: The projectmanager does not open your dfm file if you don't open the pas file first.
• Annoying: The help is minimal. The help really needs attention.
• Bug: Sometimes I manage to crash the thing. (When I say 'sometimes' I mean once/twice a day, but not every day) mostly when debugging. (Hard to locate although)
• Annoying: It is hard to stop coding.
• Annoying: Can not get the ASP.NET deployment option to work. Grrrr must be me I guess.
• Annoying/bug: After a day working in a ASP.NET application the amount of memory has grown. (After killing the ASP.NET worker process it comes down)

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:

• WTF are they doing now????
• There we go again...
• Men I just bought me a Enterprise Edition for the first time in my life....

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!

Posting data with TWebbrower

With a TWebbrowser component it is possible to post data to a webpage. Suppose you have an application with a webbrowser and your application requires a login, and the website also uses a login. The user should now login twice. And that is just to much!

You can however post data to the website with the Navigate method of the webbrowser component.
The declaration of the method is as follows:

procedure Navigate(const URL: WideString; var Flags: OleVariant;
var TargetFrameName: OleVariant;
var PostData: OleVariant); overload;

The last parameter PostData can be used to transfer the login information to the webpage, as if the user pressed the login button of the login form.

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;

Step 1: Create a string with the postdata
Step 2: Fill an array of byte with the string characters.
Step 3: Assign the array to an OleVariant.
Step 4: Set the appropriate encoding to a OleVariant (varHeader)
Step 5: Navigate the browser.

You should be logged in now!

You could of course also do it the other way around, log in the webbrowser and read the postdata from the BeforeNavigate event. (Just posted by your user and on its way to the webserver)
The disadvantage with this method is that you should parse the postdata string to get the username and you should somehow find out if the user was autorised by the webpage. One way to achieve it is to check the url in the NavigateComplete event of the browser to be the protected url (Page). If the protected page is loaded the user should be logged in and you can then login your application.
The first method, posting the data to the webserver from your application is however the best one.

BDS2006 Architect trial is available

According to John Kaster's post in the non-tech newsgroup the BDS2006 Architect trial is available at http://www.borland.com/downloads/download_delphi.html.

Go get it!

Update:
There is also a nice demo presented by David I!

Borland Announces Plan to Divest IDE Product Lines

Read the press release here.

In summary I read it like this:
Borland is seeking a buyer to create a separate company where all the IDE stuff related products will be placed. (Delphi, C#, C++ etc) This company will stay strong related to Borland who will focus on ALM and SDO.

David I has posted an open letter to the non-technical newsgroup, read it here.
There is also a blogpost here.

As far as I can see this could be a good thing for Delphi (BDS2006) although it is also quite shocking to begin with.
I only think that the name Borland should be for the IDE company, let the ALM company come up with a new name. Borland and Development Tools is said in one breath.