Office 2007 GUI License

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)

Third party components

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:

1. Standardize your development. Use prefererd components for specific tasks. (For example try to use, as default, one componentset for all your GUI work. Don't mix them if not necessary)
2. Use only components if they come with source code. This eliminates your dependency. (A positive side effect is that you can learn a lot from the source code)
3. Buy 'long term licenses' like SA or subscriptions, so that you get updates for your components.

Our 3-rd-party favorites are:

1. Devexpress VCL Components. This set is our default for GUI work.
2. TMS Software Components. Besides a large component set, they have a few specific components for scripting and instrumentation.
3. ReportBuilder from Digital-Metaphors. An outstanding reporting solution with an awesome end-user solution, right out of the box.
4. AVLock Gold, a share ware component that helps you to turn your application into a trial version with only a few lines of code.

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? 

CodeGear := Borland as DeveloperToolGroup;

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!

Microsoft urges Delphi developers to .NET #2

Looks like a battle is beginning all over again.

Here Tim Anderson's report from the Tech-Ed session.

Microsoft urges Delphi developers to .NET

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.

How to persist a TPersistent?

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?

Two weeks of Delphi

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.

The bug by accident #2

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

The bug by accident

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

Do the Delphi Survey

Let your voice be heard, do the Delphi survey.

Turbo Command line compiler available

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.

It's hot out there

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

Go Turbo

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

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.