Laden...

Forenbeiträge von Zed Ingesamt 19 Beiträge

09.11.2006 - 13:16 Uhr

Danke für die Antwort.

Zu deinen Fragen: Ja ich weiß, das typerisierte DataSets massiv viel Code erzeugen. Begeistert war ich deshalb nicht sonderlich von dieser Lösung, allerdings war es aus meine Sicht die einzigste, bei der ich mir nicht gleich am Anfang die Finger gebrochen hätte.

XPO wollte ich mir bereits seit ein paar Wochen anschauen, leider ist die Zeit bisher ausgeblieben.

Hast du bereits Erfahrungen damit gemacht? Wenn ja: Ist es wirklich so einfach zu handhaben, wie es beschrieben wird? Und ist es ausgereift?

09.11.2006 - 10:49 Uhr

Hi BerndFfm,

mir gehts in erster Linie drum, wie ich zur Designzeit mit den untyperisierten DataSets effektiv arbeiten kann.

Du schreibst ja, das ich mit untyperisierten DataSets genau so wie mit typerisierten arbeiten kann. Zur Laufzeit ist mir das soweit auch klar, aber zur Designzeit fehlen mir da die Assistenten / direkte Designzeitverknüpfungen etc.

Ich weiß zwar, das ich mir ein leeres untyperisiertes DataSet anlegen könnte und dann manuell jedes Datenbankfeld anlegen könnte, allerdings habe ich hier eine Datenbank mit 200-300 Tabellen bei der viele Tabellen auch mal 100-250 Felder haben können. Bei kleinen Anwendungen, würde ich das ganze natürlich auch manuell zur Designzeit anlegen können und dann die angelegten Spalten mit meinen Controls / Grids verknüpfen, aber wie handhabt ihr das bei vielen Feldern / Tabellen? Gibt es hierfür einen Assistent / Tool, das ich evtl noch nicht entdeckt habe?

09.11.2006 - 10:02 Uhr

Hi Rainbird

danke für die Antwort. Ich habe derzeit nur wenige Erfahrungen mit untyperisierten DataSets gesammelt, daher noch eine Frage hierzu:

Bei den typerisierten DataSets und den damit verbundenen TableAdapter erstellt er mir ja bei der Generierung, mit einem einer entsprechenden SELECT-Anweisung, gleich alle Spalten und ließt auch die zugehörigen Datentypen aus der Datenbank. Ebenso legt er (meistens 😉 ) die Insert/Delete/Update-Statements an.

Wie handhabst du das mit den untyperisieren DataSets?
Legst du jedes Datenfeld manuell an und wählst hier jeden Datentyp selbst aus oder gibt es hierfür auch eine Möglichkeit sich arbeit zu ersparen?

Und wie machst du das mit den Insert/Delete/Update-Statements? Legst du dir die manuell an und verwaltest die mit einem eigenen Objekt?

Wie du siehst ist mir noch nicht ganz klar, wie man effektiv mit untyperisierten DataSets arbeiten kann. Hoffe du kannst mir da etwas weiterhelfen. Gerne auch mit einem Tutorial/Artikel hierzu.

Vielen Dank im Voraus

08.11.2006 - 23:27 Uhr

Das ich mir hierfür Funktionen schreiben würde, die mir das dann mit wenigen Zeilen Code automatisch generieren, ist mir auch klar, allerdings gibt es doch sehr viele Fälle, bei dennen es zu viele Ausnahmen gibt... (bsp. Kunde möchte jede 2te Zeile grau eingefärbt haben und die Spalte "KD_ARTIKELNR" ebenfalls. Ausserdem soll in der 3ten Spalte die Bezeichnung geändert werden etc.)
Diese ganzen Eigenschaften müssten dann alle per Code gesetzt werden, was schnell zu sehr viel Code führen kann...

Wenn ich das aber aus deinem Post richtig interpretiere, wird im dem Fall, bei dem man mit untyperisierten Datasets arbeitet auch alles über Code statt Designer geregelt oder?

08.11.2006 - 19:03 Uhr

Ich hab bisher beinah ausschließlich mit typerisierten DataSets gearbeitet, allerdings auch die erwähnten Nachteile bitter gespürt... Was ich mich aber frage, wenn ich mir eure Beiträge so durchlese:
Untyperisierte Datasets mögen ja die Sache per Codeabfrage vereinfachen, aber wie steht es mit der Designtime-Entwicklung

Wir entwickeln viel mit DevExpress-Komponenten... Hierfür ist es oft erforderlich viele Felder in mehreren Grids zu erstellen, zu konfigurieren und diese mit einer Bindingsource zu verknüpfen. Benutzt Ihr diese Untyperisierten Datasets dann nur zur Laufzeit und erstellt jede Spalte in jedem Grid zur Laufzeit? Das wäre mir persönlich viel zu viel Code... Nur zum formatieren eines Grids, zum verknüpfen und erstellen aller Spalten, dem setzen aller Eingabemasken etc. würde ich sicher oftmals 100-200 Zeilen Code schreiben...

Bei den typerisierten Datasets war der große Vorteil halt, dass ich z.B. bei einer Tabelle mit 100 Feldern im Designer eben einen TableAdapter erstellt hab, dieser dann die 100 Felder ausgelesen hat, ich dann nur noch auf mein Hauptformular musste, ne bindingsource anlegen musste, diese dann mit dem Dataset verknüpft hab und im GridControl von DevExpress die ganzen Felder automatisch als Spalten anlegen lassen hab. Die Spalten die mich nicht interessierten hab ich dann noch schnell ausgeblendet / gelöscht und meine möglichen Eingabemasken eben im Designer festgelegt. Alles schön unkompliziert und sicherlich in 5 min bewerkstelligt... Zum füllen des Grids war dann lediglich noch eine Zeile Code mit einem .Fill notwendig...

Wie handhabt ihr das mit untyperisierten Datasets? Benutzt ihr keine Designtime möglichkeiten?

30.10.2006 - 08:04 Uhr

Hallo,

ich möchte gerne im Code mit der TableAdapter-Klasse arbeiten, kann allerdings nicht feststellen, in welchem Namespace sich die TableAdapter-Klasse befindet.
Verwunderlich für mich, liegt diese nicht im System.Data-Namespace...

Kann mir da jemand helfen? Und am besten mir eine Möglichkeit nennen, wo ich sowas in der MSDN-Hilfe oder sonstwo einfach finde (also die Objektstruckturen)?

Vielen Dank im Voraus

22.09.2006 - 13:50 Uhr

Hallo,

danke für die schnelle Antwort. Immerhin weiß ich jetzt, das ich nicht der einzigste bin, der dieses Problem bisher hatte. Allerdings steht im Link keine Lösung.

Mir ist aufgefallen, das es immer passiert, wenn ich bei meiner Pagecontrol auf z.B. dem Tabreiter 3 bin, auf dem sich die BindingNavigator-Komponente befindet und dann kompiliere. Wenn ich auf dem ersten Tabreiter bin und dann kompiliere, verschwindet der BindingNavigator komischer weise nicht...

22.09.2006 - 11:54 Uhr

Hallo,

ich habe ein eigenartiges Problem. Ich arbeite seit heute das erste Mal mit der BindingNavigator-Komponente.
Nachdem ich die Komponente platziert hab, habe ich sie sauber mit meiner BindingSource verbunden und anschließend kompliliert. In der kompilierten Version wird die BindingSource auch sauber angezeigt. Im Hintergrund generiert VS beim kompilieren aber jedes mal mein Formular neu. Dabei wird jedes mal die Visible-Eigenschaft des BindingNavigators auf false gesetzt.

Kann mir jemand erklären, warum das VS automatisch macht und was ich dagegen tun könnte?

21.07.2006 - 10:24 Uhr

Hallo,

ich habe eine Applikation, bei dem ich eine Bindingsource, eine Datasource, ein Grid und eine im Grid benutze Lookup-Komponente verwende.

Das Problem dabei ist nun die Erstellungsreihenfolge der automatisch generierten Designer.cs

Der Designer legt das ganze folgendermaßen ab:

                  ((System.ComponentModel.ISupportInitialize)(this.grdViewRSaetze)).EndInit();            
((System.ComponentModel.ISupportInitialize)(this.cbxRSaetze)).EndInit();
((System.ComponentModel.ISupportInitialize)(this.bsRSaetze)).EndInit();            
((System.ComponentModel.ISupportInitialize)(this.dsRSaetze)).EndInit();

Das Problem hierbei liegt in dem EndInit von der "cbxRSaetze"-Komponente. Diese wird fertig initialisiert, bevor die Bindingsource + Datasource fertig initialisiert ist. Wenn ich so versuche, meine Anwendung zu starten, bekomme ich immer die Meldung: "Die DataMember-Eigenschaft EINSTELLUNGEN kann in der DataSource nicht gefunden werden."

Wenn ich jetzt manuell die Combobox-Zeile um 2 Zeilen nach unten verschiebe, funktioniert alles problemlos:

                  ((System.ComponentModel.ISupportInitialize)(this.grdViewRSaetze)).EndInit();            
((System.ComponentModel.ISupportInitialize)(this.bsRSaetze)).EndInit();            
((System.ComponentModel.ISupportInitialize)(this.dsRSaetze)).EndInit();
((System.ComponentModel.ISupportInitialize)(this.cbxRSaetze)).EndInit();

Allerdings: Sobald ich das Formular einmal im Design editiere, bildet er die Designer.cs Datei neu auf. Das geht mir der Zeit ziemlich auf den keks 🙂

Deswegen meine Frage: Gibt es eine möglichkeit einzelne Teile in dieser Designer.cs-Datei unersetzbar zu machen für die automatische Generierung?
Oder kann ich sonst irgendwie die Erstellungsreihenfolge beeinflussen?

Vielen Dank schonmal im Voraus für jede Antwort

26.06.2006 - 13:12 Uhr

Ich bin mir nicht 100% sicher, ob ich mich richtig ausdrücke. Beschäftige mich erst seit kurzem mit der C#-Welt.

Also was ich gemacht hab:
Zum Projekt -> Neues Element hinzufügen -> Dataset

Anschließend in dem erstellten Dataset manuell eine DataTable angelegt und manuell Felder eingepflegt. Dieses Dataset wird dann manuell per Code gefüllt (also nicht mit .fill())

So ein Dataset nennt man doch "typerisiertes Dataset" oder?

Auf jeden Fall kann ich dieses Dataset immer verknüpfen, egal auf welchem Formular im Projekt. Ich bekomme dann bei der Databindung-Zuweißung immer den Baum:

Weitere Datenquellen
-> Projektdatenquellen
-> MeinDataSet

Der DataAdapter von Firebird erstellt leider nur "untyperisierte Dataset" in dem Formular und sind somit nicht Projektübergreifend verfügbar.

Hoffe jetzt hab ich mich verständlicher ausgedrückt?

Auf jeden Fall möchte ich die generierten Datasets (untyperisierte) Projektübergreifend zur Verfügung stehen haben, wenn dies möglich wäre?

26.06.2006 - 10:41 Uhr

Danke für die schnelle Antwort.

Die Component Class, wie in deinem Link angegeben, kann man leider nicht benutzen um Komponenten visuell zu verknüpfen. (d.h. z.B. meine Textbox mit einem DataSet auf der Component Class) Per Code, wäre das aber die Lösung, die ich benötige.

Auf die Idee mit dem Basis-Formular bin ich auch schon gekommen, nur wäre mir eine Lösung, wie ein Datenmodul lieber.

Zu deinem letzten Vorschlag, muss ich mich erst mal genauer Informieren. Sieht aber auf den ersten Blick so aus, als müsste man hierfür sein Projekt von Anfang an komplett so aufbauen.

Was mich wundert: Ich hab einen typerisierten Dataset (eine Temp-Tabelle) den ich in jedem Formular verwenden kann. Warum kann ich das nicht auch irgendwie mit einem untyperisierten generierten Dataset realisieren?!?

26.06.2006 - 09:47 Uhr

Hi Leute,

bei dieser Frage handelt es sich für mich nur um eine Verständnisfrage.
Ich selbst komme von der Delphi-Schiene und bin mir daher nicht sicher, ob meine Erstellung der Formularen + Kommunikation mit der DB korrekt ist, weil mir die ganze Erstellung der DB-Verbindungen im Gegenteil zu Delphi doch teilweise unnötig erscheint.

Also im momentan sieht das ganze so aus:

  1. Ich benutze die Firebird-Provider und habe ein Hauptformular, auf dem ich eine FbConnection habe. Diese benötige ich auf JEDEM Formular, damit ich Komponenten wie einen FbDataadapter damit verbinden kann.
  2. Sobald ich ein neues Formular erstelle, muss ich erst mal ne neue Connection stellen und eine Property mit einem "Set"-er, in dem ich die Connection meines Hauptformulars übergeben kann. Anschließend muss ich im "Set"-er, meine Connection der visuell erstellten Connection zuweisen + jedem Command die Connection neu zuordnen (weil diese nicht automatisch geändert werden, wenn die verknüpfte Connection neu zugewiesen wird)
  3. Anschließend muss ich zu aller erst einen Dataadapter erstellen um Daten für eine einfach Datenverarbeitung zu erstellen. Aus dem Dataadapter erstelle ich dann jedes mal ein DataSet um meine Komponenten visuell verknüpfen zu können. Will ich jetzt auch noch sowas wie ein "Position_Changed"-Ereigniss haben, lege ich mir noch eine Bindungsource an und Verknüpfe diese.

Was mich an dem ganzen stört: Ich muss für jedes Formular eine neue FbConnection erstellen und übergeben. Auch kann ich keinen DataAdapter, den ich auf einem anderen Formular vielleicht genau gleich erstellt hab, nochmal benutzen.
In Delphi gibt es Datenmodule. Nicht visuelle Oberflächen, auf dennen man 1 Connection ablegen kann + alle gewollten Query's um auf diese von allen Formularen zurück greifen zu können.

Von sowas wie einem Datenmodul hab ich bisher nichts gelesen. Und von einem Formular auf die Connection des Hauptformulars zurück zu greifen (vor allem auch wichtig im Design-Modus) soll ja auch nicht gehen. Hierzu gibt es ja jede Menge informationen hier im Forum.

Daher meine Frage:
Ist meine Erstellung der Applikation, wie oben beschrieben, richtig oder kann ich mir irgendwo Arbeit sparen?

19.06.2006 - 15:24 Uhr

Der Programmierer hat das nur nicht gemacht, weil er sich bei ShortString nicht um die Speicherfreigabe kümmern musste.

PChar sollte ja kein Problem darstellen im Bezug auf automatische Speicherfreigabe oder? Hab das mal eben getestet ob ich ne eigene Funktion mit PChar als Rückgabe ansprechen kann... War kein Problem.

Was denkst du dazu? PChar empfehlenswert?

19.06.2006 - 15:09 Uhr

Gut zu wissen. Wird mir nichts anderes übrig bleiben als mich mit dem Programmierer der DLL in Verbindung zu setzen.

Schade das deine ganzen Bemühungen (beinah) umsonst waren.

19.06.2006 - 14:19 Uhr

Nochmal vielen Dank für deine Bemühungen.

Leider kommt auch bei dieser Lösung ein Fehler:

Fehlermeldung:
Die Typensignatur der Methode ist nicht PInvoke-kompatibel.

19.06.2006 - 13:49 Uhr

Zu dieser Lösung:


[DllImport("Test.dll")]
[return:MarshalAs(UnmanagedType.LPArray, SizeConst=256)]
public static extern byte[] DLL_VersionsInfo();

bekomme ich folgenden Fehler:

Fehlermeldung:
return value kann nicht gemarshallt werden: Ungültige verwaltete/nicht verwaltete Typenkombination..

🙁

19.06.2006 - 13:46 Uhr

Hi svenson,

nochmal danke für deine schnelle Hilfe. Mit einem IntPtr hatte ich es auch schonmal probiert. Hab das mal eben nochmal getestet, um dir die Meldung schreiben zu können:

Fehlermeldung:
PInvokeStackImbalance

Ein Aufruf an die PInvoke-Funktion "om_exm_abcr!om_exm_abcr.frmExpressmaske::DLL_VersionsInfo" hat das Gleichgewicht des Stapels gestört. Wahrscheinlich stimmt die verwaltete PInvoke-Signatur nicht mit der nicht verwalteten Zielsignatur überein. Überprüfen Sie, ob die Aufrufkonvention und die Parameter der PInvoke-Signatur mit der nicht verwalteten Zielsignatur übereinstimmen.

Wie angenommen gibts hier Probleme mit dem Stack.

Hoffe du kannst mir trotzdem noch weiterhelfen.

19.06.2006 - 12:50 Uhr

Danke Svenson für deine Hilfe und korrektion meiner Aussage.

Leider bekomme ich beim erstellen eine Fehlermeldung:

Fehlermeldung:
Fehler beim Ausgeben des System.Runtime.InteropServices.MarshalAsAttribute-Attributs -- "Der angegebene nicht verwaltete Typ ist nur in Feldern gültig.".

Unterstrichen wird "MarshalAs".

Leider kann ich mit der Meldung zuerst mal wenig anfangen. (Zu wenig C#-Erfahrung)
Hast du ne Idee, was geändert werden muss?

19.06.2006 - 09:49 Uhr

Hallo,

mein Programm soll auf eine unmanaged Delphi-DLL zugreifen. An und für sich, klappt das auch, nur hab ich mit einen bestimmten Delphi-Typ ein Problem: ShortString

Ein Funktionsbeispiel sieht z.B. so aus:

...
function DLL_VersionsInfo : ShortString;
...

Ein ShortString ist ein 255 langer nullterminierter String. Im 0ten Byte steht die länge des Strings. C# kennt so einen Datentyp scheinbar nicht, also dachte ich, dass ich mir den Rückgabewert als byte-array geben lasse und es selbst umwandel, allerdings ohne Erfolg.

Hier mein Codebeispiel, mit 2 Versuchen, die allerdings beide fehlschlagen beim Aufruf der Funktion:


[DllImport("Test.dll")]
public static extern byte[] DLL_VersionsInfo();

[DllImport("Test.dll")]
public static extern string DLL_VersionsInfo();

Ich hab gesehen, dass man evtl. noch MarshalAs verwenden kann, um untyped-Typen zurück geben zu können, aber weiß nicht, wie ich das als Rückgabeparameter zurückgeben kann.

Achja: Ändern kann ich die Delphi DLL nicht, weil diese nicht von uns stammt.

Vielen Dank schonmal für jede Antwort