The Doric Temple

The Delphi Overflow Doc Wiki Initiative

noreply@blogger.com (Babnik) — Mon, 29 Mar 2010 23:12:00 +0000

A couple of days ago, I was reading Jim Mckeeth’s blog post about setting up a Delphi documentation wiki. Now while I admire Jim’s drive and determination about anything Delphi, and I like his idea, there’s one sentence I don’t agree with.

”At first I was thinking Embarcadero could hire a tech writer to copy edit the content from the questions into the Wiki, but that is just passing the buck.”

Any why shouldn’t Embarcadero properly document their own product? They are the ones making money from Delphi, aren’t they? I’m all for community input, but that shouldn’t let Embarcadero shirk their responsibilities. I guess Jim, like many others has just given up ever getting decent documentation, and taken matters into his own hands.

Hand’s up those who have given up on the F1 key when working in the Delphi IDE?

Silverlight back from the dead.

noreply@blogger.com (Babnik) — Sun, 21 Mar 2010 00:08:00 +0000

Microsoft have probably just saved Silverlight. Their recent announcement of the Windows Phone 7 Series, and more importantly the development platform for that phone (Silverlight of course) means Silverlight is important now. I was always pretty sure WPF would become the defacto standard for desktop applications (and what with Visual Studio now being written in WPF, perhaps it will), but I couldn’t quite see a compelling reason behind Silverlight. Now there is one!

Have Embarcadero backed the wrong horse (again…)? They’re targeting the MAC with their next compiler. Probably because they think that is where the future is. Perhaps the future is with Seattle and not Cupertino!

They have Delphi Prism of course, and you can develop for Windows Phone using that. Having said that, no one has ever answered my question? Why should I use Delphi Prism and not C#? Now before I get a 1000 comments telling me that Pascal is easier to read than C#, I just want to say I agree. I love Prism! I wish I could use it every day. It’s awesome. Can I praise it anymore? I need a reason to use it though. One I can go to my boss with. I’d like to be able to go to him and say, “you know that project we were about to develop in C# (the one we decided to NOT use Delphi native Win32 for!), well I think we should use Delphi Prism because….”

If anyone can complete that sentence for me, I’d love to be able to use it. I wish Microsoft had approached Remobjects and partnered with them rather than Embarcadero. The only way my boss would agree to Delphi Prism would be if it sat along side C# and VB.NET in the default install of Visual Studio. That wouldn’t guarantee anything, but I’m sure the added exposure would garner quite a few new followers.

More Attributes

noreply@blogger.com (Babnik) — Sat, 06 Mar 2010 17:08:00 +0000

Just got a comment from Mason Wheeler, that he prefers to use attributes to indicate a property to NOT serialise , rather than those properties to serialise. I quite like this idea, as it’s true that if you have quite a few properties to serialise, your class may get rather messy. My only problem with this is that the property name must then be the same as the column name. I guess not a major problem, but still. In a perfect world, you’d have two types of attributes. Those which came before properties, methods or fields and those which came after. Those which came before would work just like the class visibility sections. i.e. they apply to all properties, methods and fields until the next attribute, or section. Those attributes that came after a property, method or field, apply to that item only. thus I could write something like this.

public
  [Persist]
  property Id : Int64;[Key][ColName('Id')];
  property FirstName : string read fname;[ColName('Name')];
  property Surname : string read fSurname;
  property Address : string read fAddress;
public
  property FullName : string; //not persisted

I’m not sure how difficult that would have been to parse.

Attributes

noreply@blogger.com (Babnik) — Sat, 06 Mar 2010 13:05:00 +0000

Last time, I demonstrated how I would like to decorate my class using attributes to declare the table and column names I eventually will use to persist the class. Here are the the declarations of the two attributes I used.

PersistentClassAttribute = class sealed(TCustomAttribute)
  strict private
    fTableName : string;
  public
    constructor Create(const aTableName : string);
    property TableName : string read fTableName;
  end;

PersistentPropertyAttribute = class sealed(TCustomAttribute)
  strict private
    fColumnName : string;
    fKey : Boolean;
  public
    constructor Create(const aColumnName : string; aKey : Boolean = False);
    property ColumnName : string read fColumnName;
    property Key : Boolean read fKey;
  end;

Both fairly simple. The important things to not is that both inherit from TCustomAttribute, and their constructors dictate the way I will use them. I’m not going to bother showing the implementation of either of these classes. Both are very similar, in that the parameters passed to the constructors are stored in the corresponding private fields.

Now we’ve got our attributes set up, and our class has been duly decorated. How do we access that information? Well, you’ll notice that the class which we wish to persist inherits from TPersistable. This class will take care of getting the information we need from the attributes. Let’s start with the class map information.

We’ll create a class procedure on TPersistable to load our classmap.

var
  ctx : TRttiContext;
  t : TRttiType;
  p : TRttiProperty;
  a : TCustomAttribute;
begin
  ctx := TRttiContext.Create;
  t := ctx.GetType(Self);
  for a in t.GetAttributes do
    if a is PersistentClassAttribute then
    begin
      fTableName := PersistentClassAttribute(a).TableName;
      Break;
    end;

Anyone who has seen any code associated with the new RTTI functionality will be familiar with this code. We use the RTTIContext to get to the class information. We iterate over all the attributes on the class until we get to the PersistentClassAttribute. We could do this every time we needed the class map information, but we’re going to do this once, and then cache the information. The next step would be to get the list of properties which we want to persist. We’ll add a few more lines to the procedure above.

class procedure TPersistable.LoadClassmap;
var
  ctx : TRttiContext;
  t : TRttiType;
  p : TRttiProperty;
  a : TCustomAttribute;
  Prop : IPropertyMap;
begin
  ctx := TRttiContext.Create;
  t := ctx.GetType(Self);
  for a in t.GetAttributes do
    if a is PersistentClassAttribute then
    begin
      fTableName := PersistentClassAttribute(a).TableName;
      Break;
    end;

  for p in t.GetProperties do
    for a in p.GetAttributes do
      if (a is PersistentPropertyAttribute) then
      begin
        if not fPropertyList.ContainsKey(UpperCase(PersistentPropertyAttribute(a).ColumnName)) then
        begin
          Prop := TPropertyMap.Create(PersistentPropertyAttribute(a).ColumnName, P.PropertyType.TypeKind);
          fPropertyList.Add(UpperCase(Prop.ColumnName), Prop);
        end;
      end;
end;

We’re doing exactly the same thing as before, except this time we’re iterating over the properties of the class, and checking the attributes of each property. If that attribute happens to be out PersistentAttributeProperty, we create a TPropertyMap class and add it to our list of properties. Once this class procedure has been executed, we now have a cache of information about our class and how we should go about persisting it. we could add a few class functions to help us access that information.

 class function PropertyMap(const aName : string) : IPropertyMap;
 class function TableName : string;
 ...
 ...
class function TPersistable.PropertyMap(const aName: string): IPropertyMap;
begin
  fPropertyList.TryGetValue(UpperCase(aName), Result);
end;
...
...
class function TPersistable.TableName: String;
begin
  Result := fTableName;
end;

We’re still a long way from persisting our objects, but we now have all the information we need. When I do implement the actual persistence, I’ll make sure it is extremely easy to change from persisting to SQL Server or to a simple XML file.

On ORMs

noreply@blogger.com (Babnik) — Fri, 05 Mar 2010 23:13:00 +0000

I’ve always had a soft spot for ORMs (Object Relational Mappers). Whilst opinion is divided on their use, I just love them. I’ve actually written a few, because I’ve never found exactly the right one for me. Currently in the Delphi world, there are a few open source ones, and some commercial ones, but all seem to have been started pre Delphi 2010. Which means they don’t support Attributes and the new RTTI. When I first saw Attributes in Delphi 2010, I thought ORM immediately. All the ORMs I’ve used or written (in Delphi at least) store their mapping information separate to the actual class that needs to be stored. One I used, stored the information in an XML file, which was read, and parsed on start up to produce a class map. So I thought, how would I do it with Attributes.

  [PersistentClass('TestObject')]
  TTestObject = class(TPersistable)
  strict private
    fName : string;
    function GetName: string;
    procedure SetName(const Value: string);
  public
    [PersistentProperty('IdCol', True)]
    property Id;
    [PersistentProperty('NameColumn')]
    property Name : string read GetName write SetName;
  end;

At it’s simplest, I have one attribute for the class, and another for each property I wish to persist. The PersistentClassAttribute, takes the table name, whilst the PersistentPropertyAttribute takes the column name and whether the column is a primary key. What I’m hoping for is if I try and save an object of type TTestObject I get the following SQL for my relational database.

INSERT INTO TestObject(IdCol, NameColumn) VALUES(2, 'Steve')

And if I try and load and object, by writing MyObject.Load(2), I’ll get SQL similar to the following.

SELECT IdCol, NameColumn FROM TestObject WHERE Id=2

Next time I’ll demonstrate how I use those attributes to create a class map

The Ribbon Control Update

noreply@blogger.com (Babnik) — Fri, 22 Jan 2010 18:55:00 +0000

A little update to my previous post. Most of the problems I have encountered can easily be fixed by viewing the form as text, and then going back to the visual form. It’s almost usable. Still a pity though.

The Ribbon Control

noreply@blogger.com (Babnik) — Fri, 22 Jan 2010 13:54:00 +0000

Now I’m not a major fan of Microsoft’s ribbon control, and our clients have for the most part stuck with Windows XP, and Office 2003, so there has been no real call for it in our applications. However, with the advent of Windows 7, we are getting more and more calls for our application to look more like a Windows 7 and more specifically an Office 2007+ application.

To that end I have been experimenting with the ribbon control in Delphi 2010. And my am I frustrated. This is the buggiest component I have ever used out of the (Delphi) box. I add ribbon groups that disappear (I have found a workaround, by opening the form as a text file and back to form again) Icons initially appeared non-transparent, then started working. Sometimes actions would not have a caption. I’d delete the group, re-add the action, and the caption magically appears. It just seems so fragile. Has anyone actually managed to get anything but a hello world application, using a ribbon control, to actually work. and more importantly, not go nuts in the process.

This is why I protest so loudly at the Delphi pricing. Delphi 2009, touted the ribbon control and generics as two of it’s major plus points. Generics were barely useable until update 3, and then abandoned in Delphi 2009, with new fixes going in Delphi 2010. The ribbon control, I assume, was just as bad in Delphi 2009 as it is in Delphi 2010, if not worse.

Stop releasing new versions every 5 minutes, and fix the outstanding problems. Why should I have to get Delphi 2010 to fix the generics I paid for in Delphi 2009? Why should I now have to find a third-party ribbon control to fix what I paid for in Delphi 2010?

Upgrading to Delphi 2010

noreply@blogger.com (Babnik) — Thu, 21 Jan 2010 12:58:00 +0000

While the next major release of the application I work on will no doubt be written in C# (unless we get a 64-bit Delphi, then I have something to argue my case with), for the short-term, we will continue using Delphi. To that end, I like to keep up with the latest version (not always sure that’s a good idea, but anyway) so we recently got a copy of Delphi 2010 to see how easy the upgrade would be.

Not so long ago, I moved from Delphi 2006 to Delphi 2009, so I thought this upgrade would be a walk in the park. There should be no breaking changes. I would need to change a few defines, but that’s about it. And initially that was the case. In no time at all, I had upgraded our third-party components, made the necessary changes to include the new compiler version (more about that in a later post perhaps), and I had the whole thing building in no time. I ran it and disaster. Well it seemed like a disaster. All the fonts of all the menus, both the main menu and all popups were both the wrong font, very large (some the size of the monitor) and skewed. I checked the components in question, and yes the font property was basically garbage. I checked the DFM file, and everything was correct.

Now I have to add that we use some old DevExpress components for our menus. We never upgraded them as they did a complete rewrite of their grid component at the same time, and we had too much invested in the old one. Anyway, we have faithfully updated the source as and when needed. The unicode changes were perhaps the biggest challenge, but not too difficult. Now this! What was wrong?

Something was changing the font. I delved into the source for the components, and zeroed in on the following few lines.

var
  NonClientMetrics: TNonClientMetrics;
begin
  NonClientMetrics.cbSize := SizeOf(TNonClientMetrics);
  SystemParametersInfo(SPI_GETNONCLIENTMETRICS, 0, @NonClientMetrics, 0);
  Font.Handle := CreateFontIndirect(NonClientMetrics.lfMenuFont);
  ...

Now this code hasn’t changed since we compiled it with Delphi 2009, so I delved into windows.pas, and found the record that TNonClientMetrics ultimately points to tagNONCLIENTMETRICSW and down at the end, the following line.

iPaddedBorderWidth: Integer; //Requires Windows Vista or Later

Aha, I’m working on Windows XP. I checked the same record in Delphi 2009, and that line was missing. So sizeof was returning 4 bytes extra in Delphi 2010 than it did in Delphi 2009. I confirmed this by trying the following

NonClientMetrics.cbSize := SizeOf(TNonClientMetrics) - SizeOf(NonClientMetrics.iPaddedBorderWidth);

Yes, everything back to normal. Obviously, the code should check for windows version and return the size accordingly, but some kind soul has done that work for me, and added a static method, sizeof, to the record. So the code becomes

NonClientMetrics.cbSize := TNonClientMetrics.SizeOf;

The sizeof static method checks windows version and adds or removes the extra 4 bytes accordingly. I hate breaking changes like these, but whose fault was it. Delphi 2010 or Microsoft?

C# Native Compiler

noreply@blogger.com (Babnik) — Sat, 16 Jan 2010 23:41:00 +0000

I was wondering the other day about all the (failed) attempts by Borland/Inprise/Borland/Codegear/Embarcadero (that list there says a lot just by itself) at diversifying their native Delphi compiler. You had Kylix (Delphi for Linux), Delphi for .NET, and C# Builder. All of them not really what you would call successful. Now they are working on a cross-platform compiler, which will be the next version of Delphi. (I still don’t get why they think this is more urgent that a 64-bit compiler)

Has anyone ever contemplated a native C# compiler? I don’t mean something that could take existing C# projects and compile them for Win32. Delphi for .NET showed that the two platforms are just too different for that to ever work in either direction. No, what I’m thinking about is a C# native compiler built on the VCL and the Delphi IDE. I think we all agree that there is a place for native development. There’s a load of C# developers out there though, who would never contemplate Delphi, but if they needed to write some native code, they would certainly look at a C# native compiler.

If that worked, it would definitely save Delphi. As long as the VCL was alive, and you had the same kind of compatibility you now have between C++ builder and Delphi, then Delphi would be back in the limelight.

Just a thought.

Delphi is Dying

noreply@blogger.com (Babnik) — Fri, 15 Jan 2010 09:17:00 +0000

Don’t you just hate those Delphi is Dying blog posts? I do? We have been bombarded by messages of doom since about Delphi 4. “Delphi is dying” they scream. “No it’s not”, we counter. “It’s alive and kicking”.

The problem is, I think they finally may just be right. Now I’m a big fan of Delphi, I have been since Delphi 1 (and if you count Turbo Pascal, then a lot longer still), but if I’m beginning to despair, then what hope is there? It’s got absolutely nothing to do with what other people are saying. It’s just a feeling I get from trawling the internet every day looking for Delphi related stuff. There used to be a time when you needed something, you googled it (probably, yahooed it in those days), and you’d get tonnes of hits with sample code, downloads and documentation galore. What do you get now? Almost exclusively you get abandon-ware. Code that hasn’t been updated from Delphi 6 or 7. Half finished components with no, or poor documentation. I guess this didn’t happen over night, but up until Delphi 2009, you’d find some Delphi 5 code, compile it (in say Delphi 2006), and you’re off. Now, with the unicode changes in Delphi 2009, you invariably have to work hard to get any code to compile and work properly. Rather than moan about it, I should perhaps give back to these open source projects, and post my changes somewhere, but to be honest, a lot of the code is so half baked, that it’s just not worth it. You need to not only fix the unicode problems, but do a whole lot more to make anything worthwhile.

No doubt, I’ll get a few comments regarding how great Delphi 2010 is, and I won’t disagree. This post is not about how good or bad the IDE is. You can do anything with Delphi today. Sure it has some deficiencies, but what language/platform doesn’t? On the whole though, you can produce fast, compact and useful applications with Delphi. But that’s not the point. The point is that developers are abandoning it in droves. I have no scientific data to prove or disprove that statement, but I do have a feeling. It’s beginning to feel like a ghost town. I’ve just woken up, and realised everybody’s left.

Is Embarcadero working on a Garbage Collector for Delphi?

noreply@blogger.com (Babnik) — Mon, 14 Dec 2009 19:02:00 +0000

Or is Barry Kelly (Compiler Guy at Embarcadero) just doing some bedtime reading? If he’s not working on this, I hope he’s working on the 64-bit compiler! Actually, I think he’s refactoring c to c++ code!

Jokes aside, I don’t care how many road-maps we get from Embarcadero, or reassurances of the health of Delphi from the powers that be. The one thing that gives me hope for Delphi’s future is having really talented and genuinely clever people working on Delphi. And I don’t really care much for IDE enhancements, but the compiler stuff, that’s where Delphi can make a difference. So it’s good to see Barry’s posts on his blog and on stackoverflow. For the time being, the compiler seems to be in good hands!

Delphi Community Edition

noreply@blogger.com (Babnik) — Mon, 21 Sep 2009 19:31:00 +0000

I’ve just read Jolyon Smith’s post on a Delphi Community Edition. All good stuff, and something I have been clamouring for, for quite a while. The thing is, I don’t think it will happen. Embarcadero are in the business of making money, not giving things away. Incidentally, I think they’d probably make more money in the long run if they did give some things away, but playing the long game can be very difficult.

So here’s a suggestion which is a mix of both the long and short game. I’ve suggested something like this before. Here it is slightly refined.

Create a Delphi Community Edition/Turbo Editon, call it what you want, but the most important thing is it’s price. Yep, it’s free, or perhaps even better make it $99. (For some reason people think free stuff equates to poor quality)
Do all the things Jolyon suggested. Digital Watermarking for example.
Create an app-store on the Embarcadero website, that can accept apps/components from the Community Edition. Embarcadero get a percentage of all sales. (and perhaps they have some utility to remove the watermark when sold through the store)

So users get their cheap edition, but they also get a reason to use it. Why do people put them selves through the hassle of learning Objective-C and Cocoa for the IPhone when it’s arguably easier to develop for Windows Mobile? There’s money in it, that’s why!

Embarcadero get their $99 for the IDE and their 5-10% cut of sales, but more importantly they get a new user. Someone who would have used C# Express Edition, but saw an opportunity. Apple do have the advantage of a closed system, so perhaps it wouldn’t work for Delphi, but Embarcadero would not lose a thing by trying. The developers who currently would buy Delphi Professional, are not the target, and if done right, would still want the Professional version. Your target is that new developer about to download C# Express.

Customer Care

noreply@blogger.com (Babnik) — Thu, 10 Sep 2009 08:06:00 +0000

I was browsing Delphi tagged questions in stackoverflow yesterday, when I encountered this question. It’s all about generics in Delphi 2009. Whether they are actually usable. Here are a few clips from the answers :

I'm using generics extensively in Delphi 2009, and I can say it's not easy as you are often required to work around an ICE

All this trouble seems to be gone in Delphi 2010

Bottom line: if you want to use them, upgrade to 2010.

I have also personally mentioned before that the IDE just doesn’t seem to recognise the existence of generics (try any refactoring or code completion). So basically what we are saying is that if you bought Delphi 2009, and you want to use generics in any meaningful way, you need to fork out more money and get Delphi 2010.

Does anyone else find that disturbing? Let me give you a comparison. Let’s say you have just bought a Dell laptop. It cost about the same as Delphi 2009. The (fictional) Dell Longitude 2009. Among it’s many features, is built-in wifi. When you got the laptop, wifi kind of worked, but the laptop didn’t really recognise it had wifi, and you had to do a lot of manual stuff to get it working. When you did get it working, you noticed in some circumstances, it just refused to work, and in others it only kind of works. You complained to Dell, and they released update 2 and update 3 (some kind of bios update), which made things a lot better, and you were kind of happy. Less than a year later, Dell release the Longitude 2010. It looks like they’re not going to fix the existing wifi problems in the Longitude 2009, but if you have a 2009, they’ll give you a special price on a brand new 2010.

Would you buy Dell again? Would you not expect Dell to fix your Longitude 2009? And if they can’t or won’t, don’t you expect a refund?

I’m not singling out Embarcadero here, it is apparently industry practice. What other industry could get away with it though?

What worries me is that I have to go to my boss and ask to upgrade to Delphi 2010. I am lucky, that I work for a company that has no problems in giving us the latest tools, whatever the cost. And in the grand scheme of things, to even a small company, the price of Delphi is insignificant. However, my boss will definitely ask the question, What does Delphi 2010 give us? I can wax lyrical about increased IDE productivity, and improved RTTI, but at some point I’ll have to add the line. Well, we had a few problems with generics in D2009, but it’s all been sorted out in D2010. What kind of confidence does a line like that instil?

W32/Induc-A are you worried?

noreply@blogger.com (Babnik) — Fri, 21 Aug 2009 11:26:00 +0000

Over the last few days there have been a flurry of posts about this virus. I’m not going to repeat what it is or what it does, as I’m sure any self respecting Delphi developer has read the same posts that I have.

Are Embarcadero worried about this development? If not, they should be! (To be fair, they are aware of it, and thinking about it)

It’s all well and good telling us that

It only affects Delphi 4-7, so get the latest version!
It is a rather benign virus, and doesn’t cause any harm, so don’t worry unduly.

Unfortunately the cat is out of the bag, and you can’t put it back. I think (and somebody correct me if I’m wrong), there is nothing in the current version of Delphi that prevents this being replicated for later versions. My guess is the virus writer is one of those who hasn’t upgraded, and it’s only a matter of time before someone replicates this for Delphi 2009. Secondly, who knows what the next virus might do? This maybe just a warning, the next one may cause untold havoc.

How long before clients start asking what tool we use for our development, and refusing to buy applications written in Delphi. I need to be able to tell clients that this cannot happen with the tool we currently use. Is that even possible?

Time for new project type?

noreply@blogger.com (Babnik) — Thu, 20 Aug 2009 22:44:00 +0000

I’m not a web developer. While I did do some classic ASP earlier in my career, it’s mostly been about classic (Delphi) Win32 applications for me. So recently I thought I’d have a look at ASP.NET. At the same time, I thought I’d also have a look at ASP.NET MVC since that seems to be the in thing at the moment. Now I have no bias either way. I’m fairly new to both, but I just loved the simplicity of ASP.NET MVC. I’m not sure if simplicity is the word I need here, because actually, classic ASP.NET is perhaps the easier option for an inexperienced developer, as it uses abstractions to make Web development a drag and drop affair. Still, ASP.NET MVC just felt more natural to me. I’m sure had I looked at it 10-12 years ago (and had ASP.NET and ASP.NET MVC been around), I would have loved ASP.NET, and wondered why they even bothered with MVC.

This got me thinking about my day job. Since Delphi 1 we’ve opened up the IDE and clicked on New VCL Forms Application, got our empty form and started dropping components on the surface. We drop a few more components, create a few bindings, write a few event handlers, and hey presto we have an application. I bet every Delphi developer started out that way, and it works, but as you get more experienced, you begin to realise that for any real-world, half decent application, this sort of coding style just doesn’t scale well, and more importantly doesn’t maintain well. So you add a datamodule, and move all your database components to it, and feel happy for all of about 3 minutes. Something still bothers you though, so you get rid of the datamodules, and get rid of the data aware components, and perhaps write a framework, or even get a third party one. You read the book on design patterns, and see how many of them you can fit into your application.

Now that’s all well and good, and your framework may be great, but it’s different than my framework. Actually, I keep changing my framework of choice depending on what article or book I read last. My point is, that there is no consistency. So while the data-aware component model works well for beginners, and I would not advocate getting rid of it, I think Delphi is more than mature enough to have a new model. Sure we can look at third-party vendors for this model, or we can write it ourselves, but if we want real consistency, it needs to be in the IDE right next to Create New VCL Forms Application, and everybody needs to have it in their IDE. That way, when that new developer outgrows the 100 components per form model, and he or she is ready for the next level, there’s a clear path.

So how about it Embarcadero? Perhaps it’s time for Delphi to grow up a bit. I dunno, some kind of MVC pattern perhaps. Perhaps Passive View. Why not more than one? Wouldn’t you like to see this in the menu under File|New

New Passive View Project

Or maybe it’s just me!

Now I’m excited!

noreply@blogger.com (Babnik) — Mon, 17 Aug 2009 15:08:00 +0000

I’ve just read about attributes and RTTI in Delphi 2010. As someone who has used RTTI extensively and looked at reflection in .NET enviously, I can say I’m really looking forward to playing with the new RTTI model.

As for attributes, I’m sure a whole new array of interesting ways of doing certain things is going to be possible. There are currently lots of tools and frameworks which use RTTI to do certain things. Up until now, one of the main drawbacks to this was you could only work on published properties and methods.

One example that comes to mind is a small tool supplied with a third party component that prepares Delphi components and classes for use in a scripting solution. This tool works great, and parses classes to produce the boiler plate code needed for setting up the runtime environment for scripting. Unfortunately, it can only work on published properties and methods. If you want to expose any public properties, you have to do it manually.

These kind of things excite me more than IDE enhancements or ribbon controls. Having said that, I hope the IDE keeps up with these new compiler innovations. Does code completion still work with custom attributes for example?

Productivity versus Excitement

noreply@blogger.com (Babnik) — Wed, 12 Aug 2009 11:49:00 +0000

Many of the commentators in my two recent posts pointed out that the IDE additions and fixes in the forthcoming Delphi 2010 will increase productivity. I have no doubt about that. There’s one in particular I can see saving me quite a bit of time, and that’s the uses units. I use that little tool all the time, and could never understand why it automatically always put the unit in the implementation’s uses clause by default. Why can’t I choose? Well apparently now I can.

One particular comment went on to say that compiler changes, the thing I said might just excite me, could in fact decrease productivity. It takes time to learn new stuff, and if you are spending more time learning, than actually doing things, then you’d not getting things done.

That got me thinking about the Microsoft world, and how it seems that you hardly have started looking at one new technology, before it’s superseded by another. You’ve just about got your head around Winforms, and they spring WPF on you, then you jump on to that bandwagon, and suddenly it’s Silverlight out of the browser that’s the new in thing. Oh wait a minute, WPF and Silverlight doesn’t seem to be doing so good, perhaps we should stick with Winforms. Same on the web development side of things. You start with ASP.NET, get comfortable with ViewState and postbacks, and bam, they bring out ASP.NET MVC and tell you to forget all that (Actually they say they’re keeping both, so you need to decide which is for you). To make things worse, they offer you Silverlight as well. It’s the same wherever you look. Linq to SQL? Well apparently Microsoft now prefer Entity Framework. Well they did. I’m not quite sure anymore.

So yeah, all these new innovations to the language and new technologies do have an effect on your productivity, especially if you are trying them all out. The thing is, it’s human nature to want something new and shiny. Look at mobile phones. Most people use their mobile phones for making and receiving calls and that’s it. Oh, they might try a few of the new features when they first get the phone. Maybe take the occasional photo with their phone, but for the most part, they just make calls. So why do they change their phone every 6 months or so? The phone they had 5 years ago still works great for making those calls. The phone manufactures know it’s human nature to always want the new model. So they oblige and keep churning them out.

Microsoft also know that they can’t just rest on what they’ve got. They’ve got to keep their audience excited. Keep throwing as much new exciting stuff as is possible to keep them coming back for more. So while I agree, I’m as productive as a Microsoft developer who is using C# and Visual Studio, I admit I do go green with envy when that get some new toy!

Delphi Love

noreply@blogger.com (Babnik) — Mon, 10 Aug 2009 10:23:00 +0000

I was rather surprised at the comments to my last post. Some were pretty heated. Delphi developers are extremely protective of their baby, but I knew that already. I didn’t actually think my post was that provocative, but perhaps it was.

A good number commented that what has been released so far is only the tip of the iceberg, and that beta testers were not allowed to reveal more yet. That’s all well and good, but I can only comment on what I have seen. When more is revealed, I no doubt will add further comments.

Actually, I never said 2010 sucks. I just said that I’m not that excited yet. I didn’t say others wouldn’t be excited. I just said that I, personally, in my humble opinion, need more than IDE changes to get my blood stirring.

Each release of Delphi Prism excites me for example. They seem to be forever adding little goodies to the compiler. Perhaps it’s easier to do with the .NET platform?

Delphi 2010

noreply@blogger.com (Babnik) — Sat, 08 Aug 2009 13:51:00 +0000

I know I’m supposed to get excited and all that, but I’m not. Improvements to the IDE, no matter how useful or needed just don’t do it for me. I guess it’s analogous to an accountant getting excited at improvements to his favourite calculator. (although I guess accountancy is so boring that a few new buttons on a calculator might just warm an accountant’s cockles!)

I get excited at real innovation. Improvements to the language for example. Ability to do things with my preferred language that’s either impossible or difficult to do with any other language. Innovation to the underlying Compiler etc etc

I guess I’ll have to wait until Delphi 2011 comes out.

Delphi Generics

noreply@blogger.com (Babnik) — Wed, 29 Jul 2009 09:06:00 +0000

Generics was or is one of the flagship features of Delphi 2009. Probably up there with unicode. Unfortunately, I don’t think the time was been put into the feature that it deserves. It feels like a badly implemented third party component. There doesn’t seem to be much in the way of communication with the ide. Code completion doesn’t work with generics. Same with class completion. Why not? Refactoring falls over as well.

This was all annoying, but we could almost live with it. Unfortunately we’ve now got a problem, which means we can’t use generics at all. Most of our automated testing is done with Automated QA’s Test Complete. Since we’ve moved to Delphi 2009, we’ve had a major problem, in that the debug information from our Delphi application was not being read properly from Test Complete 7. Here’s my question about it on Stack Overflow. Automated were baffled. We tried writing small test applications, but we couldn’t reproduce the problem. There was something about our application, Test Complete didn’t like. After months of investigation, we finally came to the conclusion that generics was the problem. Luckily, we had actually refactored some of our code to use generics, so it was easy to go back to the previous version. And hey presto, Test Complete is now totally happy.

Automated are now looking at it. I wonder if it’s a Test Complete problem, or is it generics messing up the debug information in the executable?

Consumer Protection

noreply@blogger.com (Babnik) — Sun, 10 May 2009 07:37:00 +0000

The European Commission is proposing wants to make developers, liable for their own code. When they say developers, I guess they mean the actual company that releases the software, rather than the individual developer.

I have mixed feelings about this. As a developer, this would mean a fundamental change in the way we do things. It will probably stifle innovation, as new developments will become increasingly expensive. As a user, I’d welcome it. No more security holes in Microsoft browsers, and more importantly to me, no more bugs in my favourite IDE, Delphi. At the very least, companies would have to be more responsive with their bug fix updates (hint, hint Codegear. I’m still waiting for update 3. At this rate though, the EC will have passed their law, and Codegear will have to release their update!)

Is this a good thing, or a bad thing? Have we, as developers, had it too easy? Have we relied on our users to find our bugs?

Quality?

noreply@blogger.com (Babnik) — Sat, 02 May 2009 22:15:00 +0000

I’ve been using Delphi 2009 for about a month now, and for the most part I’m happy. Unfortunately that’s only because when you’ve been disappointed so many times, you’re grateful when you get an IDE that doesn’t crash every 5 minutes. Seriously though, so far so good. (one thing is driving me nuts though. I’ll post about it later)

So there are a few bugs. I’m a developer, and I’ve been around long enough to know that every piece of software, however good the process and the people behind it, has bugs. So I’m under no illusions here. While no bugs would be nice, I know it’s not realistic. But here’s my gripe of the day! Why does it take so long to fix the bugs?

Whilst I expect bugs in a product, I don’t expect to wait 6 months after it’s release, for those bugs to be fixed. Some of the bugs I’ve found in TDictionary lead me to believe the code was not tested. Already not a very good sign. But hey, things fall through the cracks, we’re only human right? The thing is some of those bugs are so easy to fix, that any junior developer, just out of college, could find them, and fix them in an afternoon. So why 6 months later, are we still waiting? I don’t understand it?

And it’s not like Codegear don’t know about these bugs. They’ve been reported in Quality Central for a while. Oh and that’s another thing. If you’re going to charge me for your software (fair enough), and then use me as a tester, please, oh please make it easy for me to tell you about bugs in your software. I have to go to the Codegear website. If I’m lucky, I’ve got my username and password written on a piece of paper somewhere, if not, I have to click on the lost password link. Wait for the email, fish it out from my spam folder. Then I’m not sure what you have to do, because I never got that far. Why can’t I just highlight some code in Delphi, right click, and choose report a bug. Put in a little description, and that’s it? You have my details as I use a registered copy.

As you can tell, I’m impatiently waiting for update 3? Where is it guys?

Generics in Delphi 2009

noreply@blogger.com (Babnik) — Fri, 17 Apr 2009 23:28:00 +0000

I've now had Delphi 2009 installed on my machine for about a month, and have been refactoring some code to take full advantage of Generics and Anonymous methods. I really like generics, but am beginning to feel really uncomfortable with the Delphi implementation. It just doesn't feel 100% stable. I get the occasionaly internal error, which then dumps you somewhere at the very beginning or very end of a file, with no indication about what you have done wrong. Try adding the overload keyword to a method in a generic class, without actually overloading the method for example. Code completion is a bit of a mess, sometimes working, and sometimes not. I won't even mention the TDictionary class, which is practically useless, as it is riddled with bugs. Well perhaps not riddled, but there are a few, making it unusable. Try using the enumertors for example.

Why release it when it clearly needed a little more work? When is it going to be fixed?

Component ITunes

noreply@blogger.com (Babnik) — Thu, 02 Apr 2009 23:27:00 +0000

Delphi’s strength has always been the VCL, and it’s extensibility. You always got a lot out of the box, but the knowledge that whatever you wanted to do, there was a component somewhere out there that would do it for you was an incentive to use Delphi. I could, and did spend days on the Delphi Super Page, just downloading components and trying them out.

Borland (and now Codegear) have always been careful not to step on the feet of their third party vendors, so always left some gaps for them to fill in. And rightly so. That’s why Delphi was such a success.

Unfortunately, the third party vendor scene has not been as vibrant as it once once. Sadly, the number of vendors producing quality components has decreased greatly since the glory days.

The freeware and shareware scene was also beyond compare. Now almost all freeware and open source components have not been updated since Delphi 7. The Delphi super page sometimes feels like a museum. With the advent of Delphi 2009, this problem can only get worse, because while before, a simple recompile would suffice, now you have to do some extra work.

I think Borland were 100% right in leaving the market open to third party vendors, and stepping back and letting others fill the void. It made Delphi popular, and it made the vendors happy. But times have changed, and perhaps now it’s time for Codegear to step in, and help it along a bit.

My suggestion is for Codegear to setup an ITunes for Delphi components (you know what I mean!). Somewhere, vendors, developers and Codegear themselves can sell (or give away) quality components. Codegear could approve anything deemed worthy to be on there. There is a lot of abandon-ware out there that could be resurrected and brought up to date for Delphi 2009, endorsed, and offered up by Codegear. There’d be one central place where Delphi developers go for all their component needs.

The remaining third party vendors would be happy, because they’d have another outlet for their products. New vendors would be happy, because they have a customer base ready, and waiting, and hungry for new components.

If Apple can do it with music, why can’t we do it with components?

When did the internet become so essential?

noreply@blogger.com (Babnik) — Sat, 28 Mar 2009 08:01:00 +0000

Next week I’m going into hospital for a knee operation. I’m not worried about the pain, or the months of rehabilitation afterwards. I’m worried about how I’m going to live five days without an internet connection.

I’d gladly exchange painkillers for a wifi connection. When we get the occasional problem with our broadband connection at home, I go crazy worrying that it’s going to be days or even weeks before we get it back.

I don’t know if it’s just me, but I’d gladly give up TV, telephones, game consoles, (some) food, warmth, comfort rather than lose my internet connectivity. At what point did connectivity become so important? I know there are people out there without connections, but it astounds me. I guess there are more important things, especially in developing countries, but in the first world, it’s quickly becoming essential to be within a metre or two from a computer with a connection. I guess with the advent of devices such as the IPhone, we’re going to be even closer to that connection than ever before. And we’ll subsequently fret even more when we’re cut off.