Olaf’s Thoughts About Development

If creating IW controls dynamically, then always be sure to explicitly set their Name. They won’t always get a default name – and empty names may lead to strange behaviors.

If you create IWRadioButtons dynamically, then also be careful that you always set their “Name” and “Value” properties to the same value – unless you know what you are doing. Value is important for correct control and group recognition during postbacks. Sounds odd but has to do with the way how the underlying INPUT HTML controls are working.

Unfortunately, at least in IntraWeb 9.0, IWRadioButtons synchronize Name and Value at design-time only (no idea why – I cannot remember having touched that during my time at Atozed). The attached IWComRadioButton source file fixes that, so that you only have to care about “Name”.

Note: That file is for IntraWeb 9.0. It may work with older or newer versions, but I did not test that. This is not an official file version, but just a personal contribution to the freely available visual control source files of IntraWeb. Use modified sources at your own risk – the guys at Atozed can support their own versions only.

According to Mike Nash, Microsoft’s Windows Product Manager, there will be a release called “Windows 7” anytime soon (or less sooner).

So I guess that’s somehow a service release for Windows 3.11, as Windows 3.11 was followed by Windows 95 (RIP) a couple of years ago.

If I’m wrong though and Windows 7 is supposed to be the successor of Windows Vista, then I wonder what the product management and marketing department of MS is smoking these days, with Windows 2003, 2008 on the market already …

Anyway, good that CodeGear was wise enough to not remove the Win 3.1 components. They are still there, even in Delphi 2009

There are a lot of new things to learn with Delphi’s new Unicode string type(s). For example look at Lars’ blog. Quite some interesting posts over the last days.

Apparently, the new Delphi 2009 TStringBuilder class has not got much attention yet, so I’ll give a short recap here.

Read the rest of this entry »

This is an announcement for a CodeGear Webinar about using .NET with Delphi Win32. This seminar will be held in German language.

Am 14.10.2009 um 10:00 (MESZ) werde ich in Zusammenarbeit mit Embarcadero/CodeGear Deutschland ein (kostenloses) Online-Seminar abhalten in dem das Verwenden von .NET Funktionen aus Delphi Win32 vorgestellt werden wird.

Die Veranstaltung wird über das Embarcadero LiveMeeting-System durchgeführt. Hier geht es zur Anmeldung.
(Die Freischaltung erfolgt 15 vor Beginn)

Um vor der Veranstaltung den LiveMeeting Client zu installieren und/oder zu testen klicken Sie bitte hier.

Inhalt:

Wer native Windows 32 (und später ggfs. Win64) Anwendungen mit Delphi  erstellt, kann sich in der Regel auf schnellen, stabilen Code und kurze,  effektive Entwicklungszyklen einstellen. Es gibt eine reichhaltige, in  Delphi integrierte und durch zahlreiche Dritthersteller verstärkte  Komponentenbibliothek mit der sich die unterschiedlichsten Probleme  lösen lassen.

Es gibt jedoch manchmal Situation, wo man als "nativer"  Delphi-Entwickler auf das .NET Framework schielt, weil dort eine noch  viel größere Klassenbibliothek – in großen Teilen sogar kostenlos – zur  Verfügung steht und ein anstehendes Problem dort bereits eine Lösung  hat. Deswegen das ganze Projekt nach .NET zu portieren (sei es nun  Dlephi.NET oder VisualStudio/C#/VB.NET) ist jedoch meist nicht  vertretbar – was also tun?

Interessanterweise gibt es Schnittstellen zwischen .NET und Win32  Anwendungen, die es erlauben, aus Win32 Anwendungen auf .NET Funktionen  zuzugreifen.

Die Standard-Schnittstelle ist hier COM/Interop, allerdings dürfte das  viele Entwickler eher abschrecken. Mit "Managed-VCL" und "Hydra"  existieren zwei 3rd Party Produkte, die gewohnt Delphi-komfortable  Schnittstellen zur Verfügung stellen. Diese Lösungen sind leistungsfähig  aber kostenpflichtig.

Als wenig bekannte Schnittstelle bietet sich zusätzlich "Reverse  P/Invoke" an, was für für C#/C++ Entwickler recht mühselig ist (und  daher vermutlich kaum verbreitet). Für Delphi User ist das jedoch extrem  simpel einsetzbar, da das notwendige "Brimborium" komplett vom  Delphi-Compiler versteckt wird.

Diese Session wird die drei genannten Alternative vorstellen und mit  praktischen Beispielen zeigen, wie man z.B. Winforms oder  .NET-Verschlüsselungsroutinen aus Delphi für Win32 nutzt.

As I recently noticed and already mentioned by Jim McKeeth Delphi made it back into the Top Ten of TIOBE’s Programming Community Index. Actually “we” are Ninth!

Read the rest of this entry »

You may have noticed that Delphi 2009 includes Win32 (Delphi and C++) personalities only. The .NET part has obviously been scheduled for later.

For those of you being curious how the next Delphi for .NET might look like:

CodeGear just “inofficially” announced a Delphi Prism Beta which is basically something like Delphi in Visual Studio. Nick Hodges showed off some early information at SDN in the Netherlands.

Allen Bauer also comments on these, maybe surprising news. So far it looks like in the future there will be two Delphi products, one for Win 32 Development (in the IDE we all know), and an other VisualStudio based IDE for .NET development.