Akanel schrieb:

das dass

http://www.dass-das.de/

Akanel schrieb:

ändern der Artikelspalte auf der Form nicht so funktioniert.

In welcher Anzeige funktioniert das Ändern nicht? Bzw was meinst du mit funktioniert nicht? Kannst du im Designer den DisplayMember (also den Namen der Property, welche im UI angezeigt werden soll) nicht einstellen?

Akanel schrieb:

Es werden mir Zwar die ID´s angezeigt, aber ich möchte wieder den Artikelnamen haben.

Akanel schrieb:

So sieht Form1 zur Laufzeit aus:

Also wenn ich mir deine Anwendung so ansehe, dann steht doch im DGV für die Posten keine Artikelnummern/ArtikelIDs, sondern Artikelbezeichnungen drinnen, passt doch? Oder verstehe ich dich hier falsch??

Lg Radinator

Du möchtest nicht dass der Kunde die dgv manuell befüllt sondern hast dafür eine seperate Form ja? Wenn ja, dann könntest du der neuen Form einfach paar sachen übermitteln, am besten in den constructor deiner neuen form:

Akanel schrieb:

Ich bekomme es dort nicht hin das der DisplayMember auch der ArtikelName ist.

Zeig uns mal bitte den Designer Dialog für das DGV der DialogForm, wie in Bild #3 in deinem ersten Post.

Wenn man davon absieht, dass ich in Deinem Code nicht ganz klar komme, warum da PostenBindingSource und ArtikelBindingSource z.B. in der Hauptform z.B. im Posten-DGV irgendwie vermischt sind oder in der mit "ArtikelID" beschrifteten Spalten Artikelnamen kommen und ich noch nicht ganz durchgestiegen bin, wo Du gern was anders haben willst, geb ich mal folgenden Hinweis: Wenn Du in Deiner Rechnungsdialogform (Name "dlgRechnung", Formtitel "Rechnung") im Posten-DGV in der Spalte namens "ArtikelID" (warum auch immer diese Spalte diesen Titel trägt) Deine Artikelnamen ("Betriebsanweisung erstellen", Arbeitsanweisung erstellen, ...) drin stehen haben willst, musst Du in Form1 in der Region Dialoge im Sub RechnungBearbeiten vor die Zeile If frmRechnung.ShowDialog(Me) = DialogResult.OK Then noch eine weitere BindingSource umstöpseln, und zwar mit frmRechnung.ArtikelBindingSource.DataSource = ArtikelBindingSource. Dann tauchen Deine Artikel im genannten DialogForm-DGV auf.

btw: "Arbeitsplatz begehung 1. UE" "Arbeitsplatzbegehung 1. UE"

Ich hab mal eine funktionierende Umstöpselung eingebaut.
Beachte, dass ich in dlgRechnung das üflüssige Dataset weggeräumt hab, und eine bsMain zwischen die lokalen BindingSources und dem verbliebenen lokalen Dataset eingefügt hab.
Auf diese Weise mussich beim Umstöpseln nur eine BindingSource anfassen.
Ich glaub, was mit Umstöpseln gemeint ist, und der Sinn davon, ist nicht klar.
Das Problem ist, dass dlgRechnung im Designer ein eigenes Dataset erhält - identisch zu dem in Form1, aber eben eine andere Instanz. Wenn nun Form1 sein Dataset lädt, weiß ja dlgRechnung nix davon, sondern dessen Dataset bleibt ja leer. Und alle seine BindingSources, und das ganze schöne Design ist and dieses leere Dataset angeschlossen - bringt logischerweise nix.
Daher - bevors ühaupt angezeigt wird - erstmal Umstöpseln aller BindingSources auf das Form1.DAtaset - wie gesagt, durch meine eingeschobene Bindingsource besonders einfach:Aber das ist auch alles erklärt in Daten laden, speichern, verarbeiten - einfachste Variante (versucht zu erklären wenigstens).
Ausserdem nutze ich dort einen viel einfacheren Weg, nämlich eine von mir gebastelte HelperSolution, die die Umstöpselei automatisch (und sogar bisserl gründlicher) durchführt.


Das weitereja gut - ist auch ein Umstöpseln, aber das stöpselt nur die zu editierende BindingSource auf einen bestimmten Datensatz um - es leitet nicht die Gesamtheit des BindingSource-Designs des Edit-Dialogs auf's Form1-Dataset um.

---

Beachte aber auch, dass bei so komplexen Bearbeitungs-Dialogen ein Teil des Dialog-Patterns verloren geht: Canceln kannst du nur, was via RechnungBindingSource im RechnungsDatensatz eingetragen wurde.
Aber in deim Dialog machst du ja auch Einträge inne RechnungPosten-Tabelle - diese Veränderungen wirken sofort ins Dataset (das siehste auch), und lassen sich später durch einfaches Canceln auch nicht mehr revidieren, denn .RechnungBindingSource.CancelEdit() wirkt ja nicht auf die Posten-Tabelle.

Da gibts auch kein Patentrezept für (ausser das PostenGrid readonly machen).
Also für die Bearbeitung der angewählten RechnungRow ist das ja ein Patentrezept, nach dem Prinzip kann man alle möglichen angewählten Rows bearbeiten.
Aber wenn im 'Dialog komplexe Eingaben vorgesehen sind, mehrere Tabellen betreffend - wie hier gezeigt ist das durchaus möglich, aber das Standard-Cancel-Feature mit BindingSource.CancelEdit geht dabei flöten.
Muss man mit leben, oder halt je nach Einzelfall besonderen Aufwand treiben, um im Cancel-Falle dennoch "zurückrudern" zu können.

Akanel schrieb:

solche komplexen Sachen einbaue, am ende aber nicht verstehe was da überhaupt passiert.
Daher werde ich noch etwas Zeit brauchen bevor ich mich wirklich daran traue.

Jo weiss ich auch nicht.
Natürlich hast du bereits (etwa mitte WinForms-dll) Tonnen aüsserst komplizierten Codes eingebaut, von dem du nicht die Bohne verstehst - oder meinst du, zu verstehen, was in einer Textbox vor sich geht?
.Net coden heisst, Dinge richtig benutzen zu lernen, und sich um die Innereien nicht kümmern zu müssen.

Ist - da geb ich dir recht - eine heikle Sache bei so selbstgebastelten Sachen - also eine Release von MS ist in der Tat überaus viel vertrauenswürdiger als meine Sammlung komischer Helferlein.
Aber dennoch sind auch meine Helferlein nicht unbedingt zum Verstehen vorgesehen, sondern machen ihren Job (sollen sie wenigstens) auch, wenn man den Code darin (noch) nicht nachvollziehen kann.
Das Verständnis der Helpers-Innereien ist eine Art "möglicher Luxus" der daher rührt, dass du die Sources einbindest, nicht nur die kompilierte Dll.

ja, das hängt auch mit dem Cancel-Feature zusammen: Bindingsource.Addnew erzeugt eine nur vorläufige Datarow (mit Datarowstate.Detached).
Damit die Zufügung mit .CancelEdit auch wieder ungeschehen gemacht werden kann.
Bei soner detachten Datarow kannste natürlich keine ChildRows adden, weil was soll denn mit denen passieren, wenn die RechnungRow gecancelt wird?

Lösung: die RechnungRow sofort committen. Dann kann sie aber nur noch ordnungsgemäss deleted wern, ein Bs.CancelEdit ist nicht mehr möglich:

Akanel schrieb:

Sobald ich nun eine Rechnung anlege, wird ja die Bearbeitung der RechnungBindingSource mit RechnungBindingSource.EndEdit() abgeschlossen.
Das bedeutet wiederum das ich daran nichts mehr ändern kann, kein Datum (LieferDatum, RechnungsDatum).

Doch doch - ändern kannste die Datensätze jederzeit.
Ist nur dann ein weiterer Edit-Vorgang.
Wennde mein Code-Vorschlag ausprobierst siehste ja auch, dass noch geht. Nur das Canceln ist gecancelt - bzw. bs.CancelEdit() stellt halt nicht auf den Zustand vor .Addnew() der DataRow zurück, sondern auf den Zustand nach .EndEdit().
Etwa könntest du beim Canceln die Row nun explizit löschen, um das AddNew aufzuheben. Das geht durchaus, und die Lösschweitergabe entfernt auch die untergeordneten Posten.
Einzig ist, dasses nicht mehr so schön ist, dass man händisch was dazu-coden muss, während in simplen Szenarien der IEditableObject-Pattern sich automatisch um alles kümmert.

Akanel schrieb:

Heisst wohl ich muss einen weiteren Edit-Vorgang dazu programmieren.

Nein, du hast garnix damit zu tun.
Ich habe nur versucht, zu erklären, warum du beim Hinzufügen mittels bs.AddNew() gleich bs.EndEdit() aufrufen musst, bevor das EditForm ühaupt anzeigt - siehe mein Code.
Und dass das für die Bindingsource dann 2 Edit-Vorgänge sind: beim ersten fügt .AddNew() eine vorläufige Datarow hinzu, das folgende .EndEdit übernimmt diese Zufügung sogleich als abgeschlossenen Edit-Vorgang, und danach erst öffnet sich das EditForm und editiert den nun bereits übernommenen Datensatz. Und letztere Editierung kann der User canceln, aber das stellt den Vorgang nur soweit zurück auf den Stand nach Übernahme der Hinzufügung, und das widerspricht dem eiglichen IEditableObject-Pattern.
Weil das Hinzufügen + Editieren einer einfachen DataRow, bei der nicht Childrows mit-zu-editieren sind - solche Zufügungen sind eiglich cancellable.

Oder anners: Der Cancel-Button auf deim Editieren-Form cancelt nicht richtig - dassis alles.

Akanel schrieb:

Aber das RechnugsDatum und das LieferDatum werden somit nicht übernommen.

Die werden deshalb nicht übernommen, weil die entsprechenden Datatimepicker kein Databinding haben - zumindest nicht in der Solution, die ich grad gedownöoaded hab.
Ich würd dich auch SolutionExplorer - OpenSource empfehlen, der zippt eine Solution ohne Binaries.
Oder machs händisch, dasss du den bin-ordner iwie anners aus der Zipdatei entfernst - ist nämlich aus guten Gründen nicht erlaubt, ausführbare Dateien hier übers Forum in Umlauf zu bringen.