schließen wird eigentlich über die verschiedensten Wege irgendwie immer möglich sein
das ein oder andere könnte man zwar verhindern, jedoch würde ich eher den ansatz wählen eine zweite Applikation als eine Watcher einzusetzten.
die beiden Applikationen würden dann gegenseitig überwachen und die jeweils andere wieder erneut starten.
auch wenn auch ich das nicht für eine gute Idee halte, aber welche zugriffstechnologie oder Datenbank benutzt du denn ?
gerade bei den Datenbanken gibt ja schon unterschiedliche SQL Dialekte so, dass sich dein Problem schon nicht so einfach zu beantworten wäre.
Bei einer eigenen DAL, sollte es je nach implementierung auch einfach möglich sein, die erstellten SQL auf irgendeine Memory DB oder sogar xml oder JSON Dokumeten umzuleiten
auch unter Windows Forms sollte man eigentlich nicht fensterübergreifend so einfach auch die Controls zugreifen.
Bei WPF ist jedoch schon etwas anderes, meistens wird hier das MVVM Pattern eingesetzt was auch bedeutet das die hier eine zwischen Klasse (ViewModel) hast, Du würdest dann ein Property im ViewModel ändern (Direkt oder über helper Methoden) und aufgrund der Implementation von z.B. dem INotifyPropertyChange Interface wird das das in der View Angezeigte Feld welches per Binding an das jeweilige Element gebunden ist aktualisiert.
Wenn Du dich in diesem Forum mal umschaust wirst Du viele Beispiele finden wie man auch so eine Fenster übergreifende Kommunikation sauber unter WPF hinbekommst
so wie es aktuell aussieht kennt dein MySqlCommand die Connection nicht
der Konstruktor vom MySqlCommand hat eine Überladung mit der Query und einer Connection
das sollte zumindest schonmal ausreichen das dein Code funktioniert.
des weiteren, versuche bitte so wie du es ja auch schon angedeutet hast, bei den SQL Queries auf den Parameter Weg zu setzen anstatt einzelne Strings zu Konkatenieren , da du damit unter anderem so etwas wie SQL Injection verhindern kannst.
Bei einem Insert nutzt man eigentlich nicht die Methode ExecuteReader, da diese eher für Select Queries benutzt wird, versuche es lieber mit ExecuteNonQuery()
Bitte denke zukünftig daran, beim Quellcode auch die Code Tags zu benutzen
das Hilft beim lesen ungemein.
wie wäre es denn, mit einer von Dir erstellten abstract Class von der du ableitest.
in dieser Klasse, hättest Du dann deine globalen Funktionen und Properties und wenn du die funktion virtual machst kannst Du diese, wenn Du es benötigst sogar überschreiben.
Das Binding kann ja auch nicht funktionieren, da der DataContext im besten Falle an dieser stelle ein nur einfacher Datentyp ist und nicht etwas vom Typ IEnumerable.
Entweder Du setzt die Items der Combobox im Code direkt oder Du mußt deinem Binding eine RelativeSource mitgeben
Hmm, ich kenne so ein Verhalten eigentlich nur, wenn ich ein Fehler habe und mit F5 die Anwendung starte
und in der Konfiguration unter
Projekte und Projektmappen => Erstellen Ausführen
bei 'Beim Ausführen, bei Buildfehler...' "Alte Version starten" eingestellt ist
-- Hast Du schon einmal in die Fehlerliste reingeschaut
-- Das Projekt bereinigt (also alles gelöscht) und dann neu erstellt
-- oder absichtlich mal ein ';' vergessen und gestartet
Du könntest das ganze einfach an das Window hängen, die Frage wäre dann nur welche anklickbaren Elemente Du verwenden möchtest.
Denn wenn Du zb einen Button oder eine Textbox hast, würde dieses Event von dem jeweiligen Element selber behandelt werden und nicht von deinem Fenster.
warum bindest Du denn den CommandParameter, an das Property SelectedItem von der ListView
ein Binding auf den aktuellen Row DataContext, wäre für Dich doch eigentlich das Richtige.
So würdest Du im Parameter, auch das Objekt bekommen welches die aktuelle Zeile Repräsentiert.
wenn du wirklich keinerlei Informationen über die DB oder ein mögliches Format hast,
dann bedeutet das ein wenig manuelle Arbeit.
Deine Aufgabe wird dann sein, das mögliche Format aus der Datei ab zuleiten.
Entweder anhand von den vorhanden Daten in der Datei und den im Programm angezeigten Daten.
Oder durch erzeugung von neue Einträgen und einer nachgelagerten Analysiert der veränderten Datei.
und sobald man meint das alles Versanden zu haben,
dreht man den Spiess um und ändert die Datei manuell und überprüft die eigenen änderungen mit dem Programm.
mit den so gesammelten Informationen und einem gescheiten Test Framework, ist dann die Nachimplementation nur noch ein Fleissarbeit.
Das es im Slider-Control nicht funktioniert kann eventuell an folgenden liegen:
1.) Gib nicht deinem USerControl, den Namen root, dondern deinem 1. Element (i.d. Fall deinem Grid)
Das Problem ist nämlich sonst, dass der DatenContext deines UserControls überschrieben wird, wenn du es ein Parent bekommt (z.b. wenn du es einem WIndow hinzufügst)
2.) Du kannst das Binding auf den ElementNamen sparen. Gib nur den Path an. Da das Framework automatisch in den DatenContext schaut ob irgendwo die Property liegt (erst im Slider-DatenContext, dann im Grid usw. und im Grid würde es dann gefunden werden)
hmm, ich glaube an dieser Stelle hast du ein kleinigkeit übersehen, denn an dieser Stelle wird nicht über den DataContext auf die jeweiligen Eigenschaften zugegriffen.
zum ersten solltest Du Dich einmal ein wenig mehr mit den Funktionalitäten der einzelnen Layout Container beschäftigen.
zum zweiten würde ich Dir Empfehlen den Designer Links liegen zu lassen, denn mit ein wenig Vorstellungskraft und ein wenig Übung bist Du um einiges schneller wenn du den XAML Code direkt schreibst.