Hardcore Software

How hard it can get?

CodeGear’s roadmap for Delphi and C++ Builder is published June 14, 2007

Filed under: .NET,Delphi,News,Software — Hemant @ 7:05 pm

CodeGear has published the roadmap for 2 of it’s major products Delphi and C++ builder.

Advertisements
 

Moving to .NET Platform, A difficult choice? May 20, 2007

Filed under: .NET,Delphi,Life,Software — Hemant @ 5:20 pm

I am working on a product which is developed using Delphi for Win32. Originally Delphi 7 was used and we then moved to Delphi 9 (Delphi 2005) and are now planning to move to Delphi 10 (Delphi 2006). I have to admit that despite the originally reluctance in accepting the Delphi as the long term development technology, I have now grown to simply love it. You know what I like about Delphi most? The fact that it solves the real world problems!

You know there is lot of technology talk always going on. Every second day you hear the announcement of a new language, new database technology, new framework which would just magically solve all your problems. But if you have worked even for few months in software industry (as I have), you will realize there is no such thing which can solve all our problems magically. Language, framework and components just assists you do your job and *nothing* can replace a good programmer. Still Delphi provides the simple to understand and simple to use framework which suits most developers. This is because real developers like to find the “most appropriate way” to solve a problem in given time and resources and not essentially the “best way”. Lengthy and exhaustive time, performance, use analysis is luxury of few developers, who program in a garage and for fun.

Everything was working fine until my organization had to think “What to do about .NET platform? Do we need to go for it?”

After thinking for sometime, I concluded couple of points:

  1. Developers (who actually get to work on product) like to work on a technology which is popular in market. Perhaps it makes them feel safer that it will not be too difficult to find another job, just in case. If you ask “Why you like to work on .NET?” it would be difficult for them to answer. Perhaps the only answer is “because every second person seems to talk about .NET”.
  2. It doesn’t matter to the organization whether its developers are using .NET or Java or Delphi; it wants to deliver the right solutions to customer at right time.

During my initial couple of months in software development, I used to find so many problems with existing code/structure/design etc. Even a stupidly named variable would drive me nuts. It’s not that now I don’t care about how variable are named but you just can’t make everyone to name variables like you. You have to adjust somewhat somewhere. I always liked to do things the perfect way and I still do, but now I also think “what is more important? Renaming the variable to my taste in 20 odd units or shipping the product to customer next week?” Don’t take me wrong, I am a real nasty person in this regard; I would still rename the variable in 20 odd units but only in next planned release!

In coming few days, a decision will be made by me and few senior people (who I actually admire). Lets see what comes up!

 

Delphi Compiler Version Directives March 6, 2007

Filed under: .NET,Delphi,Software — Hemant @ 1:32 pm
Here is a list of Delphi Compiler version directives. I searched few places but none could give me complete list (A page on About.com was closest to completion) so I thought of creating this list and publishing it.
SYMBOL COMPILER VERSION
VER80 Delphi 1
VER90 Delphi 2
VER100 Delphi 3
VER120 Delphi 4
VER130 Delphi 5
VER140 Delphi 6
VER150 Delphi 7
VER160 Delphi 8
VER170 Delphi 2005
VER180 Delphi 2006
WIN32 Indicates that the operating environment is the Win32 API.
CONSOLE Indicates that an application is being compiled as a console application.
LINUX Indicates that the operating environment is Linux.
CPU386 Indicates that the CPU is an Intel 386 or better.
MSWINDOWS Indicates that the operating environment is Windows. Use MSWINDOWS to test for any flavor of the Windows platform instead of WIN32.
CLR Indicates the code will be compiled for the .NET platform.
 

Thinking of using constants in Delphi? Consider class properties! February 27, 2007

Filed under: .NET,Delphi — Hemant @ 5:39 am
If you have gone through any *real* software project you will understand the need of using constants in code. Your professor would have told you thousand times that don’t use any magic numbers in code and if you need, define a constant and use *that* in code. I wouldn’t go into the flexibility constants brings in (define and change at single place and use million times stuff).

What I want to discuss is an alternative to constant. There are called “class properties”. In C world, these would be called static properties. Yes, you guess right. These are properties which relate to a “class” rather than an “object” (instance of the class). With Delphi.NET, we now have:

  1. Class Fields
  2. Class Methods (Both procedures and functions)
  3. Class Properties

Class fields and class properties and not available in Delphi for Win32 (well, programmers take “never say die” approach).

So class properties allows us to write something like:

var
number: Integer;
begin
number := TPredefinedNumbers.DefaultNumber;
//do something with number
end;

Here, “DefaultNumber” is a class property of TPredefinedNumbers class and we can access DefaultNumber using class name and without actually creating an instance of it. .NET framework makes extensive use of class properties. Refer SystemColors, Brushes etc.

Why class properties qualifies as an (perhaps better) alternative for constants? The reason is, you never know what crazy requirement will be raised by your sales or marketing person which calls for user control on that constant. Perhaps you would think that using the INI file for that constant value would be better so that you can control it. Perhaps day after tomorrow it will qualify to sit in a database field. Who knows?

So class properties provide a great abstraction. When you want to change the location where that constant value resides, all you need to change the get method of class property. And everything works fine..

type
TPredefinedNumbers = class
private
class function GetDefaultNumber: Integer;

published
class property DefaultNumber: Integer read GetDefaultNumber;

end;

implementation

class function TPredefinedNumbers.GetDefaultNumber: Integer;
begin
//You can return a hard coded value
Result := 0;

//or you can get from INI file or database or whatever and return
end;

 

Using the HashTable in Delphi for hybrid collections February 16, 2007

Filed under: .NET,Delphi — Hemant @ 6:53 am

While working on one of my project I came across a problem of maintaining a collection of item who were of different types. As I was using Delphi.NET, I was able to use HashTable class (in System.Collections namespace) for this purpose.

Here is code snippet:

{$AUTOBOX ON}
procedure UsingHashTable;
var
hybridCollection: Hashtable;
stringValue: string;
dateTimeValue: DateTime;
integerValue: Integer;
begin
hybridCollection := Hashtable.Create;

stringValue := ‘A String…’;
dateTimeValue := System.DateTime.Now;
integerValue := 1000;

//stuff different type of values in the collection
hybridCollection.Add (1, stringValue); //Add a string
hybridCollection.Add (2, dateTimeValue); //Add a datetime
hybridCollection.Add (3, integerValue); //Add an integer

//Get the values back
stringValue := hybridCollection[1] as System.&String;
dateTimeValue := hybridCollection[2] as DateTime;
integerValue := hybridCollection[3] as Integer;

console.WriteLine (stringValue);
console.WriteLine (dateTimeValue);
console.WriteLine (integerValue);
end;
{$AUTOBOX OFF}

Above code snippet produces following output:
A String…
16-Feb-07 12:15:05 PM
1000