Friday, December 22, 2006

Delphi: Five reasons

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:

  • Delphi supports development of native code applications. For ISVs and MicroISVs, native development is really the only choice. Such developers can’t yet assume that the .Net framework is installed on a potential customers machine, and either including the .Net Framework with your install or directing potential customers to Microsoft’s website to download the framework can make trying or using such a product too difficult. Delphi builds fast, tight, native apps with no runtime dependencies. That’s the only choice for an ISV today.
  • Delphi provides rapid application development on the Win32 platform. Given that native development is the only choice, Delphi is the only RAD tool for Win32 developers that is still being advanced and developed. Other major tool vendors have dropped all support for native RAD development Delphi, however, continues to provide you with a powerful RAD IDE and the Visual Component Library. Delphi’s Win32 tools are also continuously being updated and improved. CodeGear realizes that Win32 is and will continue to be a viable and useful development platform for years to come.
  • The VCL provides you a path to Win64, .Net and Vista. The VCL has proven to be not only powerful, but adaptable as well. Originally developed for 16-bit Windows, the VCL was easily moved to the 32-bit world. More recently, VCL has been ported to the .Net 1.1 platform and will soon be moved to the .Net 2.0 Framework. Future plans also include migrating the VCL to support the new native Vista controls and APIs as well as a version for native Win64 development. With the VCL, you have a proven development framework that will go with you if and when you decide to support these new platforms. If and when managed code becomes the norm, your Delphi code will be ready to take you there.
  • The Delphi Community is large, varied, supportive, and knowledgeable. One of the strengths of the VCL is that it is a component-based architecture. Right from the very beginning, Delphi programmers were component programmers, and right from the beginning they shared their code, whether it was in the form of freeware, shareware, or commercial offerings. The Delphi community is strong and dedicated. Once the web came into the forefront, websites providing Delphi components, technical articles, and code libraries sprung from the woodwork. The Delphi newsgroups provide free, peer-to-peer support where experts of all levels and capabilities cheerfully answer your questions of any level. There are countless free and open source component and code libraries. Delphi developers are there for each other.
  • Delphi is a proven ISV development tool. Delphi is a fully powerful and capable development tool. There isn’t any doubt that it can handle anything an ISV could throw at it. FeedDemon, FinalBuilder, BeyondCompare, the Skype Windows client, and AutomatedQA tools are all popular and widely used tools built in Delphi. These companies have realized the power and advantages of a native, RAD development tool that has a strong, supportive community and been successful building their products in Delphi.
  • Go, Go, Go, Go, CodeGear!

    Saturday, December 16, 2006

    Rehook your links, CodeGear is up!

    The CodeGear website is online! Time to redirect all the links (and there are quite a few) from Borland.com to CodeGear.com.


    My first impression of the website is that it is a very 'clean' website with clear navigation.

    Good job CodeGear!

    Friday, December 01, 2006

    Free IDE's

    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!

    Wednesday, November 22, 2006

    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)

    Sunday, November 19, 2006

    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? 

    Wednesday, November 15, 2006

    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!

    Tuesday, November 07, 2006

    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.

    Monday, November 06, 2006

    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?

    Friday, November 03, 2006

    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.

    Thursday, November 02, 2006

    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

    Thursday, September 28, 2006

    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.

    Tuesday, September 19, 2006

    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

    Monday, September 11, 2006

    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

    Tuesday, August 15, 2006

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

    Monday, August 14, 2006

    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!

    Monday, August 07, 2006

    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


    Sunday, July 16, 2006

    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.

    Tuesday, July 04, 2006

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

    Friday, June 09, 2006

    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!

    Wednesday, June 07, 2006

    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.

    Tuesday, May 23, 2006

    Code smells

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

    "Working clean means constant refactoring"

    Sunday, May 21, 2006

    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.

    Wednesday, April 12, 2006

    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.

    Sunday, April 02, 2006

    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.

    Sunday, March 26, 2006

    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.

    Friday, March 17, 2006

    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.

    Wednesday, March 08, 2006

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

    Monday, March 06, 2006

    More on "DevCo"

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

    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.

    Wednesday, March 01, 2006

    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!



    Wednesday, February 22, 2006

    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.

    Friday, February 17, 2006

    Wednesday, February 08, 2006

    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.

    Tuesday, February 07, 2006

    BDS2006, BDP and memo fields

    Lately I encountered some strange problems using the Borland Data Provider (BDP) in a ASP.NET project. At first I thought I had solved it, but eventually (mostly because of project scope changes) it made me change from BDP to OleDB.

    The project is a database-driven website for which I use BDP to connect to the database.

    Why Borland DataProvider?

    Borland DataProvider has some benefits compared to the standard .NET providers (SQL/OleDB):

    • BDP is database independent (Same components for SQL and local databases)
    • Connection pooling
    • Easy data remoting components

    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]

    Having only one text field in the SELECT works just fine! That is strange, isn't it? [No]

    In SQL Server however I could of course change one of the Text fields to a varchar with a (max) length of 4000. Not the most elegant way, I know, but it is a rather small database only holding the website content. Problem solved.
    Now, for other reasons, my customer wants to use an Access database instead. No problem! As said BDP components are database vendor independent!
    Except, of course, that varchar fields in Access are limited to 255 chars, so I ended up with two truncated memo fields. :-(

    The only solution left was to change from BDP to OleDB. This switch was easy because the BDP components are similar to the standard .NET providers.
    My project now contains two database technologies, BDP and OleDB. All works fine but I can not call it elegant. (I keep the BDP, because there might be a switch back to SQL Server in the future.)

    I only can imagine that this is a bug in the Borland Data Provider so I added a report to quality central. You can find it under QC number #24314

    Update 8-2-2006:
    Well I imagined it wrong. It seemed to be a property of the BdpConnection called BlobSize, which is default set to 1024! Well QC report withdrawn!
    Wow this one was really hard to find! :-)

    Wednesday, February 01, 2006

    Old papers, still up-to-date

    In the 'old' days I have made a few tutorials about Delphi(4/5) for The Software Developer Pages. These tutorials and papers are still available behind my company's website. They are available in english and dutch, and not updated for ages, but some papers are still up-to-date today. The most papers are at beginner-level because, guess what, I was those days a beginner.
    There is even Delphi 5 code available for download which should be working easily in BDS2006.

    The main page can be found here. (Note I do not update this anymore, so it looks a bit odd now)
    Some still up-to-date papers are:

    I keep a permanent link to this papers on this blog.

    Friday, January 27, 2006

    BDS2006 small features, great impact

    It is always amazing how small things can have such a great impact on your daily work. The new features in the BDS2006 editor like live templates are obviouos because you can see it immediately while working in the editor. 'Small' improvements and features are discovered along the path.

    Lately I noticed a tiny red bug (in dutch we call it a lieveheersbeestje) on a tab in the editor after debugging an application.

    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!

    Tuesday, January 17, 2006

    ECO Adventures: Inheritance

    Inheritance is one of the five pilars of Object Oriented Programming. In ECO inheritance is, I can tell you now, a piece of cake.
    Consider this 'real world' model:


    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:

    Notice that adding a developer or salesman automatic means adding a person. So again the model does all the hard work in the background.
    While still scratching the surface of ECO it becomes clear that ECO is very powerfull framework, taking a lot of the work load. Making this little application with TDataSets would be harder (although it can be done). For instance after inserting the Developer you would have to code to get a person in the person table.

    Guess what: We did not code at all!

    Monday, January 16, 2006

    Refactor all the way

    After using BDS 2006 for three weeks now I must say it is a real piece of art. I can not think of one reason to go back to Delphi 7. For me the most valuable new features are the improved and extended refactorings. It takes some time to get used, using them, old habbits just don't disappear that easy :-) I guess.

    What I always found a bit annoying in Delphi coding was the fact that changing the parameters of an existing method, meant a lot code cruising. OK, you can't have it all but figure this:

    In Delphi 7, to change a parameter of a method you should do something similar like this:

    1. Change the parameter in the implementation section (iow the method)
    2. Surf (Ctrl-Click) to the interface section to change the decleration
    3. Ctrl + Arrow Down to go back to the implementation

    Delphi 2006, and in specific Together, dramatically improved things. With refactoring you can now change the parameterlist of a method, and Together will take care of changing the declaration (or vica versa)!

    The 'Change Parameters' refactor dialog:


    With this dialog you can add or alter parameters in a very easy way. Other 'My favourite' refactorings are:

    • Extract method (Existed already in D2005)
    • Find unit (Helps you finding the unit for the uses clause)
    • Declare variable

    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.

    Monday, January 09, 2006

    Fooling around with TWebbrowser

    For a project I needed to edit a HTML page within a Delphi Win32 application. Delphi has a TWebbrowser component which appeared to be suitable for this situation.
    TWebbrowser in fact is a wrapper over Microsoft's Shell Doc Object and Control library (SHDOCVW.DLL) and it brings webbrowser functionality to your application. With a TWebbrowser it is easy to navigate the web and files. There are a lot resources to find on the internet, here I share some of my experiences.

    Using TWebbrowser for editing
    As said before I needed to edit a HTML webpage. You can get the Document (from the loaded webpage) with MSHTML, a library providing WYSIWYG editing for Internet Explorer and thus TWebbrowser. This HTMLDocument provides access to all the elements of a webpage, and allows you to edit the page visually.
    After adding MSHTML to your uses clause you can get the document as follows:

    Getting the document:
    HTMLDocument2Ifc := (MyWebbrowser.Document as IHTMLDocument2);

    Note that the webpage must be completed loaded otherwise the object will be nil.

    With a IHTMLDocument2 interface object we can edit the webpage. Now for this project I needed to place links absolute on the page aligned with some body background. But the first thing we need to do is setting the document in edit mode.

    Setting the document in edit mode:
    HTMLDocument2Ifc.DesignMode := 'On'; //Use 'Off' to switch desingmode off

    Setting the body background:
    (HTMLDocument2Ifc.body as IHTMLBodyElement).background := AFileName;
    HTMLDocument2Ifc.body.style.backgroundRepeat :='no-repeat';

    Setting the document for absolute positioning (2-D positioning):
    HTMLDocument2Ifc.execCommand('2D-Position', false,true);


    Now we can drag the links (wrapped by a span) around on the webpage.

    With the execCommand method you can easily do a lot of editing on selected text in the document. To name a few:


    HTMLDocument2Ifc.execCommand('Bold', false,0);
    HTMLDocument2Ifc.execCommand('Italic', false,0);

    HTMLDocument2Ifc.execCommand('FontSize', false, 4); //Set the font size of selected text
    HTMLDocument2Ifc.execCommand('InsertImage', true,0); //Use default insert image dialog


    There is a lot more, check microsoft MSHTML site for everything.

    Another feature of the HTMLDocument2 is that you can get collections of images, links and styles of the webpage. For example you could get all the picture sources as follows:

    for i := 0 to HTMLDocument2Ifc.images.length -1 do
    begin

    Item := HTMLDocument2Ifc.images.item(i, null) as Ihtmlelement;
    lbItems.AddItem(Item.getAttribute('src',0) + ' [A Picture]', nil);
    end;


    Well there is a lot more to explore, but it is easier then you might think at forehand. Here are some links with more resources, to fool around with, on TWebbrowser:

    Microsoft MSHTML site
    Webbrowser to the max (about.delphi.com)
    Brian Cryer TWebbrowser page
    MSHTML Editier modus German site with examples.
    WebSVN Code examples.


    Tuesday, January 03, 2006

    ECO Adventures: Master-Detail

    I finally have the time to play with ECO and learn about what it is.
    In this episode of 'The ECO adventures' I create a Master-Detail model.

    In VCL it is very easy to create a master-detail relationship between two datasets (TDataSets) using the mastersource property. In ADO.NET you can make such relations within the .net dataset, but implementing them is a bit different compared with the TDataSet.
    In ECO, it is again relative easy to implement.

    Making the model
    Take this model, where we have Customers and Projects. This two objects has a relation, where a customer has zero or more projects, and a project belongs, of course, to one customer.
    In ECO we can model it like this:



    Take an extra look at the /Project attribuut. This is a derived attribuut, in this case showing the projectnumber (an integer) and the description in one field.
    This can be done by OCL. The expression for this one is:

    self.Number.asString + '-' + self.description

    You can easily create this with the OCL expression editor.

    I have created this model in a ECO Package, so that it can be used in multiple client applications. (Winform and ASP.NET)

    Making the Winform Application
    Just add a ECO Winform Application to your projectgroup with the ECO package and make a project reference to the ECO dll. In this case it is the MasterDetail.dll.
    After setting the reference, you must select the package in the ECO space of the Winform application, to let the application know that it can use the package.

    After that you must first recompile for further designtime support.

    Now we can create the GUI. The form has standard a few ECO components, with among others the rhRoot, wich connects the form to the ECO space. (The reference to the model)
    Select the ECO space in the ECOSpaceType property of the rhRoot.

    Connecting to the object instances of our classes (Customers and Projects) we use ExpressionHandles, which are connected to the model through the roothandle (rhRoot).

    To get the project details, we have to use a CurrencyManagerHandle, which has the grid (in general a GUI control) with Customers as the BindingContext. Through this handle we connect to projects of a specific Customer. (This is like the CurrencyManager in ADO.NET)

    So let's make this GUI:





    Create a new expressionhandler and call this ehCustomers.
    Set properties as below:
    • Roothandle -> rhRoot
    • Expression -> Customer.AllInstances (Use the OCL editor for this by invoking it with the ... button)

    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:

    • Name -> cmCustomer
    • RootHandle -> ehCustomers
    • BindingContext -> CustomerDataGrid

    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:

    • Name -> ehProjects
    • RootHandle -> cmCustomer (yes the CurrencyManagerHandler...)
    • Expression -> self.Projects (To select in the OCL editor through the Roles node)

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