Entwickler-Ecke
Andere .NET-Sprachen - Namespaces in Delphi.Net
winx - Mo 17.10.05 21:38
Titel: Namespaces in Delphi.Net
Hi,
wer kann mir das Prinzip der Namespaces und wie ich sie verwende erklären???
Wie muß ich meine
-Projektgruppen
-Projekte
-Klassen
damit das alles eine Struktur bekommt (vielleicht ein Beispiel???)?
Vielen Dank,
winx
AndyB - Di 18.10.05 13:07
Titel: Re: Namespaces in Delphi.Net
 winx hat folgendes geschrieben: |
| -Projektgruppen |
GroupName.bdsgroup (Schlagmichtot.bdsgroup)
MyCompany.MyPackage.bdsproj (Jedi.Jcl.bdsproj)
MyNamespace.UnitName.pas (Jedi.Jcl.JclSysUtils)
winx - Di 18.10.05 13:28
und wie muß ich dann von außen eine Klasse ansprechen:
So?
MyCompany.MyPackage.MyNamespace.UnitName ???
Christian S. - Di 18.10.05 14:09
Hallo!
Seit Delphi 2005 gilt für die Namespaces folgende Regel: Wenn Du eine .pas-Datei mit dem Namen "teil1.teil2.teil3.name.pas" hast, dann ist der Namespace dieser Datei "teil1.teil2.teil3". Also immer das, was vor dem letzten Punkt (von dem ".pas" mal abgesehen) steht.
Wichtig: In der Uses-Klausel gibst Du aber trotzdem den kompletten Dateinamen an, wie Du es gewohnt bist.
IIRC war es bei Delphi 8 anders, aber wen interessiert schon Delphi 8 :D
Grüße
Christian
winx - Di 18.10.05 14:40
Danke, programmiert du dann schon richtig mit Delphi.Net, bin mämlich noch am probieren und traue der Sache noch nicht so ganz...
Muß man die Projektdatei auch irgendwie benennen oder spielt das dann keine Rolle?
winx - Di 18.10.05 15:19
Und wie waren deine Erfahrungen mit Delphi.Net? Hast du noch die VCL benutzt?
Sind noch sehr viele Bugs vorhanden???
Christian S. - Di 18.10.05 15:33
Hallo!
Nein, die VCL nutze ich nicht, ist ein reines WinForms-Projekt.
Die Erfahrungen mit Delphi 2005 waren durchaus positiv. Ich fand es angenehm damit zu arbeiten. Allerdings gibt es auch ein paar Dinge, die nerven, wenn man z.B. System.Windows.Forms.DialogResult.OK schreiben muss anstatt DialogResult.OK schreiben zu können. An einigen Stellen ist der Delphi-Compiler einfach "dumm". Das hat mich in einem Thread hier im Forum mal dazu verleitet, zu sagen, beim nächsten Mal würde ich C# nehmen.
Aber auch da gibt es ein paar nervige Dinge, sodass ich inzwischen wohl nicht mehr uneingeschränkt zu dieser Aussage stehen würde, sondern die Wahl zwischen Delphi und C# schwer fallen würde.
Was Bugs angeht, so muss ich sagen, dass Delphi 2005 mit allen drei Updates absolut für den Produktiveinsatz geeignet ist. Mir fällt auf Anhieb nichts ein, was mich stören würde. Programmierer, die einen größeren Teil der Funktionen von D2k5 nutzen als ich, werden aber wahrscheinlich auch mehr Bugs sehen und evtl. zu einem anderen Urteil kommen.
Grüße
Christian
AndyB - Di 18.10.05 18:48
| Christian S. hat folgendes geschrieben: |
| System.Windows.Forms.DialogResult.OK |
Ein Grund, warum ich mir da immer einen Alias-Namen anlege.
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
| type
DlgResult = DialogResult;
procedure TWinForm.Button1_Click(sender: System.Object; e: System.EventArgs);
begin
if MessageBox.Show('Hallo World!', 'MyApp', MessageBoxButtons.OKCancel) = DlgResult.OK then
...
end; |
Das macht das Leben schon viel angenehmer.
Der Unterschied zwischen Delphi.NET und C# liegt hierbei einfach darin, dassn in C# ein Typ vor dem "auto-this" kommt. Wenn man also in C# auf die Forms Eigenschaft DialogResult zugreifen möchte, dann muss man this.DialogResult schreiben.
Bei beiden Varianten ist der Vorteil aber auch der Nachteil. Das hängt halt immer vom jeweiligen Kontext ab. (die C#-Variante ist aber dahingehend besser dass "this." einfach kürzer zu schreiben ist als "System.Windows.Forms."
winx - Mi 19.10.05 08:28
Hi,
schön zu hören das eure Erfahrungen mit Delphi2005 (auch mit den WinForms) durchwegs positiv sind :-)
Habt ihr auch schon probiert ein Delphi7 Projekt in Delphi.Net zu importieren???
Danke
Robert_G - Mo 24.10.05 01:55
| AndyB hat folgendes geschrieben: |
Der Unterschied zwischen Delphi.NET und C# liegt hierbei einfach darin, dassn in C# ein Typ vor dem "auto-this" kommt. Wenn man also in C# auf die Forms Eigenschaft DialogResult zugreifen möchte, dann muss man this.DialogResult schreiben.
Bei beiden Varianten ist der Vorteil aber auch der Nachteil. Das hängt halt immer vom jeweiligen Kontext ab. (die C#-Variante ist aber dahingehend besser dass "this." einfach kürzer zu schreiben ist als "System.Windows.Forms." |
Öhm wer hat dir denn das erzählt? Ich lasse mir das "this." sogar autom. von einem AddIn entfernen wenn es unnötig ist[meta]stört irendwie beim lesen...[/meta].
Das hier funktioniert absolut problemlos in C#
C#-Quelltext
1:
2:
3:
4:
5:
6:
| private void okButton_Click(object sender, EventArgs e)
{
String String = "Hallo";
Text = String;
DialogResult = DialogResult.OK;
} |
oder in Chrome:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
| method MainForm.okButton_Click(sender: Object; e: EventArgs);
begin
var String := 'Hallo';
Text := String;
DialogResult := DialogResult.OK;
end; |
Sollte eigentlich auch klar sein. Wenn ich, als fehlbarer Mensch, sofort erkennen kann kann, dass hier eine Property mit der Konstante DialogResult.OK besetzt wird, sollte es der Compiler schon 10-mal wissen. ;)
Die Art der Verwendung schließt doch schon aus, dass es ein Typ ist, somit muss der Compiler nur noch schauen, ob es eine passende Variable/Property/Feld gibt. ;)
btw: @Christion, es geht auch
&DialogResult.OK Nicht schön, aber kürzer... ;)
AndyB - Di 25.10.05 09:34
[quote="
Robert_G"]Öhm wer hat dir denn das erzählt? Ich lasse mir das "this." sogar autom. von einem AddIn entfernen wenn es unnötig ist[meta]stört irendwie beim lesen...[/meta].
Falsche Annahme meinerseits. Ich habe jetzt schon fast ein 3/4 Jahr nicht mehr mit C# gearbeitet (native Anwendungen werden halt immernoch bevorzugt gewünscht).
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!