Announcement

**Andreas Kosch** · 08.01.2005, 16:55

Bug: Von einer Zeichenkette werden nur die ersten 4 Zeichen verwendet 
Plattform: Delphi.NET (FCL) 
Kategorie: Show Stopper 
Version: Delphi 2005 Architect (engl.) Update#1
Die Klassen aus dem .NET Framework sowie der Gro�teil der im Umlauf
befindlichen Assemblies wurden in der Sprache C# geschrieben. Daher ist es f�r
Delphi.NET essentiell, mit C#-Assemblies problemlos zusammenzuarbeiten.
Schritt 1: Delphi 2005 Update#1: Neues C# Class Library-Projekt
Die folgende Mini-Class Library (ConstString.dll) ver�ffentlicht nur eine
Zeichenkette �ber eine �ffentlich sichtbare Membervariable:
<pre>using System;
 
namespace ConstString
{
public class OSConstStr
{
public OSConstStr()
{
}
 
public const string sOS = "OssiSoft";
}
}</pre>
Die Class Library wird mit Delphi 2005 Update#1 zur Assembly ConstString.dll
kompiliert. Da Delphi 2005 an dieser Stelle auf den originalen Microsoft-Kommandozeilen-Kompiler aus dem .NET Framework zur�ckgreift, wird die C#-Assembly fehlerfrei erstellt.
Schritt 2: Delphi 2005 Update#2: Neue Delphi.NET Windows Forms Application
- Projekt der gleichen Projektgruppe zuordnen 
- References | Add Reference... | Project References: Assembly des C#
Class Library-Projekts ausw�hlen 
- Namespace ConstrString der uses-Auflistung hinzuf�gen 
<pre>uses
System.Drawing, System.Collections, System.ComponentModel,
System.Windows.Forms, System.Data, ConstString;</pre>
- String-Wert aus der C# Class Library auslesen: 
<pre>procedure TWinForm.Button1_Click(sender: System.Object; e: System.EventArgs);
var
sTemp : String;
begin
sTemp := OSConstStr.sOS;
MessageBox.Show(sTemp);
end;</pre>
- Erwartet: Die MessageBox zeigt die Zeichenkette "OssiSoft" an 
- Delphi 2005-Ergebnis: Die MessageBox zeigt nur die
ersten 4 Zeichen der Zeichenkette an
 
Eventuell ist das beabsichtigt, dass ich als Th�ringer nur den Text "Ossi" zu Gesicht bekomme ;-)
 
Schritt 3: Gegenprobe mit Visual Studio .NET 2003
- Die MessageBox zeigt die Zeichenkette "OssiSoft" korrekt an
Die angeh�ngte Abbildung zeigt das Verhalten:
P.S: Ein Beispiel f�r das Verst�mmeln von Zahlen in Win32-Anwendungen habe
ich im FORUM bereits vorgestellt. Es gibt f�r die Win32-Fans an dieser Stelle kein Grund zur Schadenfreude, auch das eigene Spielfeld ist betroffen ;-)</p&gt

**Andreas Kosch** · 08.01.2005, 16:58

Bug: Eine BDP.NET-Verbindung kann keine UNICODE-Zeichen aus der Datenbank
auslesen 
Plattform: .NET (BDP.NET) 
Kategorie: Show Stopper 
Version: Delphi 2005 Architect (engl.) Update#1
Schritt 1: Vorbereitung in der Datenbank (MS SQL Server 2000)
<pre>USE tempdb
GO

CREATE TABLE D2005TEXT
(
recid INTEGER NOT NULL IDENTITY PRIMARY KEY,
wert1 VARCHAR(19) NOT NULL DEFAULT 'Umlaute: �� ',
wert2 TEXT
)
GO
INSERT INTO D2005TEXT (wert2) VALUES ('Das ist ein Test.')
INSERT INTO D2005TEXT (wert2) VALUES ('Das ist ein 2. Test: ��')
INSERT INTO D2005TEXT (wert2) VALUES ('Das ist ein 3. Test: ��')
GO
SELECT * FROM D2005TEXT
GO
 
CREATE TABLE D2005NTEXT
(
recid INTEGER NOT NULL IDENTITY PRIMARY KEY,
wert1 NVARCHAR(19) NOT NULL DEFAULT N'Umlaute: �� ',
wert2 NTEXT
)
GO
INSERT INTO D2005NTEXT (wert2) VALUES (N'Das ist ein Test.')
INSERT INTO D2005NTEXT (wert2) VALUES (N'Das ist ein 2. Test: ��')
INSERT INTO D2005NTEXT (wert2) VALUES (N'Das ist ein 3. Test: ��')
INSERT INTO D2005NTEXT (wert1,wert2) VALUES (N'N', N'N')
GO
SELECT * FROM D2005NTEXT
GO
</pre>
Schritt 2: Anzeige im Data Explorer von Delphi 2005 Update#1:
- Umlaute werden korrekt anzeigt 
- Bug: Unicode-Zeichen in der
NVARCHAR-Spalte werden nicht angezeigt, sondern durch 
Fragezeichen ersetzt 
- Bug: Zeichenkette (egal welcher Art) in
der TEXT bzw. NTEXT-Spalte werden �berhaupt nicht angezeigt 
Schritt 3: Delphi 2005 Update#1: Neues FCL-Projekt greift �ber BDP.NET auf
die Tabellen zu
- Anzeige im DataGrid (BdpConnection, BdpDataAdapter, DataSet, DataView,
DataGrid) 
- Umlaute werden korrekt anzeigt 
- Bug: Unicode-Zeichen in der
NVARCHAR-Spalte werden nicht angezeigt, sondern durch 
Fragezeichen ersetzt 
- Bug: Zeichenkette (egal welcher Art) in
der TEXT bzw. NTEXT-Spalte werden �berhaupt nicht angezeigt 
Schritt 4: Gegenprobe mit Visual Studio .NET 2003
- Umlaute werden korrekt anzeigt 
- Unicode-Zeichen werden korrekt angezeigt
 
- TEXT/NTEXT-Inhalt wird korrekt angezeigt

Siehe angeh�ngte Abbildung
Workaround: Auf BDP.NET verzichten, nur die originalen ADO.NET-Klassen aus
dem .NET Framework nutzen
 </p&gt

**Andreas Kosch** · 08.01.2005, 17:00

Bug: Ein VCL-Projekt wird nur unvollst�ndig zu einem VCL.NET-Projekt
konvertiert 
Plattform: Delphi.NET (VCL.NET) 
Kategorie: Nicht rechtzeitig fertig geworden 
Version: Delphi 2005 Architect (engl.) Update#1
Delphi 5/6/7-Projekt einer VCL-Anwendung �ffnen und als VCL.NET-Projekt
konvertieren lassen
- Korrekt: Eintrag �DelphiDotNet.Personality� in der *.bdsproj-Datei 
- Bug 1: Das Icon ist verschwunden und muss
neu zugewiesen werden 
- Bug 2: Delphi 2005 verwendet den
Win32-Formulardesigner 
- Bug 3: Delphi 2005 verwendet die
Win32-Komponenten in der Toolpalette 
- Bug 4: Das 
STAThread-Attribut wurde der Projektdatei 
nicht hinzugef�gt! 
- Bug-Beispiel: 
 a) TRvProjekt-Komponente
(d.h. die "alte" Win32-Komponente) wird auf dem Formular abgelegt 
 b) Project | Build: Kompilerveto F1026 File not
found: 'RpDefine.dcuil' 
Workaround: Die fehlenden Schritte von Hand nachholen
1. Projekt in Delphi 2005 schlie�en ohne zu speichern 
2. Projekt neu �ffnen 
3. Project | View Source: STAThread-Attribut
von Hand nachtragen 
<pre>[STAThread]
begin
Application.Initialize;
Application.Title := 'BorNews';
Application.CreateForm(TFormMain, FormMain);
Application.Run;
end.</pre>
4. Projekt in Delphi 2005 schlie�en, dabei die �nderungen speichern 
5. Im Windows-Explorer von Hand nachtr�glich die Dateiendung 
*.dfm der Datenmodule/Formulare in 
*.nfm �ndern 
6. Im Windows-Explorer von Hand nachtr�glich in den dazugeh�renden
pas-Dateien der Datenmodule/Formulare die Zeile $R *.dfm
in $R *.nfm �ndern. 
7. Das Projekt erneut in Delphi 2005 �ffnen: 
8. Erst nach dieser manuellen Reparatur zeigt Delphi 2005 den VCL.NET-Designer
sowie den VCL.NET-Inhalt der Tool Palette an
Siehe angeh�ngte Abbildung</p&gt

**Andreas Kosch** · 08.01.2005, 17:03

Bug: Die Resourcestring-Informationen werden mit "M�ll-Zeichen" verfremdet 
Plattform: Win32 
Kategorie: Sch�nheitsfehler 
Version: Delphi 2005 Architect (engl.) Update#1
Beispiel: Verst�mmelte Anzeige von LegalCopyright,
die mit jedem Speichern anw�chst 
Siehe angeh�ngte Abbildung</p&gt

**Andreas Kosch** · 08.01.2005, 17:15

Bug: Kein Datenbankverbindungs-Pool f�r BDP.NET 
Plattform: .NET (BDP.NET) 
Kategorie: Fehlende Funktionalit�t 
Version: Delphi 2005 Architect (engl.) Update#1
Bei allen zustandslosen Anwendungen (ASP.NET, XML Web Service, .NET Remoting,
.NET Enterprise Services) ist es wichtig, dass eine Datenbankverbindung
innerhalb jeder aufgerufenen Methode so schnell wie nur m�glich aufgebaut werden
kann. Die originalen ADO.NET-Verbindungsklassen aus dem .NET Framework stellen
daher einen Pool zur Verf�gung, die BDP.NET-Klassen jedoch nicht (einzige
Ausnahme: BDP.NET greift auf den MS SQL Server via COM Interop auf den "alten"
OLE DB-Provider zu, und OLE DB stellt einen eigenen Datenbankverbindungs-Pool
zur Verf�gung).
Diese Funktion fehlt in den folgenden Versionen:
- C#Builder 1.0 (BDS 1.0) 
- Delphi 8 (BDS. 2.0) 
- Delphi 8 Update#1 (BDS. 2.0) 
- Delplhi 8 Update#2 (BDS. 2.0) 
- Diamondback (BDS 3.0) 
- Delphi 2005 (BDS 3.0) 
- Delphi 2005 Update#1 (BDS 3.0) 
Ergebnis: Der Verbindungsaufbau ist mit BDP.NET um Gr��enordnungen langsamer
als bei ADO.NET. Im Fall von ADO.NET ist nur der 1. Verbindungsaufbau messbar, alle nachfolgenden Aufrufe werden vom Pool bedient. Im Fall von BDP.NET wird der fehlende Pool zum Beispiel beim Zugriff auf den Borland InterBase 7.x deutlich bemerkbar.
Workaround
- Alternative A: Anstelle von BDP.NET die nativen ADO.NET-Komponenten aus dem
.NET Framework nutzen 
- Alternative B: Die Server-Hardware einige Nummern gr��er kaufen, um den
langsamen Verbindungsaufbau zu kompensieren
Siehe angeh�ngte Abbildung</p&gt

**Andreas Kosch** · 08.01.2005, 17:40

Bug: Delphi.NET legt einen falschen PUBLIC KEY TOKEN  im Manifest ab 
Plattform: Delphi.NET 
Kategorie: Show Stopper 
Version: Delphi 2005 Architect (engl.) Update#1
Der Bug ist in den folgenden Versionen nachweisbar:
- Delphi 8 (BDS 2.0) 
- Delphi 8 Update#1 (BDS 2.0) 
- Delphi 8 Update#2 (BDS 2.0) 
- Diamondback (BDS 3.0) 
- Delphi 2005  (BDS 3.0) 
- Delphi 2005 Update#1 (BDS 3.0) 
Bug reproduzieren
1. Delphi.NET Package Projekt anlegen 
2. Klasse f�r einen .NET Enterprise Service nachr�sten 
<pre>unit D8ESPackageObj;
 
interface
 
uses
System.Reflection,
System.EnterpriseServices,
System.Runtime.InteropServices,
System.Data,
System.Data.SqlClient,
System.Text.RegularExpressions;
 
type
ID2005ESPerfPackageObj = interface
function ObjVersion: Integer;
function GetDataSetKunden(kunden_id: Integer): DataSet;
function GetFirst500Kunden: DataSet;
function ConnectionString(iMode: Integer): String;
end;
 
[TransactionAttribute(TransactionOption.NotSupporte d),
ConstructionEnabled(Default='(local),tempdb,sa,sa'),
JustInTimeActivation(True),
EventTrackingEnabled(True),
DescriptionAttribute('Delphi 2005 .NET Enterprise Services Package-Version'),
Guid('20C89F4B-A61C-4828-B027-A8122E26C092'),
ClassInterface(ClassInterfaceType.None)]
TD8ESPerfPackageObj = class(ServicedComponent, ID2005ESPerfPackageObj)
private
FConstructString: String;
FCSADO : String;
FCSADONET : String;
FBDPNET : String;
protected
procedure Construct(constructString: String); override;
public
function ObjVersion: Integer;
function GetDataSetKunden(kunden_id: Integer): DataSet;
function GetFirst500Kunden: DataSet;
function ConnectionString(iMode: Integer): String;
end;
 
implementation
 
...
</pre>

3. Package-Assembly kompilieren 
4. In der gleichen Projektgruppe einen FCL Windows Forms-Clientanwendung
einrichten, den .NET Enterprise Service dort aufrufen 
5. Projektgruppe kompilieren 
6. Client starten: Exception "The located assembly's
manifest definition... does not match the assembly reference". 
Ursache �ber das Microsoft-Tool Assembly Binding Log
Viewer suchen 
- FUSLOGVW.EXE starten 
- Client-Programm starten -> Exception -> FUSLOGVW.EXE zeigt einen Eintrag an 
- Doppelklick auf diesen Eintrag
<pre>...
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
ERR: The assembly reference did not match the assembly definition found.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
</pre>
Fehlersuche mit dem IL Disassembler (ildasm
D2005CltD8ESPerfPackage.exe)
<pre>.assembly extern D2005ESPerfPackage
{
.publickeytoken = (B8 1A 9F 0C 00 00 00 00 )
.ver 2:0:0:0
}</pre>
Gegenprobe: Delphi 2005-Package in einen VS.NET 2003 C#-Client einbinden 
VS.NET bindet den korrekten
publickeytoken-Wert in das Manifest ein und kann daher den Delphi 2005 .NET
Enterprise Service problemlos aufrufen:
<pre>.assembly extern D2005ESPerfPackage
{
.publickeytoken = (8E 99 11 D5 B1 50 4E DD ) // .....PN.
.ver 2:0:0:0
}</pre>
Siehe angeh�ngte Abbildun

**J�rgen Hofmann** · 08.01.2005, 18:20

Lieber Andreas,
vielen Dank f�r die ausf�hrlichen Beispiele (ich glaube, ich war derjenige, der um "Butter bei die Fisch" gebeten hatte).
Ich bin gewiss der Letzte, der nun fordert, mit fliegenden Fahnen die Seiten zu wechseln. Daf�r habe ich zu lange und mit gro�er Zufriedenheit mit Delphi gearbeitet und zuviel Geld f�r Komponenten ausgegeben. Aber auch ich habe schon seit �ber einem Jahr Visual Studio auf meinem Rechner und mich bereits ganz leidlich eingearbeitet.

Ich glaube aber auch, dass wir noch eine ganze Zeit weiter mit Delphi Win32-Anwendungen erstellen k�nnen. Also sollten wir jetzt nicht in operative Hektik verfallen und in Ruhe darauf warten, wie die Szene sich entwickelt. Ich f�rchte aber auch, dass Delphi nicht mehr die Zukunft hat, die wir uns daf�r w�nschen w�rden. Auch eine Firma wie Borland kann es sich nicht dauerhaft erlauben, Entwickler vor den Kopf zu sto�en.

Was den Punkt des Austestens von Funktionen betrifft, so sehe ich das etwas anders: es kann nicht die Aufgabe des Entwicklers sein, z.B. jede Stringfunktion oder mathematische Funktion vor der Verwendung zu testen. Ich muss mich darauf verlassen k�nnen, dass das, was von Borland an Funktionen mitgeliefert wird, auch funktioniert. Daf�r sind professionelle Anwendungen einfach zu komplex. F�r mich fallen die Beispiele, die hier gegeben wurden, unter die Rubrik "Qualit�tssicherung", und von einem professionellen Tool, f�r das ich eine Menge Geld abliefern muss, verlange ich diese Qualit�tssicherung, bevor(!) es auf die Menschheit losgelassen wird (�brigens bekommt das Microsoft mit Visual Studio ja auch ganz gut auf Reihe). Ansonsten gibt es genug Compiler etc., die ich kostenlos im Public Domain-Bereich bekommen kann

**Andreas Kosch** · 18.01.2005, 07:18

Hallo,

inzwischen sind im Internet sogar Videos aufgetaucht, die einige Macken auf humorvolle Art und Weise (insbesondere die Hintergrund-Musik ist treffend gew�hlt) vorstellen ;-)

a) http://www.wiredred.com/d2005/package_errors.html

b) http://www.wiredred.com/d2005/cannot_resolve.html

c) http://www.wiredred.com/d2005/published_sets.html</i&gt

**J�rgen Hofmann** · 18.01.2005, 19:54

Hoffnung f�r Delphi 2005!

Wie bei c't nachzulesen, hat Borland die �bernahme der texanischen Consulting-Firma TeraQuest Metrics bekannt gegeben. TeraQuests Gesch�ftsschwerpunkt ist die Beratung von Unternehmen auf der Grundlage der Capability Maturity Model Integration (CMMI), einem Modell zur Verbesserung der Qualit�t von Produkt-Entwicklungsprozessen.

Bill Curtis, Mitbegr�nder und Chief Scientist von TeraQuest, soll bei Borland die neu geschaffene Position eines Chief Process Officer bekleiden.

Grund zum Jubeln: jetzt haben wir endlich einen Chief Process Officer (fr�her nannte man das "Senior Vice President for Something", zu Deutsch: "Fr�hst�cksdirektor"), der sich endlich die Qualit�t von Delphi 2005 k�mmert!!!! Kann man f�r die paar Euro, die es kostet, auch wirklich verlangen!

**Wolfgang Roller** · 21.01.2005, 22:40

Ich wollte heute meinen beiden Kollegen denn ersten der drei Links von Adreas Kosch zeigen, aber der Server kennt die Seite nicht mehr. :-(

Zufall oder wurde da mit dem Zaunpfahl gewunken?

Gru�

Wolfgan

**Knut Schoknecht** · 08.02.2005, 00:29

Bug hin, Bug her - bestimmte Dinge sollten einfach funktionieren. Auch f�r WIN32 !!

Die IBX-Komponenten funktionieren mit IBFB 1.5. Ausnahme in der IDE ist der Anweisungstexteditor f�r die SELECT Abfrage. Hier werden keine Feldnamen f�r die ausgew�hlte Tabelle angezeigt.

Auch verschwindet DELPHI bei der Ausf�hrung einer DATASET-Abfrage im NICHTS. Dioes tritt ebenfalls bei dem �ndern von Eigenschaften auf.

Bei dem einf�gen von Komponenten werden diese irgendwo auf dem Formular plaziert - nur nocht an die Stelle wo der Mauszeiger hinzeigt.

Ich bin mit DELPHI immer zufrieden gewesen. Stabilit�t, einfache Bedienung und die Flexibilit�t sind die St�rken (gewesen ???).
Ich bin eigendlich nur entt�uscht

**Andreas Kosch** · 08.02.2005, 16:13

Hallo,

>Auch verschwindet DELPHI bei der Ausf�hrung einer DATASET-Abfrage im NICHTS. 
>Dies tritt ebenfalls bei dem �ndern von Eigenschaften auf.

dieser Effekt kann im Worst Case bei sehr vielen Operationen auftreten. Bei einem Stack-�berlauf wird der Prozess automatisch von Win32 entsorgt, so dass die IDE ohne jede M�glichkeit zur Gegenwehr sofort verschwindet. Die Installation vom Update#1 scheint die H�ufigkeit dieses Problems zu erh�hen.

Wer neugierig ist und die ausl�sende Stelle ermitteln m�chte, kann Delphi 2005 im visuellen Debugger (Microsoft CLR Debugger) aus dem .NET Framework SDK laufen lassen (C:\Programme\Microsoft.NET\SDK\v1.1\GuiDebug\D bgCLR.exe). Sobald es knallt, ist im besten Fall der �belt�ter zu sehen

Announcement

Der Delphi 2005-Streichelzoo

Der Delphi 2005-Streichelzoo

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment