Suchergebnisse
Suchergebnisse 1-29 von insgesamt 29.
Hier erfahren Sie, wie einfach Sie Ihren Browser aktualisieren können.
-
du kannst dir auch einen meiner Uploads im Wpf-Tut-Bereich zu Gemüte führen. Und zurnot mit F10 starten und von anfang an im Einzelschritt durchsteppen. Wenn cih recht erinnere findet mein ganzer Startup im MainViewmodel statt. Nur eine Einstellung bezüglich CurrentCultur fäht bei mir im App.xaml-Codebehind herum - weil muss noch früher da sein.
-
oder gugge meine Wpf-Grundlagen - Tuts (also die, die mit "Grundlagen" markiert sind). Ist viel weniger durchzuarbeiten, weil die versuchen nicht, die ganze Wpf abzudecken. Sondern beschäftigen sich direkt mit den Kernthemen: MVVM-Pattern, Databinding + DataContext, Delegate-/RelayCommand-Commands und Templating-Wesen Ich empfehle denn auch diese Reihenfolge: Anwendungsstruktur, BindingPicking, ControlTemplates Das erstmal durchkauen - vorher kannste kaum sinnvolle Fragen stellen, weil was du vo…
-
Zitat von Haudruferzappeltnoch: „@ErfinderDesRades Ist das MainViewModel denn das Analogon zum StartForm bei Windows Forms?“Nein - es ähnelt eher den typisierten Datasets, wie ich sie in WinForms verwende. Ich siedele ja komplexe Business-Logik vorzugsweise in partiale Klassen des typDatasets an - Stichwort Trennung von BL und GUI. MVVM treibt das nu auf die Spitze: Es gibt gar keinen prozeduralen Code mehr im GUI: kein Button_Click - Event, kein Combobox_SelectedIndexChanged etc. Das gesamte Da…
-
Zitat von DTF: „Füge doch bitte noch einen privaten Konstruktor hinzu,“brauche ich nicht. Das Feld ist Shared Readonly - das kann nicht durch was anneres ersetzt werden. Ja, ok - iwelche Trollos mögen eine Instanz vom MainViewmodel sich erstellen, und konfuses Zeug damit anrichten - also bitte:VB.NET-Quellcode (7 Zeilen) Zitat von Haudruferzappeltnoch: „Bei dir läuft als erstes die Sub New von MainModel, da ist die Frage warum? Das ist ja im Endeffekt eine selbstgebaute Klasse, das kann ja nicht…
-
Klar, wenn Logik nur in einer Klasse benötigt wird, dann lässt man die Logik da, und braucht keine Basisklasse. Aber alle Viewmodelse mit veränderlichen Properties müssen zb INotifyPropertyChanged implementieren - das wär ja blöd, in jeder ViewmodelKlasse neu hinzuschreiben.
-
naja, wenn du in deim Leben nur 1 Wpf-Anwendung machen willst, brauchst du MainViewmodel-Funktionalität nicht auslagern. Und wenn deine Anwendung nur eine ViewmodelKlasse hat, und nie jemals weitere dazukommen werden - dann brauchst du auch keine ViewmodelBase. Aber da ist doch auch garnet so viel kompliziertes drin, oder? Nur INotifyPropertyChanged und IsInDesignmode - oder habich was vergessen?
-
ich würd nie zur Designzeit etwas aus einer Datei laden - allenfalls auf korrekte Weise aus den Wpf-Resourcen. Gut möglich auch, dass der Dateipfad zur Designzeit in ein anderes Directory verweist - probierma mittm vollqualifizierten Dateinamen. Btw - wieso biste denn da im MainWindow unterwegs? Dassis ja komplett gegen MVVM. Da brauch man im Grunde ja kein Databinding, wenn das Window die Daten selber ist.
-
Zitat von Haudruferzappeltnoch: „MVVM hab ich noch nicht“Also vergisses. WPF muss man mit MVVM anfangen, Templates sind nachrangig. Templates ohne MVVM sind - nur Klickibunti. Zitat von Haudruferzappeltnoch: „Wofür ist das DataContext = Me?“dassiis Databinding, wie man es genau nicht machen sollte. Jedes Visual - also auch ein Window - hat einen DataContext - entfernt vergleichbar der DataSource von WinForms-DGV, -Combobox, -Listbox. Diesen DataContext auf sichselbst einzustellen ist einfach MIs…
-
Zitat von Amro: „Bitte verbreite keinen solchen Unsinn. Spätestens wenn du einen DI-Container verwendest und Dependency Injection einsetzt, wirst du es nicht in XAML definieren können, da XAML nur den Basiskonstruktor verwenden kann.“hmm - Unsinn würde ich das deswegen nicht nennen. Klingt für mich eher nach einem starken Argument gegen Dependency Injection. Aber ich müsste es mal probieren. Durchaus möglich, dass ich einen Weg finden würde, mir Designtime-Unterstützung trotz DI zu erhalten. (Sa…
-
<local:MainModel /> ist glaub keine gute Idee, weil das instanziert ein Mainmodel . weil wenn jedes View sich sein eigenes Mainmodel instanziert hat man viele Mainviewmodelse und Chaos. Zitat von Haudruferzappeltnoch: „Wird das Mainmodel mit dieser StaticRessoure Anweisung instanziert?“Ich denke, das MainModel ist in den Resourcen von App.Xaml angelegt. Dort ist es instanziert, und daran kann alle View binden - ohne dass Dubletten entstehen.
-
warnix bedeutet, ich hatte zu schnell losgeblubbert, und nehme meinen post zurück.
-
Zitat von ErfinderDesRades: „Dort ist es instanziert, und daran kann alle View binden“Jepp - das ist auf die BeispielSolution von mir gemünzt, die Hdz am Wickel hat. Wie gesagt: vom Main(View)Model darfs nur eines geben, und eine Lösung ist, es in App.xaml (VB: Appliccation.Xaml) in die Resourcen zu legen. Ist der Fehler aus post #22 denn nu weg?
-
So, jetzt habich das Tut selbst nochmal downgeloaded, geöffnet, kompiliert, und dann ins MainView.Xaml geguckt: alles paletti. Also weiss ich nicht das problem Und nix wegmachen der / hat eine wichtige Funktion: Dadurch wird an das aktuelle Item einer CollectionView gebunden, und nicht an die ganze Liste.
-
Zitat von Haudruferzappeltnoch: „You only can instantiate MainModel when MainModel.Instance.IsNull or MainModel.Instance.IsProvisional“Dassis doch ein nützlicher Hinweis - den habich programmiert. Offensichtlich wird dein Mainmodel mehrfach instanziert, for whatever reasons. Was ja wie gesagt nicht gut ist.
-
Habe nun einen möglichen Fehler-Grund: Ersetze mal die Public Shared Function IsInDesignMode() As Boolean durch folgende Version:VB.NET-Quellcode (7 Zeilen) Und dann bereinigen, rekompilieren, VS schliessen und wieder öffnen. Das dämliche ist, zur Designzeit muss bei diesem Ansatz das Mainmodel mehrfach instanzierbar sein - aber zur Laufzeit nicht. Also muss man sich eine Public Shared Function IsInDesignMode() As Boolean programmieren. Die vorherige Variante funzt auch bei WinForms - wo ich das…
-
ja genau. Und mit Process.GetCurrentProcess().ProcessName wird der abgerufen, und ist zur Designzeit ein anderer als zur Laufzeit. Nachgucken kann man die VS-Prozesse im Taskmanager. vb-paradise.de/index.php/Attachment/54274/ Kannste mir den deinigen mitteilen? bislang lautet meine Sammlung ja: VB.NET-Quellcode (1 Zeile)
-
ich hab im helpers-projekt den rootnamespace gelöscht. aber das ist eine heikle sache, heut würdich solch nicht tun. man kann nämlich den namespace auch so definierenVisual Basic-Quellcode (1 Zeile)aber sparsam mit umgehen - dass man die MS-Namespaces nicht zu sehr vollmüllt mit eigenem Kram. Manche Programmierer lehnen das auch insgesamt ab, und sagen: willst du eigene Infrastruktur einbinden, sollste den Import gefälligst auch drüber schreiben.
-
und zur laufzeit zeigts richtig an? weil sonst sind halt einfach die bindings falsch, und das wäre dann ja grad der DesignTime-Support, dass du gleich siehst, dasses net funzt.
-
Zitat von Haudruferzappeltnoch: „Ich kriege auch von Intellisense Vorschläge zu den Membern von Data.“kriegst du offenbar nicht. Da läuft was komplett schief - normalerweise braucht man "Benutzerdefiniert" nicht, und kriegt dennoch was angeboten. Gugge nochma Tut. vb-paradise.de/index.php/Attachment/54345/ Oder du arbeitest mit typDataset - da ist DesignTime-Support ja nicht gescheit unterstützt
-
Zitat von Haudruferzappeltnoch: „Achja, und der DataContext ist anders definiert!“tja, da wird wohl HasePfefferZitat von Haudruferzappeltnoch: „Wie gesagt bei mir der Singleton-Weg.“bei mir ja auch - gugge Bildle. man muss übrigens immer feste kompilieren, sonst versucht der Xaml-Designer an was zu binden, was nicht uptodate ist. Zitat von Haudruferzappeltnoch: „Versuche dann erstmal anders mehrere Instanzen zu verhindern“wird so nicht funktionieren, im Designer schon nicht - aber wirste schon s…
-
jau, du hast recht - Start-Tag muss so aussehen:XML-Quellcode (9 Zeilen)Ändert sich ansonsten nix anne Funktion vom Xaml-Designer. nu müsste man mal deinen StartTag angucken...
-
Zitat von Haudruferzappeltnoch: „Hier bindet derjenige selbstständig mit Path“äh - binde ich denn nicht mit Path? Zitat von Haudruferzappeltnoch: „ so wie es das Studio bei mir ja automatisch macht:“äh - was macht VS bei dir automatisch?
-
Zitat von Haudruferzappeltnoch: „Und soweit das Fehlverhalten was ich bezeuge quasi "normal".“Tja, definiere "normal". Bei mir gilt als normal, wenns funktioniert, und dass du in deim Xaml nicht an Singletons binden kannst, findich nicht normal. Vielleicht kannst du ein Sample-Projekt hochladen, was den Fehler reproduziert?
-
DataContext ist keine Klasse, sondern ist eine Property. Ansonsten kann man xaml Code Definitionen im Xaml nachgucken, also da, wo man sie hingeschrieben hat. Aber vielleicht zielt deine Frage auf das hier ab: Grundlagen - Xaml-Syntax Da wird anfangs angedeutet, wie eine Xamll-Einschachtelung als Property zu verstehen ist. Alles weitere ergibt sich daraus. Alsso man kann tatsächlich ein Stück Xaml nach vb.net übersetzen.
-
ich verstehe deine Satze immer nicht. Zitat: „In einer Definition von Microsoft findet man da meistens was zu, aber sowas scheint es da nicht zu geben?“"in einer Definition findet man was???" "aber sowas scheint es nicht zu geben???" was fürn sowas denn?
-
wenn ich dei Frage nun ricchtig verstund, ist sie tatsächlich im in post#55 verlinkten Tut beantwortet. DataContext="{Binding Source={x:Static vm:Data.Instance}}" bedeutet, dass dem DataContext ein Binding-Objekt zugewiesen wurde - steht da ja. DataContext="{x:Static vm:Data.Instance}" bedeutet, dass dem DataContext das vm:Data.Instance-Objekt zugewiesen wurde. (Ich bin allerdings irritiert davon, dass bei dir letzteres mit dem Xaml-Designer zusammenarbeitet, ersteres nicht. Weil bei mir arbeite…
-
Bei Welchem Control und welcher Property darin willst du denn ein Binding setzen mit dem Binding-Editor? Wie gesagt: Sample-App wäre vlt. ganz sinnvoll
-
jo, es ist wie du sagst. Bei DataContext="{Binding Source={x:Static local:Singleton.Instance}}" funzt der Binding-Editor net ich hab übrigens das FW auf .net.5 runterdrehen müssen. In FW4.8 isses anders, da funzzen beide Varianten: DataContext="{x:Static local:Singleton.Instance}" DataContext="{Binding Source={x:Static local:Singleton.Instance}}" Ich bin echt angekäst von Wpf, dass man sich in einer 15 Jahre alten Technologie noch mit solchen Kinderkrankheiten rumschlagen muss.
-
jo, hab kein .net.6