Konstruktoren in C# und der Umstieg Delphi -> C#

Hallo, vorne weg: ich komme von Delphi. Kann also sein, dass ich noch etwas durcheinander denke. Nun mein Problem. Habe folgendes Konstrukt:

	public class WebSession
	{
		private HttpSessionState Session;

		public WebSession(HttpSessionState TheSession)
		{
			Session = TheSession;
		}
...

Dort will ich einige Automatismen mit Sessions anstellen (Null-Check bevor ich einen Wert holen, Wandlungen etc.). Wenn ich die Klasse benutzen möchten:

private WebSession SCContr = new WebSession(Page.Session);

bekomme ich immer die Compiler-Meldung:

[C# Error] Input.ascx.cs(22): 'System.Web.UI.Control.Page' denotes a 'property' where a 'class' was expected

Was soll das? Was ist falsch?

Hallo tomaten,

das bedeutet, genau was dasteht: Page ist eine Eigenschaft (einer Klasse), aber an dieser Stellen wird ein Klassenname (oder der Name einer Variable dieser Klasse) erwartet.

herbivore

Original von herbivore
Hallo tomaten,

das bedeutet, genau was dasteht: Page ist eine Eigenschaft (einer Klasse), aber an dieser Stellen wird ein Klassenname (oder der Name einer Variable dieser Klasse) erwartet.

herbivore

🤔 Die erforderliche Varaible ist vom Typ HttpSessionState und Page.Session auch. Page.Session ist ein Variablenname dieses Klassentyps. Oder kurzum, wie bekomme ich die in ASP.NET ständig verfügbare "Session" an meine Klasse übergeben. Vielleicht reden wir ja aneinander vorbei!?

Hallo tomaten,

dann fehlt vor Page noch das Objekt auf dessen Page-Eigenschaft du zugereifen willst.

herbivore

Original von herbivore
Hallo tomaten,

dann fehlt vor Page noch das Objekt auf dessen Page-Eigenschaft du zugereifen willst.

herbivore

Ich steh voll auf dem Schlauch!

Das ganze befindet sich innerhalb von:

	public abstract class CardealerInput : System.Web.UI.UserControl
	{
		private WebSession SCContr = new WebSession(Page.Session);

Dort ist sowohl "Page" als auch direkt "Session" im Code ansprechbar. Ich kann es wohl als Delphianer nicht verstehen, aber wenn ich was benutzen kann, kann ich es auch als Variable übergeben! Any Code please. bettel

Das witzige ist, hier funktioniert es 🙁 :

    private void Page_Load(object sender, System.EventArgs e)
    {
        WebSession SCContr = new WebSession(Session);

Hallo tomaten,

probier es mal mit

public abstract class CardealerInput : System.Web.UI.UserControl
    {
        private WebSession SCContr;
        public CardealerInput ()
        {
           SCContr = new WebSession(Page.Session);

herbivore

Hallo tomaten,

naja, dann ist es doch aber auch klar. In dem Code von 21:57 steht Page.Session im Kontext der Klasse. Im Code von 22:06 steht Page.Session im Kontext des aktuellen Objekts. Und da Page eine Eigenschaft des Objekts ist ...

herbivore

Muss ich beim überschreiben des Konstruktor nicht den originalen Konstruktor aufrufen. Es wird so zwar kompiliert aber gibt beim Aufruf einen Fehler.

Original von herbivore
Hallo tomaten,

naja, dann ist es doch aber auch klar. In dem Code von 21:57 steht Page.Session im Kontext der Klasse. Im Code von 22:06 steht Page.Session im Kontext des aktuellen Objekts. Und da Page eine Eigenschaft des Objekts ist ...

herbivore

Das kann ja noch heiter werden mit C# von Delphi kommend. Klasse <> Objekt <> Instance? 8o

Noch eine OT-Frage. Gibt es in C# ein ähnliches Sprachkonstrukt wie:

with Anything do
prodecure or property from Anything

???

Hallo tomaten,

Konstruktoren können nicht überschrieben werden, da Konstruktoren nicht vererbt werden. Aber wenn du in der Unterklasse einen Konstruktor definierst, wird so oder so ein Konstruktor der Oberklasse aufgerufen. Welcher bestimmst du durch die Parameter, die du hinter ': base' angibst.

herbivore

Hallo,

ich fasse hier beide Codeauschnitte nochmal kurz zusammen.

1. (funktioniert)

public abstract class CardealerInput : System.Web.UI.UserControl
{
    private WebSession SCContr = new WebSession(Page.Session);
   
    // ...
}

2. (funktioniert nicht)

public abstract class CardealerInput : System.Web.UI.UserControl
{
    private WebSession SCContr;

    public CardealerInput() {
        SCContr = new WebSession(Page.Session);
    }

    // ...
}

Grundlegendes Problem ist mal ganz klar der Namenskonflikt zwischen der Eigenschaft System.Web.UI.Control.Page und der Klasse System.Web.UI.Page. Du willst hier auf die Klasse zugreifen, allerdings wird bei Namen immer möglichst "lokal" gesucht und somit zuerst die Eigenschaft gefunden, welche natürlich nicht passt.

Um das Problem zu beheben, könntest du jetzt entweder die 1. Version oben benutzen, oder die Klasse Page "umbenennen". Zum Beispiel so:

using UIPage = System.Web.UI.Page;

// ab hier einfach UIPage benutzen

Noch kurz erklärt warum die 1. Version dennoch funktioniert:

Beim Initialisieren von Feldern erhalten diese ja erstmals ihren Wert. Sobald die Feldinitialisierer ausgeführt werden ist der Konstruktor noch nicht aufgerufen worden und somit das Objekt ansich noch nicht erstellt. Darum sind beim Initialisieren Zugriffe auf das eigene Objekt verboten. Der Compiler weiß, dass dieser Zugriff verboten ist und zieht somit die Eigenschaft System.Web.UI.Control.Page gar nicht in Betracht passend sein zu können, da sie einfach noch ungültig ist. Somit bleibt nur noch System.Web.UI.Page über.

Hoffe ich konnte das entsprechend rüberbringen 🙂

Aha, siehst in Delphi kann man die wohl überschreiben. Naja, man gewöhnt sich an alles. Bis auf dieses kleine Problem bin ich mit C# ganz zufrieden. Endlich Schluss mit stundenlangen Deklarationen. Einfach den Code ordentlich am Stück schreiben macht schon Spass.

Hallo tomaten,

so ein with-Konstrukt gibt es meines Wissens nicht.

herbivore

@Bernhard

Ja so langsam schnall ich das. Das blöde an C# ist, das Klassen und ihre Instanzen meist den gleichen Namen haben. In Delphi ist das einfacher. Die Klasse in hat in der Definition immer ein "T" davor, also "TPage = class ..." und dann die Instanze "Page: TPage". So kann man das klarer auseinander halten!

Schade, muss man immer:

Klasse.Property1 = ;
Klasse.Property2 = ;
Klasse.Property3 = ;
Klasse.Property4 = ;

anstatt:

with Klasse do
begin
    Property1 = ;
    Property2 = ;
    Property3 = ;
    Property4 = ;
end;

schreiben! 🙁

Btw. hab etwas voreilig geschrieben, die erste Version funktioniert ebenfalls nicht. Hab den Compiler überschätzt und
war bis eben grade selbst zu faul um es auszuprobieren. Er findet also trotzdem System.Web.UI.Control.Page.

Ach ja wenn du dieses with und das restliche Delphi-Zeugs so sehr vermisst, dann verwend halt
einfach Delphi.NET oder wozu ich dir eher raten würde VB.NET (was ja z.B With ebenfalls besitzt).

Bevor ich jemals VB.NET verwende, hack ich mir die Finger ab! 😉 Ich benutze seit Delphi 1 vor 10 Jahren Delphi. Zu C# will ich doch nur "Wechseln" (bei neuen Projekten) um etwas kompatibler in der neuen schönen M$.NET Welt zu sein. Nein ehrlich, bei Delphi.NET haben die einiges verbockt bei der .NET Implementierung. Habe selbe schon 2 echt kritische Bugs gemeldet (z.B. werden static const auf 8 Zeichen gekürzt!).

Nachtrag: Und weil ich das Zusammenlegen von Deklaration und Implementation schön finde. Geht viel flüssiger als die tagelange Scrollerei!

Original von tomaten
@Bernhard

Ja so langsam schnall ich das. Das blöde an C# ist, das Klassen und ihre Instanzen meist den gleichen Namen haben. In Delphi ist das einfacher. Die Klasse in hat in der Definition immer ein "T" davor, also "TPage = class ..." und dann die Instanze "Page: TPage". So kann man das klarer auseinander halten!

In .NET gibt es halt andere Namenskonventionen als bei Delphi:

http://msdn.microsoft.com/library/deu/default.asp?url=/library/DEU/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp

Um bei deinem Beispiel zu bleiben: Instanzen beginnen mit mit einem Kleinbuchstaben, so ist die Verwechslung mit einem Typ ausgeschlossen.

Anders sieht das natürlich bei Typen und Membern aus. Beide die gleiche Schreibweise. Halte ich aber für weniger kritisch als Klasse/Instanz.

Original von svenson
In .NET gibt es halt andere Namenskonventionen als bei Delphi:

Man gewöhnt sich an alles. Danke für den Link. Die ganze C# Referenze durchzublättern ist schon etwas umständlich. Und mein Buch erwähnt nur am Rand C#, da ich hauptsächlich WebAnwendungen erstelle (z.Zt. noch mit einem Win32 Clone von ASP.NET für Delphi) und das Buch hauptsächlich ASP.NET behandelt.

Besonders lustig ist nur, wenn sich MS selbst nicht dran hält. Das MS-Tool FxCop prüft ja sowas.

Nun mache man den Versuch und lasse sich DataSet-Klassen generieren und jage sie durch den FxCopy und siehe da: Pro Klasse Dutzende Verletzungen der Namenskonventionen.... 🙂

Die Umstellung von Delphi ist - so denke ich - relativ einfach zu verkraften. Mehr Probleme haben offenbar C++-Coder. Die können einfach nicht davon lassen Variablen Typkürzel mitzugeben.... 🙂

@tomaten:

Noch eine OT-Frage. Gibt es in C# ein ähnliches Sprachkonstrukt wie: with Anything do prodecure or property from Anything

Wie dir ja schon mitgeteilt wurde gibts in C# das with-do nicht. Und ich würde dir auch in Delphi davon abraten es zu benutzen. Ich komme auch von Delphi und bin auch seit den Anfängen dabei. Ich mußte leider feststellen das dieses Konstrukt leider nicht immer das tut was es soll und mich schon mal zur Verzweiflung getrieben hat. Das Problem hat sich dann plötzlich in Luft aufgelöst als ich das with - do rausgeschmissen habe und halt etwas mehr getippt habe. Doch das nur am Rande.

Das C# mit seinen Klassen und Membern wegen Namensgleichheit durcheinander gerät ist mir auch schon passiert. Da hilft dann entweder die Verwendung von this (entspricht dem self in Delphi) oder man muß halt den kompletten Namespace mit dazu klatschen damit der Compiler sicher sein kann was den nun gemeint ist.

An sich kann ich nur sagen das mir der Umstieg von Delphi nach C# nicht sonderlich schwer gefallen ist

esonders lustig ist nur, wenn sich MS selbst nicht dran hält. Das MS-Tool FxCop prüft ja sowas. Nun mache man den Versuch und lasse sich DataSet-Klassen generieren und jage sie durch den FxCopy und siehe da: Pro Klasse Dutzende Verletzungen der Namenskonventionen.... Die Umstellung von Delphi ist - so denke ich - relativ einfach zu verkraften. Mehr Probleme haben offenbar C++-Coder. Die können einfach davon lassen Variablen Typkürzel mitzugeben....

Nun ja, wer hält sich schon an Konventionen. 🙂

Die Sache mit den Typkürzeln ist aber eigentlich gar nicht so dumm finde ich. Das erleichtert das Lesen des Codes beträchtlich. Ich habe sie auch in Delphi teilweise benutzt.

Original von UweR
Die Sache mit den Typkürzeln ist aber eigentlich gar nicht so dumm finde ich. Das erleichtert das Lesen des Codes beträchtlich. Ich habe sie auch in Delphi teilweise benutzt.

Sicher, in einer unmanaged Sprache mit "reference to pointer of pointer...." ist das auch dringend angezeigt. Bei .NET gibt es aber nur native Typen und Objekte. Da macht es praktisch keinen Sinn mehr und verunstaltet eher die Lesbarkeit.

Je fragiler die Typisierung desto mehr Information muss in die Namensgebung fliessen....

Original von UweR
@tomaten:

Wie dir ja schon mitgeteilt wurde gibts in C# das with-do nicht. Und ich würde dir auch in Delphi davon abraten es zu benutzen. Ich komme auch von Delphi und bin auch seit den Anfängen dabei. Ich mußte leider feststellen das dieses Konstrukt leider nicht immer das tut was es soll und mich schon mal zur Verzweiflung getrieben hat. Das Problem hat sich dann plötzlich in Luft aufgelöst als ich das with - do rausgeschmissen habe und halt etwas mehr getippt habe. Doch das nur am Rande.

Also ich benutze das sehr sehr sehr sehr oft um es noch geschmeichelt auszudrücken und habe schön leserlichen Code und hatte damit noch niemals Probleme.

_Original von UweR_Das C# mit seinen Klassen und Membern wegen Namensgleichheit durcheinander gerät ist mir auch schon passiert. Da hilft dann entweder die Verwendung von this (entspricht dem self in Delphi) oder man muß halt den kompletten Namespace mit dazu klatschen damit der Compiler sicher sein kann was den nun gemeint ist.

Wer benutzt denn schon "Self" in Delphi, wenn man vernüftige Namen verwendet!? Habe das bisher glaube nur ein einziges mal gebracht. Hatte niemals Problem mit irgendwelchen Namensgleichheiten die das nötig gemacht hätten. Da ist C# schon ziemlich unkomfortabel.

_Original von UweR_Die Sache mit den Typkürzeln ist aber eigentlich gar nicht so dumm finde ich. Das erleichtert das Lesen des Codes beträchtlich. Ich habe sie auch in Delphi teilweise benutzt.

Also das kenne ich in Delphi nur von Aufzählungstypen und da ist es Standard.

Aber Du musst doch auch mit Bedauern sagen, dass Delphi und .NET nicht wirklich zueinander gefunden haben oder weshalb bist Du umgestiegen?

Aber Du musst doch auch mit Bedauern sagen, dass Delphi und .NET nicht wirklich zueinander gefunden haben

Da muß ich dir zu meinem bedauern wirklich zustimmen. Das liegt einmal daran das die IDE einfach zu viele Bugs hat. Drei Releases in nem halben Jahr und das noch nach der verunglückten 8er-Version ist schon ne Leistung. Zweitens kommt noch hinzu das einige Sachen wie z.B. Namespaces einfach nicht gut genug gelöst sind. Eine echte Alternative, falls du dich nicht mit C# anfreunden kannst, ist Chrome. Das gibts aber leider erst mal nur als VS-PlugIn.

Ein weiterer Grund für den Umstieg war die Plattformunabhängigkeit. Es gibt auch halt C#-Compiler die auf Linux laufen. Das wird es für Delphi nie geben.

Original von UweR
Ein weiterer Grund für den Umstieg war die Plattformunabhängigkeit. Es gibt auch halt C#-Compiler die auf Linux laufen. Das wird es für Delphi nie geben.

Nach Chrome hab ich auch schon geschaut, aber ich kann mich ganz gut mit C# anfreunden. Das mit der Plattformunabhägigkeit ist mir nicht wirklich in den Sinn gekommen. Mono dürfte da doch immer die eine oder andere Version hinterher hängen.

Ich benutze aber auch für C# die Delphi 2005 IDE, da ich viel auf meine "alten" Funktionen zugreifen möchte und nicht alles in C# machen kann. Einige Desktop Anwendungen hab ich ja doch noch und immer zwischen den IDE's wechseln und 2x löhnen. Ne das will ich nicht wirklich. Nur ist fast keine Hilfe für C# in der Delphi IDE verfügbar. Davon mal abgesehen, dass die seit dieser Version eine absolute Katastrophe ist! Wenn ich da an früher denke, einfach F1 und es öffnete sich eine gigantische Hilfebibliothek. Heute sehe ich zu 75% "Thema nicht vorhanden"! 🙁

Die Umstellung von Delphi ist - so denke ich - relativ einfach zu verkraften. Mehr Probleme haben offenbar C++-Coder. Die können einfach nicht davon lassen Variablen Typkürzel mitzugeben....

Wobei man aber fairerweise sagen muss, dass die meisten bereits erfahreneren C++-Programmierer auch sämtliche
Typkennungen oder ähnliches ablehnen (mit Außnahme von zum Beispiel einem führenden _ für Member).

Notationen sind meistens für die alltäglich, die entweder als Einstiegsbuch etwas falsches erwischt
haben, oder bereits einen älteren Dozenten/Lehrer haben, der sich nicht recht anpassen will, ...

Hier mal ein Beispiele dazu:
http://c-plusplus.de/forum/viewtopic-var-t-is-115621-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html

Mono dürfte da doch immer die eine oder andere Version hinterher hängen.

Das schon, aber das was ich von Mono brauche, nämlich ASP.NET und ADO.NET, ist jetzt schon vorhanden. Und was das hinterherhinken angeht, das dürfte dir mit Delphi auch passieren. Ich bin mal gespannt wann die erste Delphi-version rauskommt die .NET 2.0 spricht.

Ich werde es so halten das ich .NET mit VS in C# mache und die alten Win32-Geschichten mache ich in D7 obwohl mich die 2 Umgebungen auch etwas annerven. Irgendwie erwischt man immer die falschen Hotkeys.

Notationen sind meistens für die alltäglich, die entweder als Einstiegsbuch etwas falsches erwischt haben, oder bereits einen älteren Dozenten/Lehrer haben, der sich nicht recht anpassen will, ...

oder für die die es einfach praktisch finden einer Variablen oder einem Objekt sofort anzusehen ob es nun ein Label oder eine TextBox ist und dazu noch zu faul sind sich für, wenn ich das Beispiel jetzt noch mal bemühen will, eine TextBox und einen Label die zusammengehören sich auch noch zwei Namen ausdenken zu müssen. Aber ich denke da sind die Geschmäcker der Programmierer halt verschieden und was man 20 Jahre gemacht hat will man halt auch beibehalten.

Original von UweR
oder für die die es einfach praktisch finden einer Variablen oder einem Objekt sofort anzusehen ob es nun ein Label oder eine TextBox ist und dazu noch zu faul sind sich für, wenn ich das Beispiel jetzt noch mal bemühen will, eine TextBox und einen Label die zusammengehören sich auch noch zwei Namen ausdenken zu müssen. Aber ich denke da sind die Geschmäcker der Programmierer halt verschieden und was man 20 Jahre gemacht hat will man halt auch beibehalten.

Also das mach ich nach wie vor bei allen grafischen Elementen. Alles andere wäre der pure Horror!

In .Net schreibt die Bezeichner meistens aus.

Beispiel:

statt:
btnOk, btnCancel, lblUser

schreibt man:
okButton, cancelButton, userLabel

Das mit dem okButton ist zwar schön und gut, aber wenn ich nun mal für meinen eigentlich Bezeichner mehr als nur ein Wort brauche komme ich ins Schleudern und es wird "unleserlich" (zumindest für mich). Ich finde halt firstnameTextbox schwieriger zu lesen als txtFirstName, mal ganz abgesehen davon das es 4 Buchstaben weniger aufweist und man als Programmierer eigentlich eher schreibfaul ist. 😉

oder für die die es einfach praktisch finden einer Variablen oder einem Objekt sofort anzusehen ob es nun ein Label oder eine TextBox ist und dazu noch zu faul sind sich für, wenn ich das Beispiel jetzt noch mal bemühen will, eine TextBox und einen Label die zusammengehören sich auch noch zwei Namen ausdenken zu müssen. Aber ich denke da sind die Geschmäcker der Programmierer halt verschieden und was man 20 Jahre gemacht hat will man halt auch beibehalten.

Es wird halt dann unangenehm wenn man plötzlich den Typ des Steuerelements ändern will und man nun die Namen anpassen muss, da diese ja nicht mehr zusammenpassen. Natürlich könnte man jetzt mit Refactoring ein Gegenargument stellen, allerdings behaupte ich jede IDE, die Refactoring unterstützt, wird dir auch Typinformationen anzeigen, wenn du den Cursor über eine Variable oder Methode hältst.

Btw. kann man diesen Thread eventuell splitten?

_Original von Bernhard_Btw. kann man diesen Thread eventuell splitten?

Habe ja schon den Titel geändert. Alles ander müssen die Mods machen.

Es wird halt dann unangenehm wenn man plötzlich den Typ des Steuerelements ändern will und man nun die Namen anpassen muss

Das sollte doch eher selten vorkommen. Man sollte doch eigentlich erst mal seine Oberfläche zusammenbasteln, zumindest mal soweit das man das hat was man braucht (über Anordnungen kann man immer noch diskutieren), bevor man großartig damit anfängt den Code zu schreiben. Außerdem kann es mir dann auch passieren das ich eine Propertie benutzt habe die es jetzt plötzlich nicht mehr gibt.

Und wenn es denn doch mal passiert brauch ich kein großartiges Refactoring, da reicht dann immer noch ein simples suchen/ersetzen. Wer auf Oberflächenelemente außerhalb seines Forms zugreift sollte so oder so erschossen werden. Ich habe drei Kreuze geschlagen als ich festgestellt habe das man da im Framework einen Riegel vorschieben kann und dies auch defaultmäßig tut, in Delphi sind die nämlich public.

allerdings behaupte ich jede IDE, die Refactoring unterstützt, wird dir auch Typinformationen anzeigen, wenn du den Cursor über eine Variable oder Methode hältst.

Da hast du völlig recht und irgendwie habe ich auch auf diesen Satz gewartet, aber ich habe keine Lust erst jedesmal mit der Maus zu kreisen um zu wissen was den nun was ist, andere können da einfach anderer Meinung sein. Aber man ist nun mal in einer Zeit groß geworden als man froh war wenn man einen Editor mit Syntaxhighliting hatte und man von Intellisense und TipTools nur träumen konnte und da hat man sich das halt so angewöhnt und vor allem dran gewöhnt.

So langsam sollte wirklich mal jemand den Thread splitten, irgendwie sind wir doch etwas OffTopic geraten!

Original von UweR
Das sollte doch eher selten vorkommen. Man sollte doch eigentlich erst mal seine Oberfläche zusammenbasteln, zumindest mal soweit das man das hat was man braucht (über Anordnungen kann man immer noch diskutieren), bevor man großartig damit anfängt den Code zu schreiben. Außerdem kann es mir dann auch passieren das ich eine Propertie benutzt habe die es jetzt plötzlich nicht mehr gibt.

Morgen UweR,

machst Du das wirklich so? Also ich schreibe erst die Klassen für die Buisinesslogik und teste die dann. Anschließend schreibe ich mein GUI drum rum. So habe ich für mich eine höhere Flexibilität, da ich mir ziemlich sicher sein kann, dass die Klassen auch ohne das GUI funktionieren.

Gruß,
Fabian

@Fabian

Die Businesslogik entsteht natürlich getrennt von der GUI und wird auch getrennt getestet und da hat auch keinerlei Oberflächenelement was drin zu suchen, aber bevor ich den Präsentationlayer mit Leben fülle bin ich mir schon ziemlich sicher welche GUI-Elemente ich brauche. Das ist ja auch durch die Anforderungen an die Software vorgegeben. Wenn was ausgewählt werden soll kann ich nicht mit ner Textbox kommen und bei Mehrfachselektierung in der Liste komm ich halt mit ner ComboBox auch nicht mehr hin.

Ich versuche auch halt mir einen Entwurf der GUI vom Kunden abnehmen zu lassen, sonst bastel ich mir ne wunderbare Businesslogik und erst wenn der "Kunde" (bzw. mein Chef) die GUI sieht fällt ihm ein das er alles ja ganz anders haben will und das natürlich auf die Businesslogik oder noch tiefer durchschlägt.

Hallo zusammen,

ich kann bestätigen, dass man anhand eines Entwurfs der Fenster mit den Kunden besser kommunizieren kann als z.B. anhand eines Klassenmodells der Business-Klassen.

Trotzdem kann (und sollte) man die Business-Klassen anschließend, getrennt und unabhängig von der Oberfläche entwerfen.

herbivore

Hallo Herbivore,

das ist genau das was ich ausdrücken wollte.

Und jetzt sind wir wirklich OffTopic. Von Konstruktoren nach dem Umstieg von Delphi, dann zur Schreibweise und jetzt noch zu Präsentation- und BusinessLayer.

Original von herbivore
Hallo zusammen,

ich kann bestätigen, dass man anhand eines Entwurfs der Fenster mit den Kunden besser kommunizieren kann als z.B. anhand eines Klassenmodells der Business-Klassen.

Trotzdem kann (und sollte) man die Business-Klassen anschließend, getrennt und unabhängig von der Oberfläche entwerfen.

herbivore

Hallo herbivore,

ich denke das können alle bestätigen, die schon Erfahrungen in diesem Bereich sammeln konnten. Ein Anwender denkt halt nicht so wie ein Programmierer und dann ist es sehr von Vorteil, wenn der Anwender bildlich etwas sieht.

Ich hatte nur den Beitrag von UweR falsch verstanden. Deswegen hatte ich so darauf geantwortet.

Gruß,
Fabian

Ich habe mal wieder ein syntaktisches Problem in C#. Nach einer Stunde vergeblicher Suche muss ich mal wieder dumme Fragen posten 🙂 ! Ich habe eine Funktion:

Add(IndexName: string; Fields: string; Options: TIndexOptions);

Dabei habe ich das Problem mit den "Options". Das ist ein Set of Enums. Unter Delphi tu ich folgendes, wenn ich keine Options angeben möchte:

Add('blabla', 'blibli;blublub', []);

Aber wie verdammicht nochmal geht das unter C#?

Hallo tomaten,

das ist doch ein neues Problem. Warum machst du dafür keinen neuen Thread auf?

Unter C# musst du in dem Enum einen Extra-Wert None o.ä. auf 0 definieren.

herbivore

Ja, das ist so eine Sache, ich kann da leider nicht auf Borland warten! 😁

Helfen würde mir natürlich auch eine indizierbare .NET 1.1 MemTable. Die DataTable kann es ja noch nicht! Dann muss ich nicht soviel aus der guten alten Delphi-Welt benutzen.

Hallo tomaten,

wenn ich das richtig verstehe, definierst du deinen Enum nicht selber. Dann sollte es gehen, einfach 0 in den enum-Typ zu casten.

herbivore

Original von herbivore
Hallo tomaten,

wenn ich das richtig verstehe, definierst du deinen Enum nicht selber. Dann sollte es gehen, einfach 0 in den enum-Typ zu casten.

herbivore

*Bahnhof* 😉 Gibt es keine .NET 1.1 MemTable die ich anstelle der für .NET mehr oder weniger zurechtgestutzen benutzen kann? Die basiert nämlich noch auf TDataSet von Borland und da muss ich 200 Assemblys mitschleifen! 🙁

Nachtrag. Einfach Add("blabla", "blibli;blubblub", 0); geht ja wirklich 😁

Was willst Du denn machen?

Versuch dich mal von Delphi zu lösen, und schau nicht immer
nach, was Du da gemacht hättest.

Wie einem andern hier im Forum rate ich dir, mal das anzuschauen was dir
.NET bietet, und das zu benutzen.

Nochmal, was soll das denn überhaupt bewirken, was du da machen willst?

Hallo. Also ersteinmal schau ich nicht bei Delphi nach, sondern übersetze Delphi Code. Deshalb passiert sowas! Naja, was ich eben brauche ist eine indizierte Memory Tabelle. Warum weiss ich schon und spielt eigentlich auch keine Rolle, sie war schon vorher im Delphi Source in Benutzung. Da gibt es sowas én Mass! Ich würde ja gerne etwas von .NET nehmen, aber es scheint mir nichts in der Richtung zu bieten! 😉

C# kennt - anders als Object Pascal - keine Menge als Sprachkonstrukt. Die Menge werden in Delphi oft als "Bitfelder" genutzt. Genau sowas kennt aber C#: Das sind normale Enums, wobei das Enum mit dem Meta-Attribut [Flags] ausgezeichnet wird:

 
[Flags]
public enum Seasons
{
    None = 0,
    Summer = 1,
    Autumn = 2,
    Winter = 4,
    Spring = 8
    All = Summer | Autumn | Winter | Spring,
}

Beim All sieht man auch, wie man Kombinationen aus den Flaks bilden kann. Im Prinzip genauso wie man bei Delphi eine Menge aus einem Enum generiert.

Das TDataSet findet seine Entsprechung im DataSet. Es gibt noch diverse andere Datenstrukturen, wo du deine Daten im Speicher ablegen kannst - vergleichbar mit TList (ArrayList, Hashtable, etc.).

Hallo, erstmal Danke für Deine Bemühungen. Ich werde aber dennoch nicht komplexe Daten, auf die ich schnellen und komfortablen Zugriff haben muss, in irgendwelche Arrays und sonstige Strukturen quetschen, nur weil Microsoft es nicht schafft, an Indizes für Ihre neuen "Wahnsinns"-Technologien zu denken! In Version 1.0 hätte ich es ja verstanden, aber in 1.1 (die ja quasi schon die 2.0 ist) habe ich kein Verständniss dafür. Vor allem arbeitet Microsoft doch nicht erst seit gestern mit Datenbanken! Memory Tables gibt es unter Delphi schon seit ... ??? Ich kann mich schon garnicht mehr errinnern, wann es keine gab! Ich hätte gerne kompatiblere benutzt (schon alleine wegen der einfacheren Bindung an visuelle Elemente), aber es geht nun mal leider nicht! 🙁 Und wie man sieht, gibt es hier zu diesem Thema keine wirklich konstruktiven Beiträge! 🙁

Hallo tomaten,

Und wie man sieht, gibt es hier zu diesem Thema keine wirklich konstruktiven Beiträge!

Ich denke sowas kannst und solltest du dir sparen, wenn du es dir mit den Leuten, die hier viel und konstruktiv auf deine Fragen antworten, nicht verscherzen willst.

Abgesehen davon angesehen, verstehe ich dein Problem nicht.

DataTable.Rows [n]

Wo ist das Problem?

herbivore