Suchergebnisse

ich find was du verlinkst nicht wirklich ähnlich. Auch finde ich da keine Lösung, sondern der TE dort scheint einfach das Interesse verloren zu haben. Hier würde ich sagen, geht es darum, einen Filter auf die K-Faktor-Tabelle zu setzen, der nach gewählter ZelleID und StationID filtert. Wie du sagst: Geht nicht ohne Zusatz-Code. Ist nicht ganz einfach, aber auch nicht soo schwierig mit DataExpressions. DataExpressions: Filter und berechnete Spalten im Dataset

wie gesagt: Die Lösung liegt in DataExpressions. Du kannst der KFaktorBindingSource eine Expression verpassen wieSQL-Abfrage (1 Zeile) Weiters das KFaktorBindingSource_AddingNew-Event behandeln, und im Datensatz, der dir da übermittelt wird, die ForeignKeys entsprechend setzen (nämlich auf 3 und 5. Wenn du dann einen neuen KFaktor ins Grid einträgst, bekommt der automatisch die erforderlicchen ForeignKeys. Wenn du hingegen über andere Kanäle als das DGV KFaktoren zufügst, sind vlt. annere Wege a…

Jepp, ups!, ja, sorry. Stichwort BindingSource.Filter hätte ich unbedingt nennen müssen, dass man mein Gefasel versteht thx!

zu 3: Du solltest dich wirklich mit dem DataExpression-Tut vertraut machen. Also hier etwas zum wörtlich nehmen:VB.NET-Quellcode (1 Zeile)Du wirst einwenden: "aber das setzt ja vorraus, dass es eine K_FaktorBindingSource gibt." Ja, tut es. Und wenn es K_Faktor-Datensätze gibt mit ZelleId=3 und StationId=5, so werden sie im daran angebundenen DGV angezeigt - die anderen nicht. Und dann mach zur AbwechslungVB.NET-Quellcode (1 Zeile)und schau, was dann angezeigt wird. Und dann noch VB.NET-Quellcode…

ich find das normal mit viele BindingSources. Ich bename die kürzer, und wenn nicht klar ist, wer daran bindet, kommt auch diese Info in den Namen rein. Aber hier ist glaub eindeutelich, dasses die Bs' der Combos sind. Mich stört, dass schön typisierte Datarows aus den BindingSources geholt werden, und dann wird nicht konsequent damit gearbeitetVB.NET-Quellcode (8 Zeilen)Und mit Importen lassen sich viele Namens-Bandwürmer vermeidenVB.NET-Quellcode (2 Zeilen)wenn Standard der Name deines typData…

Jo, hab mir Vid angeguckt - das Form ist jetzt ja doch enorm vollgeballert mit BindingSources. Und das verrückte Verhalten der Combos kann ich mir nur erklären dadurch, dass noch annere Sachen an deren BindingSource hängen, etwa iwelche DatagridviewComboboxColumns. Oder wird iwo händisch was eingefüllt in die Combo, oder zugewiesen an Combo.Text. Weil 0 dürfte eine Combo garnet anzeigen können, deren DataMember auf Name festgelegt ist. Mir scheint hier auch zweckmäßig, mit UserControls zu arbeit…

Zitat von ludl8615: „Das wäre logisch, aber ich hab ja die BS extra für dafür neu erzeugt. Also sollte doch daran nichts anderes hängen.“Kann man auch mit Volltextsuche nachgucken oder ab 2015 mit Kontext-FindAllReferences

weiß ich auch nicht. Aber ein Source-Backup hast du nicht zufällig gemacht, oder? Weil da könnte man nu schön vergleichen, wieso es vorher ging und nu nichme. Wenn kein Backup, dann ist das jedenfalls ein wesentlicher Lerngewinn: Wie wichtig Backups manchmal sind Kannste dir entweder ein SourceControl-Umgebung installieren, oder minimal dieses Progrämmle benutzen: SolutionExplorer - OpenSource Das kann u.a. auch Source-Backups zurecht-zippen.

da fällt mir ein, es gibt noch einen anneren Weg, ohne das ListChanged-Event. Man kann die DefaultValues der Foreign-Key-Spalten auf die in den Combos gewählten primKeys setzen. Dann sind die ja Default, und man braucht kein ListChanged, um da nachträglich etwas nachzubessern.

ähm den DefaultValue solltest du setzen, wenn sich eine der Combos (die den DefautlValue ja bestimmen) ändert. Das AddingNew-Event kann dann weg, weil ja automatisch die richtigen Werte eingetragen werden, wenn ein Datensatz erzeugt wird (das ist ja die Bedeutung von "DefaultValue").

wie gesagt: der defaultValue bewirkt, dass der Wert bereits gesetzt automatisch ist, bevor der Datensatz der DataTable zugefügt wird. Beim BindingSource_AddingNew sind die Werte bereits so eingestellt wie gewünscht.