wpf xaml - GUI zur Laufzeit anpassen

[RM_ITA]

Hallo,

ich suche einen Ansatz, wie man zur Laufzeit fertige xaml Masken anpassen kann. Genauer gesagt, würde
ich das gern mit Hilfe einer eigenen GUI machen. Es muss dabei sichergestellt sein, dass nur Felder bearbeitetet
werden können (hinzufügen, löschen, verschieben, Grafik einfügen, usw.). An der Funktion selbst darf nichts
geändert werden.

Bin für jeden Hinweis dankbar! Wie sollte man da am besten vorgehen?

Vielen Dank
lg
R

[gfoidl]

Hallo,

zur Laufzeit kann mit dem XamlReader das "Markup" nachgeladen werden -> Dynamically Loading XAML.
Jetzt brauchst du noch einen Weg das XAML zu generieren und fertig.

Da XAML eigentlich nur XML ist, so sollte die Anpassung schon möglich sein. Vllt. gibt es auch fertige Designer die dafür verwendet werden können, aber bekannt ist mir keiner und gesucht hab ich auch nicht danach.

mfG Gü

[RM_ITA]

Hallo Gü,

vielen Dank, der Ansatz gefällt mir schon sehr gut!
Bin aber weiterhin für Idee, Ratschläge, usw. offen!

Vielen Dank
R

[Ralph Erdt (2)]

Ich gehe den "klassischen" Weg (und falle ganz schön oft auf die Schnautze):

• Im WPF muss das Root Element (oder das Element, mit dem man arbeiten will) benannt werden: Name="XYZ";
• Im Code dann:
  • ein Objekt mit "new" anlegen
  • mit XYZ.Children.Add(obj); an die Oberfläche packen
  • mit obj.Width = x / obj.Height = x; skalieren
  • mit Canvas.SetLeft(obj, wo) / Canvas.SetTop(obj, wo) positionieren

etc.

Ich bin sicher, dass ist nicht der Königsweg, aber was besseres habe ich nicht gefunden.

[RM_ITA]

Hallo Ralph,

danke das nutzt mir nicht viel. Anfoderung ist die. Ich habe ein fertiges Programm, installiert und beim Kunden im Einsatz. Nun
möchte ich dem Kunden die Möglichkeit geben, seine Masken selbst zu erweitern, sprich neues DAtenbankfeld anlegen, Masken anpassen.
Das gnaze soll natürlich über eine Art Maskeneditor gehen, wo der User die Felder verschieben kann, usw. Dazu kommt, dass an der Funktionalität
der Maske nichts geändert werden darf.
Evtl. soll der User auch eigene Events an Felder anhängen können, dies wäre aber der übernächste Schritt erst.

lg
R

[Ralph Erdt (2)]

Bei so einer Aufgabe ist Weg von gfoidl natürlich einfacher, nichts desto weniger trotz ist mein Weg auch eine gangbare Lösung - die mir sympatischer ist: (Rant Bei XAML wird zur Laufzeit analysiert und dann Fehler geschmissen. Man kann sich a) nie sicher sein, ob MS doch irgendwo die API breaking ändert und b) pb man nicht selbst einen Klopper gerissen hat. Daher ist mir meine Lösung sympatischer: Alles wird zur Compile Zeit validiert und ist dann gültig und lauffähig und funktioniert (IMHO hat XAML die gleichen Fehler wie SQL: Fehler nicht zur Compile-Zeit feststellbar).

[Christian Marquardt]

nichts desto weniger trotz ist mein Weg auch eine gangbare Lösung

Musst jetzt nur noch erklären, wie man zur Laufzeit deinen Code ins Programm bekommt

Fehler wie SQL: Fehler nicht zur Compile-Zeit feststellbar

Das sollte wie genau passieren?
Das ist ein "Fehler"?

Wenn ich also ein Steuerungsprogramm für einen Industrieroboter an diesen sende, und das läuft schief, ist es ein Fehler, dass die Fehler nciht beim compilieren entdeckt wurden?

[Ralph Erdt (2)]

Musst jetzt nur noch erklären, wie man zur Laufzeit deinen Code ins Programm bekommt

Code bekommt man nicht zur Laufzeit rein (Wir reden mal nicht von nachladen von DLLs, oder eine eigene Scriptingsprache). Klar. Aber man kann zur Laufzeit GUI-Objekte erstellen, positionieren, dimensionieren, einstellen, Ereignisse anhängen, und eben alles machen, was man machen muss/will (man muss manchmal nur etwas suchen wie es geht )

Mein Ansatz wäre: Speichern was "was und wo und wie". Also: Textfeld auf A6 (Sorry), und dann das Datenbing XYZ ran, bzw. auf ein Event verweisen, bei dem als erstes der Sender analysiert wird (forech (UserControl customcontrol in Customcontrols) if (sender == customcontrol ) ...) Alles am Anfang etwas knobeln, danach eine Fingerübung.

Das sollte wie genau passieren?
Das ist eine "Fehler"?

(Zusammenhang: "Fehler wie SQL: Fehler nicht zur Compile-Zeit feststellbar")

Hast Du es noch nie gehabt, dass ein WPF nicht so richtig funktionierte und du dann in den Debug-Ausgaben (Visual Studio Fenster "Output") Fehlermeldungen gesehen hast? Ich sehr oft. z.B. so etwas wie "Property XYZ auf ABC, Componente bla gibt es nicht." In einer klassischen Windows-Form würde das nicht passieren. (OK, Datenbindings haben auch ein "String" Feld - das ist auch ein Fehlereinfallstor. Aber nicht ganz so groß wie XAML)

Das es so ist ist kein "klassischer" Fehler; es ist eine meiner Meinung nach eine Design Fehlentscheidung. Ich habe das Gefühl, das gesamte XAML Geraffel ist eine "Me too" Sache von Microsoft, weil die so etwas wie HTML haben wollten... Und jetzt ist das über den Kopf gewachsen.

[RM_ITA]

Guten Morgen,

alles sehr interessant, was hier geschrieben wird, vielen Dank dafür. Zum Thema, Code zur Laufzeit hinzufügen. Darüber habe ich noch nicht so recht nachgedacht. Ist auch noch Zukunftsmusik.

Wichtiger ist dertzeit dem User eine Möglichkeit zu geben, seine Masken ändern zu können. Das muss meiner Meinung nach über einen eigenen Designer gehen, der das Grundlayout läd und die Standardfelder gleich einmal
sperrt, so dass diese nicht verändert werden können. Dann kann man auch gefahrlos neue Felder hinzufügen und mit einem DB-Feld verknüpfen, ja auch hier braucht es ein kleines Tool für die Erweiterung der DB.

Grundsätzlich bin ich von XAML schon angetan. Ernsthaft Fehler kann man nicht wirklich einbauen, das fällt ja schon bei der Entwicklung und Testing auf, damit hatte ich eigentlich noch nie wirklich Schwierigkeiten.