Why I still prefer Delphi over C# WinForms | The Coffeehouse

sysrpl

I've been using C# and Visual Studio at work, but I still keep coming back to Delphi. Here what I think Delphi has over C# and VS.

Some features I prefer/need:

sets and set operations
virtual constructors
deterministic and virtual destructors
virtual static methods
messaged based method and DefaultHandler
implementation through delegation
assign and assignto
property promotion
published section
access to source code examples of property editors, component editors, experts, design time support
full library source code
interface and implementation sections
design time binary/string properties, easy support to stream to/from dfm
class types
global level procedures and functions
block declarations
better com support
better windows api support
better visual control library
both graphic and windowed controls
onevents rather than method sounding events (click in c# vs onclick in delphi)
native code, no runtimes
asm, mmx, sse, sse2, sse3

Importantly from above organization

Block delcaration and interface/imeplementation sections really make a difference in organizing code. With the interface section I get to see the outline of the class/types, and with block declaration I see everything organized in a strict order.

class
private
    field
    field
    field
    method
    method
    method
protected
    method
    method
    method
    property
    property
    property
public
    constructor
    destructor
    method
    method
    property
    property
published
    promoted property
    promoted property
    promoted event
    promoted event

I love the above. Delphi forces you to place fields before methods, methods before, properties, properties before events. Delphi does not put the implemenation and declaration together, C# is nowhere near this organized. C# is a bunch of implemenation code rolled into declaration code, usually appearing in no organized pattern (ie.e things come in any order).

With C# you cannot block declare things such as:

const
WM_A = WM_USER;
WM_B = WM_A + 1;
WM_C = WM_B + 1;

WM_D = WM_C + 1;

Regarding class types, you can't do this in C#:

procedure ExecuteForm(FormClass: TFormClass): Boolean;
begin
with FormClass.Create(Appllication) do
try
Result := ShowModal = mrOk;
finally
Free;
end;

end;

To me, property promotion is also a big deal. I wrote a winform control in C# recently and was quite disappointed to learn of all the derived properties which were exposed as public which I would preferred to have hidden.

The windows control section of is also much more powerful. The base control, graphic control, custom control classes have so many more methods.

Event naming in C# irks me to no end. I really want to know if something is an event by looking a it. OnClick to me automatically tells me, "Hey, I'm a click event", whereas Click seems to me like an action (method) "Click the button". Then c# messes up events further with their virtual names using On (it's Do in Delphi).

Oh, and I'm not totally sold on EventArgsTypes. It is so annoying in VS to break open the help, searching for the an event to see the type, clicking the type to get to the about page for the type, clicking the EventArgsTypes, then click members, and finally learning what the parameters actually are. In case that want click, here it is in diagram form:

In VS highlight MouseDown in the property grid -> F1 help pops up
public event MouseEventHandler MouseDown -> click MouseEventHandler
public delegate void MouseEventHandler(Object sender, MouseEventArgs e) -> click MouseEventArgs
public class MouseEventArgs : EventArgs -> click members
MouseEventArgs Members -> scroll down past the constructor and methods inherited from system.object
Ah what type is "Button"? -> click "Button" to find public MouseButtons Button { get; }

In Delphi (using version 7 here) highlight MouseDown in the object inspector -> F1

type

TMouseEvent = procedure (Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer) of object;

Boom! Now that was a lot easier. The event has 5 parameters, and Button is type TMouseButton.

That's enough for now. You get the idea.

Ion Todirel
buuu

You can't compare lemons with strawberries, and I think you got some stuff wrong e.g. "better visual control library" among others, a fairer comparison would be Delphi.NET with C#, you also seem to dismiss BCL from C#'s side. Just some personal thoughts...

sysrpl

In reply to Ion Todirel

#Sep 15th @ 8:05 PM

Of course I can compare apples to stawberries. I like stawberries so much better. Tasty, juicy, and each one is bite sized.

I'll take you on the WinForms vs VCL "better visual control library" debate. I'll even give you some extra points to start with:

Your free point:

.net has better data binding

Now my points:

The VCL is a rich object orient Visual Class Library which encapsulates working with and designing Windows desktop applications. The control library contains of 150 visual controls with a distinct between both Graphic and Windowed controls. When designing your own control, drawing performance is many factors greater than with C# Gdi+. Of course if you want to use Gdi+in the VCL, you are free to do so. The control library (which come with the full source by the way), is mature and quite well laid out (by Anders Hejlsberg). WinForms was a port of the VJ++ library Anders was working on before Sun axed their VJ++ product (precisely because of the *Windows only* extensions Anders was putting into VJ++). With the VCL I can create many great visual design easily, that are performant, aesthetically pleasant, and rapidly designed.

Examples of my work with the VCL:

http://imagebot.org/snapshops/new-work-app.jpg

http://imagebot.org/snapshops/report-utility-operators.jpg

http://imagebot.org/snapshops/liberty-reports-favorites.jpg

http://imagebot.org/consulting/mail_merge_screen3.jpg

http://imagebot.org/snapshops/phun-gears-builder.jpg

http://imagebot.org/snapshops/mushroom-editor.jpg

With the VCL I can also easily do true 3D animation and shader programming:

http://imagebot.org/snapshops/gold-dragon-hammered.jpg

http://imagebot.org/snapshops/angel-fine.jpg

The controls in the VCL contain many more methods wrapping the Windows API, making it easier to extend the controls, You also have the choice to create non-windowed controls which can be drawn transparently over their container control. The VCL also has property promotion, so that when you design a control, it doesn't not expose those properties which are not suitable to be exposed from the derived class (TabStop for example, dicussed here).

Com interop is easier with the VCL, and thus controls which rely on com are easier to create and use. For example and IShellBrowser control a ole rich text control (rich edit with image support).

You might want to view a few of my videos or read some of my developer notes:

http://imagebot.org/recordings/groupgrid/new-grid_controller.swf

http://imagebot.org/recordings/reports.swf

http://codebot.org/delphi/?doc=9551

http://www.codebot.org/delphi/?doc=9556

http://codebot.org/delphi/?doc=9533

CreamFilling512

In reply to sysrpl

#Sep 15th @ 8:36 PM

WinForms is largely deprecated by WPF though, which is extremely powerful and expressive. WinForms is more of a Win32 wrapper library, although they added some nice things in 2.0 like DataGridView. I still use WinForms for new code because its very lightweight, it depends on the requirements.

I'd like to hear how COM Interop is better in Delphi though, considering its been practically transparent when I've done it in .NET.

W3bbo
The Master of Baiters

It looks to me like you just took the "differences between Delphi and C#/.NET" article and just listed the features in Delphi that aren't in C#.

A lot of the stuff you describe are moot points: C# doesn't have "globals" because that's what static class members are for, we know from C that a single global namespace is a bad thing and that's why it doesn't have it. Other concerns are subjective, like "better foo library": there's no way to prove that.

The CLR makes use of machine-specific processor instructions when it's available to it, like MMX and SSEn. Assembly code isn't allowed in .NET assemblies because otherwise it wouldn't be portable, which is by-design. I consider this an advantage over Delphi's machine-specific approach.

Also, what are you talking about when you say "virtual static methods"? there's no such thing. In .NET a derived class can implement new static members with names that "override" (or shadow, rather) the old one with the 'new' modifier keyword. Otherwise you could be using singleton instances and factory patterns.

sysrpl

In reply to CreamFilling512

#Sep 15th @ 8:53 PM

I believe you have mistakenly conflated COM and automatation control backed by a type library. Certainly automatation and type libraries are part of COM, but they do not encompase its entirety.

The few examples I listed above touched a bit more on vanilla com. IShellBrowser, IShellFolder, shell extensions (which Microsoft now dissuades you from), IDataObject, ect which yields crap like this in C# (and this code doesn't include how to define these com interfaces):

*** In C# you would ***

int retVal;

ShellLib.IMalloc pMalloc;
pMalloc = ShellLib.ShellFunctions.GetMalloc();

IntPtr pidlSystem;
retVal = ShellLib.ShellApi.SHGetFolderLocation(
                IntPtr.Zero,
                (int)ShellLib.ShellApi.CSIDL.CSIDL_SYSTEM,
                IntPtr.Zero,
                0,
                out pidlSystem);

IntPtr ptrParent;
IntPtr pidlRelative = IntPtr.Zero;
retVal = ShellLib.ShellApi.SHBindToParent(
                pidlSystem,
                ShellLib.ShellGUIDs.IID_IShellFolder,
                out ptrParent,
                ref pidlRelative);

System.Type shellFolderType = ShellLib.ShellFunctions.GetShellFolderType();
Object obj = System.Runtime.InteropServices.Marshal.GetTypedObjectForIUnknown(
    ptrParent,shellFolderType);
ShellLib.IShellFolder ishellParent = (ShellLib.IShellFolder)obj;

ShellLib.ShellApi.STRRET ptrString;
retVal = ishellParent.GetDisplayNameOf(pidlRelative,
    (uint)ShellLib.ShellApi.SHGNO.SHGDN_NORMAL, out ptrString);

System.Text.StringBuilder strDisplay = new System.Text.StringBuilder(256);
retVal = ShellLib.ShellApi.StrRetToBuf(ref ptrString ,pidlSystem,strDisplay,
    (uint)strDisplay.Capacity);

System.Runtime.InteropServices.Marshal.ReleaseComObject(ishellParent);
pMalloc.Free(pidlSystem);
System.Runtime.InteropServices.Marshal.ReleaseComObject(pMalloc);

*** Now in Delphi that would be ***

var Desktop: IShellFolder; ItemList: PItemIDList; StrRet: TStrRet;

SHGetDesktopFolder(Desktop);
SHGetSpecialFolderLocation(0, CSIDL_SYSTEM, ItemList);
Desktop.GetDisplayNameOf(ItemList, SHGDN_NORMAL, StrRet);
CoTaskMemFree(ItemList);
Result := StrRet.cStr;

Because:

A) Delphi already declares the Windows API, COM functions, and COM types for you

B) Delphi releases COM pointers for you

Ion Todirel
buuu

In reply to sysrpl

#Sep 15th @ 9:30 PM

actually in C# it would be a one liner, but I think you know that...

sysrpl

In reply to Ion Todirel

#Sep 15th @ 9:38 PM

The purpose of the example was to show how COM interop works in C#, not how to retrieve the system path, but I think you knew that. If you have to, use your imagination and pretend you were writing a function where you didn't know how pidl was created.

CreamFilling512

In reply to sysrpl

#Sep 15th @ 9:30 PM

I think its great that delphi has shell32.dll stubbed out for you. I assume they update the bindings everytime a new version of Windows comes out? But what does this have to do with COM interop? COM seems to have little to do with your example besides the fact you are calling some shell functions that take COM objects as parameters. In .NET I can reference a COM library in visual studio, and instantiate the objects like first-class .NET objects, or implement a COM interface like any other managed interface. I don't see how Delphi improves on interop with "Generic COM Library".

sysrpl

In reply to CreamFilling512

#Sep 15th @ 9:49 PM

Again, you incorrectly ecompassed automation plus a type library as all of COM, when in reality it's only a small portion.

Oh and side point, Delphi even makes automation easier with default and named parameters, late binding, and the choice to use a dual interface.

vesuvius
Das Glasperlenspiel

Maybee the langage designer of Delphi was better than the language designer of C#

AndyC

In reply to sysrpl

#Sep 15th @ 9:40 PM

True, but your example in Delphi only works because the types from Shell32.dll have been pre-wrapped for you. If you're going to compare C# and Delphi in this respect then you need to write the Delphi code without using the built in helpers for shell32 (otherwise the .NET BCL methods are just as valid and a lot easier).

And while I agree that some of the structure inherited from Pascal is quite nice for forcing tidy code, it also inherits the fact that object-orientation is clearly a bolted on afterthought. Polymorphism in Delphi, for one thing, is just plain ugly.

Other things: Virtual Constructers are just syntactic sugar around class factories, which are easily done in C#. Global anything is just plain horrid. And I'm not sure I really see your point on the EventArgs things, but then maybe that's because I let Intellisense tell me rather than breaking my workflow to have a search through the help files.

TommyCarlier
I want my scalps!

In reply to vesuvius

#Sep 15th @ 10:30 PM

That must have been it. Wink

exoteric
I : Next<I>

In reply to W3bbo

#Sep 15th @ 9:07 PM

"A lot of the stuff you describe are moot points: C# doesn't have "globals" because that's what static class members are for, we know from C that a single global namespace is a bad thing and that's why it doesn't have it. Other concerns are subjective, like "better foo library": there's no way to prove that."

No reason to have "globals", just namespaced functions. Extension methods mitigate this.

exoteric
I : Next<I>

In reply to TommyCarlier

#Sep 15th @ 10:42 PM

Technically speaking it was not the same set of people Wink

spivonious

In reply to exoteric

#Sep 16th @ 12:41 AM

I agree with you on the whole EventArgs thing. I never understood how that makes things easier. It just means I have to make pointless wrapper classes for one property for my own events if I want my events to look like the built-in ones.

sysrpl

In reply to vesuvius

#Sep 15th @ 10:30 PM

I swear up and down I've watched video interviews with Anders H (probably hosted on this site) where he just sat there biting his tounge rather than telling you what he really thought. His position at Microsoft deals with a lot of hotter heads and political jockeing as much as it does with design (of which he is god like).

Sure, C# has some totally awesome features, and .net is completely cool in many areas (especially the single rooted object, reflection, implicit/explicit conversions, and so on), but it was not designed in a vacuum, whereas Delphi was witha bit more run authoririty by Anders H.

That's not to say Delphi is the greatest thing ever. It has a lot of problems as well, but they've been working on those just like Microsoft continutes to improve C#.

I'm not totally against C#, I'd just like to see it improved. I use the best tool for the job and show no brand loyaltly, instead I judge something on its merits.

For web apps, rich animated content, games (XNA), command line (powershell aka monda), and many other situations, C# wind hands down. My passion though is Windows GUI desktop application development, and I feel Delphi is still ahead in that area for some of the reasons I outline (I wan't trying to build an exhaustive list).

C# can stand to be improved, and I think it will. The next version they are introducing features to make workng with automation (named and default parameters, dynamic type/late binding) better and more in line with what Delphi already has.

spivonious: I'm with you there, but when I work with C# I do try and follow the same patterns presented by the BCL in order to create consistent code.

Dexter

In reply to spivonious

#Sep 16th @ 5:01 AM

Couple of points about the EventArgs stuff:

- This makes possible for a "future version" to provide more information with an event. You can add fields and properties to the event args class but you cannot add parameters to an existing delegate.

- It allows the event handler to return information to the event invoker (see CancelEventArgs) without using ref/out paramters.

- The event args classes can form a hierarchy (see what inherits from WinForms's MouseEventArgs for example).

- Some event args classes have more than 2-3 properties. How do you like a function with 8 parameters from which most of the time you only need 2?

And for the common case where you need to pass only one value to an event you can create an EventArgs<T> if you find creating a new class such a hassle.

Dr Herbie
Horses for courses

In reply to Dexter

#Sep 16th @ 6:57 AM

+1

EventArgs is a good OOP design because you can change the structure of the parameter class to add more properties\methods without affecting method signatures all over the code.

I do this in normal code too (where there is no way around extensive parameters).

Herbie

CreamFilling512

In reply to sysrpl

#Sep 15th @ 9:56 PM

No you're incorrecting referring to a bunch of random DLL exports as COM interop, you're just using pinvoke. A type library is how you make COM components usable by other devs. If I'm going to be using COM components in code its safe to assume they're in a type library?

sysrpl

In reply to CreamFilling512

#Sep 16th @ 10:43 AM

Q: If I'm going to be using COM components in code its safe to assume they're in a type library?

No, a type library is something that is a convenience to developers and is not required. It's not required for automation either, in which case with C# you're SOL.

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to sysrpl

#Sep 16th @ 11:29 AM

A type library is required to make COM usable in pretty much any language except C/C++ (in which case you can make do with the headers generated by the IDL compiler). With nothing but the DLL (no type libraries or headers), COM objects are as good as unusable.

Marc Truitt

The only thing I find truly frustrating between .NET and Delphi is a linker (does anyone remember those) is missing from .NET. I understand the framework is supposed to be installed, but in a corporate environment there are multiple versions of .NET, a computer may have .NET 1.1, 2.0, 3.0, 3.5...etc....I was a true believer in the .NET concept, but in the real world where we have web servers with multiple versions of the framework running and Microsoft has lost the concept of "backwards compatibility" I traded dll hell for .NET hell. I work for the local government we don’t have the budget to rewrite code for every new version of the framework. The irony of this is we have Delphi applications that run on Vista better than the .NET applications. With Delphi I build and it links dependencies, I can copy just the executable to another machine and it just works, like magic. I guess I would say Microsoft needs to give us a linker or make the framework more backwards compatible.

Also I know if ILMerge (But it does not play well with third party assemblies at least that has been my experience)

http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx

My $0.02

You do make an interesting argument for Delphi.

vesuvius
Das Glasperlenspiel

In reply to sysrpl

#Sep 16th @ 5:19 AM

You do have valid arguments, and win some, lose some. People always think that just because some new language has come along, all the previous languages are obsolecsent.

Not if Regnwald has anything to do with it Big Smile

I am lucky enough to have programmed MSM Server/Mumps, Delphi, then C++ and finally C#/Visual Basic. For all these languages, there are some very big companies here in the UK still harnessing all of them, even as I write this post.

Thus far programming wise, I miss less using .NET though, being a full on WPF developer (dayjob). I still think Windows Forms was and is harder than WPF, and all these people diminishing Winforms developers have a thing to learn or two. WPF itself is riddled with bugs at present (.NET 3.5) and will take a few more iterations before it fully realises it's potential.

Software changes do not happen overnight, whatever the language. You are probably in a unique position in that you can judge the best tools (be it delphi or whatever) for the job, and not choosing tech because it is the latest and greatest. Thats not to say one cannot use something new, because in some situations there is a business need to use Silverlight for example, but Stack Overflow is an awsome website and all written in pure HTML and dollops of AJAX.

You are a leader and not a follower.

Dexter

In reply to Sven Groot

#Sep 16th @ 11:46 AM

Nope, type libraries are not required but yes, if you don't have the type library you need either the C/C++ header or the IDL file. And if you have any of these 3 you can use a COM component from C#.

To make it short: it is possible to use a COM object from C# even if you don't have a typelib and even if the object doesn't implement IDispatch.