Abarbeitungs-Reihenfolge mittels Combobox festlegen.

  • WPF

Es gibt 51 Antworten in diesem Thema. Der letzte Beitrag () ist von Nofear23m.

    Hallo NoFear23m,
    ​Hast dich mal wieder mächtig ins Zeug gelegt, hast keine Mühe gescheut. Super!

    Nofear23m schrieb:

    Habe mir die Demo gerade angesehen. OK. Ist es richtig das sich hier ja nicht viel verändert hat? Nur löschen oder?

    Ja, so ist es. Ist zwar nicht so viel, hat mich aber schon etwas Mühe gekostet... Und dann kommst du mir mit Refactoring!
    Schön und gut wenn das die "bessere" Lösung wäre. Aber damit muss ich mindestens solange warten bis ich weiss was Refactoring ist und wie man es einsetzt. ?( :?:

    Nofear23m schrieb:

    Es war/ist ja eigendlcih recht ungeschickt von mir implementiert das sich die WorkCenterVMs nicht mit den OrdersVms snycronisieren. Ich hatte das so gemacht weil ich dachte das du ja auch noch was zu tun brauchst. Sowas würde ich mit einem Refactoring machen.

    Aber schön, dass du mir das zumutest... ^^
    ​Wie gesagt hab ich keinen Schimmer von einer Ahnung was Refactoring sein könnte. Ich kenn das eben nicht anders als "à la DoRefresh". Werde mir aber mal ansehen was Google darüber weiss.

    ​Frage: Womit kann ich, im Kontext der Demo, die besten Treffer bei Google landen?
    ​Mit "WPF Refactoring" oder vielleicht eher "VB.NET Refactoring" oder.........

    ​Ja, ich hatte mich tatsächlich auf das Löschen der Orders im Grid konzentriert und so die Orders in den Listen der WorkCenter glatt vergessen. Aber das hast du jetzt ja gerade gebogen. Danke.

    ​Also was Drag & Drop angeht,
    ​also für mich noch etwas zu hoch! Kann mir jetzt noch nicht vorstellen sowas ohne Hilfe auf die Reihe zu kriegen. Bin aber froh, ein funktionierendes Beispiel zu haben, zum lernen und zum abgucken.

    ​Für mich enthält die Demo auf jeden Fall alles was ich benötige um meine Order App zusammen zu basteln. :thumbsup:


    ​Danke,
    Jeiss
    @Jeiss

    Keine Angst. Refactoring bedeutet beim programmieren nichts anderes wie "nacharbeiten".

    Im Grunde ist es ja so das man meisst ne Idee im Kopf hat.
    Man setzt diese Idee um. Natürlich nicht super gut und immer sauber.

    Man klatsch auch mal nen Code hin und probiert sein vorhaben mal aus.

    Sehr cool. Die Idee geht auf, es funzt so wie man sich das vorgestellt hat.
    Also auf zum Refactoring. Code durchgehen, säubern, optimieren, kürzen, loggen, Kommentieren oder was weis ich was.

    Beispielsweise rufe ich gerne während ich ein VM fertig mache alle Spalten von einer Tabelle (DB) ab weil es mir in dem Moment nicht so wichtig ist ob die Abfragen performant sind.
    Auch ist mir in diesem Moment nicht wichtig wieviele Abfragen ich mache. Ob ichs Teile oder mit Joins löse, das muss ich mir dann alles danach ansehen.

    Beispiel:
    In der ersten Implementierung einer Useranmeldung sieht der SQL vieleicht so aus:

    SQL-Abfrage

    1. SELECT TOP(1) *
    2. FROM [Users] AS [u]
    3. WHERE [u].[UserName] = @param1

    Ich habe den User dann inkl. der Passwortspalte und kann nun vergleichen obs richtig eingegeben wurde.

    Erstens werden alle Spalten abgerufen was schon mal nicht so optimal ist, wozu. Brauche ich doch alles nicht. In einer Tabelle "User" können sich gut und gerne mal 20 Spalten auch befinden, vieleicht bei Byte() Spalte mit einem Benutzerbild mit 1MB usw.
    Zweitens kann die Abfrage an sich ja auch besser formoliert werden. Ich will ja nur wissen ob das Passwort korrekt ist, Dafür brauche ich aber gar keine Daten.

    SQL-Abfrage

    1. SELECT CASE
    2. WHEN EXISTS (SELECT 1
    3. FROM [Users] AS [u]
    4. WHERE ([u].[UserName] = @param1)
    5. AND ([u].[Password] = @param2)) THEN CAST(1 AS BIT)
    6. ELSE CAST(0 AS BIT)
    7. END


    Das gibt mit True oder False zurück. Mehr benötigt es nicht.
    Habe absichtlich einen vergleich mit eine DB Abfrage gemacht damit du erkennst das es nicht um ein gewisses Thema bei "Refactoring" geht. Das ist ein Allgemeiner Begriff.

    Man, schon wieder so ein Roman. Ich schweife immer so leicht ab.
    Naja, gute nacht.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Hallo NoFear23m,
    gut dass du dich so schnell gemeldet hast.
    Hab nämlich das da gefunden.

    docs.microsoft.com/de-de/visua…actoring-in-visual-studio

    Und die bei MSDN sehen das irgendwie nicht so locker. Die beschreiben Refactoring eher als "features" der IDE wenn ich das richtig verstanden habe.
    ​Aber ich komm doch noch mal auf "dein" Refactoring, im Zusammenhang mit der Demo zurück. Aber heute nicht mehr. Die Augen werden schon müde....

    ​Danke,
    Jeiss

    Jeiss schrieb:

    Und die bei MSDN sehen das irgendwie nicht so locker. Die beschreiben Refactoring eher als "features" der IDE wenn ich das richtig verstanden habe.

    Nicht so locker ist gut. Die sehen das genauso. Nur das hier ein Feature des IDE (VisualStudio) hevorgehoben wird welches die Refactoring erleichtert.

    Refactoring
    stellt den Prozess der Codeänderung mit dem Ziel dar, diesen leichter
    verwalten, verstehen und erweitern zu können, ohne dabei das Verhalten
    zu ändern.

    Doch genau das was ich gesagt habe, nur besser beschrieben :D
    Wenn ich mit Hilfe der IDE mit einem Tastendruck code kürzen oder verbessern kann ist das Refactoring. Oder? Ob ich das jetzt selbst machen oder die IDE mir dies vorschlägt ist doch schnuppe.

    Beispiel: VS kann mir mit seinen Helferlein aus Dim test As String = Me.DataContext innerhalb von ein paar klicks Dim test = CType(DataContext, String) machen.
    Nicht immer ist das was VS vorschlägt gut und Hilfreich, aber es Hilft dennoch. Besser anpassbar und auch inteligenter und flexibler ist hier ReSharper.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Hallo,
    ja wenn das so ist, dann hab ich auch schon Refactoring betrieben. Ich bin da aber immer sehr vorsichtig damit, denn nach dem Refactorieren soll der Code ja noch richtig funktionieren....
    Ok, soweit alles gut. Aber bevor wir weiter um Refactoring diskutieren hätte ich ne Frage zu der DoRefresh Methode. Oder besser gesagt zu RaisePropertyChanged
    Gleich in der Ersten Zeile der Methode steht:

    VB.NET-Quellcode

    1. Public Sub DoRefresh()
    2. RaisePropertyChanged()

    Ich kenn bisher nur den Aufruf RaisePropertyChanged() aus dem Setter einer Property her.
    Weiss nicht genau was der macht aber irgendwie (so stell ich mir das jedenfalls vor....) setzt der einen Mechanismus in Gang um Gebundene Elemente in einem View über die Änderung der Eigenschaft zu informieren.
    So Meine Frage jetzt. Dieser RaisePropertyChanged Aufruf innerhalb einer Prozedur ist der gewollt, macht der Sinn oder hast du den "für alle Fälle" reingetan und man könnte den bedenkenlos raus- Refaktorieren?

    Und jetzt zum Refactoring deiner Demo. Meine Frage betrifft Post N°31.
    Ok, deine Demo mag nicht optimieret sein, gut aber sie funktioniert. War und ist mir immer noch sehr wichtig.
    Aber ich verstehe gar nicht richtig was da Refaktoriert werden sollte/könnte.

    Nofear23m schrieb:

    Im Moment ist es ja so das man die Vms Syncron halten muss. Ändert sich also die Reihenfolge weil man diese im DataGrid umstellt so muss im Code die Reihenfolge auch für die WorkCenter (die Listboxen oben) nachgetragen werden. Kann man gut sehen in OrderVm im Setter von CurrentOrderSequence
    .......
    Viel schöner wäre es wenn diese VMs das mitbekommen würden. Dann spar man sich die Arbeit. Aber ist kein muss.

    Also, wenn die Reihenfolge der Order oben in den Listen nicht per Code nachträglich angepasst werden soll, dann kann das ja nur noch durch Optimierung der Bindung ganz automatisch und synchron erledigt werden?
    Oder wie soll ich mir das vorstellen?

    Danke,
    Jeiss
    ----------------------------------------
    Halt! Fehler!
    Meine Frage betrifft nicht Post N°31, sondern N° 39!
    ​Sorry
    Hallo

    Jeiss schrieb:

    Ich kenn bisher nur den Aufruf RaisePropertyChanged() aus dem Setter einer Property her.
    Weiss nicht genau was der macht aber irgendwie (so stell ich mir das jedenfalls vor....) setzt der einen Mechanismus in Gang um Gebundene Elemente in einem View über die Änderung der Eigenschaft zu informieren.
    So Meine Frage jetzt. Dieser RaisePropertyChanged Aufruf innerhalb einer Prozedur ist der gewollt, macht der Sinn oder hast du den "für alle Fälle" reingetan und man könnte den bedenkenlos raus- Refaktorieren?

    Das ist ein gutes Beispiel zu einem überbleibsel welches im Zuge von einem Refaktoring aufgeräumt werden würde. Wie du richtig erkannt hast wir die erste Zeile der Prozedur nicht benötigt weil sie schlicht nichts bringt. Es passiert jetzt kein Fehler und sonst wirkt es sich nicht wirklich negativ auf die Performance aus aber es ist schlichtweg unnötig. Also weg damit. Vermutlich ein überbleibsel wo ich noch ein Zusätzliches Property updaten wollte und es dann doch nicht benötigt habe. Sowas passiert schon mal. Die nächsten zwei Zeilen aber werden benötigt.

    Jetzt genauer. Wenn du dir die Methode ansiehst:

    VB.NET-Quellcode

    1. Protected Overridable Sub RaisePropertyChanged(<CallerMemberName> Optional ByVal prop As String = "")
    2. If prop IsNot Nothing AndAlso prop.Length > 0 Then RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(prop))
    3. End Sub

    CallerMenmberName holt sich einfach den Namen den "Aufrufers". In den Meissten Fällen ist das das jeweilige Property. Deshalb musst du hier nichts mit angeben.
    Solltest du Beispielsweise von dem Property FirstName oder LastName der WPF mitteilen wollen das sich das readOnly Property FullName damit auch geändert hat hättest du folgendes stehen:

    VB.NET-Quellcode

    1. Private _firstName As String
    2. Public Property FirstName() As String
    3. Get
    4. Return _firstName
    5. End Get
    6. Set(ByVal value As String)
    7. _firstName = value
    8. RaisePropertyChanged()
    9. RaisePropertyChanged("FullName") 'oder besser RaisePropertyChanged(NameOf(Fullame))
    10. End Set
    11. End Property
    12. Public ReadOnly Property FullName() As String
    13. Get
    14. Return String.Format("{0} {1}", FirstName, LastName)
    15. End Get
    16. End Property


    Zu deiner Frage bez. Optimierung wegen der Syncronisierung der Klassen.
    Im Moment ist es so das wenn sich in OrderVm eine Reihenfolge oder ein Workcenter ändert nicht vergessen werden darf diese änderung in allen WorkCenterVM Klassen auch einzutragen.
    Sowohl beim ändern des aktuallen WorkCenter einer Orders als auch bei der OrderSequence selbst muss immer nach dem WorkCenter (eines der drei oben) gesucht werden und dort auch die änderung aktualisiert werden.
    Und das wäre eleganter und schöner wenn die WorkCenter diese änderung automatisch mitbekommen würden. Z.b. weil es in Order Events hierfür geben könnte welche dann gefeuert werden wenn etwas in dieser Art passiert. So können die WorkCenterVMs darauf reagiert. wie gesagt. Nicht unbedingt notwendig aber eleganter.

    Aber wie schon erwähnt wollte ich den Code einfach und verständlich halten. Wie weit man das ganze treiben möchte muss man selbst entscheiden.


    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Hallo,
    ok so war das also mit dem Refactoring gemeint.
    Ja ein Event wäre natürlich eleganter, das steht fest.
    Aber, das ist jetzt nicht böse gemeint. Ich weiss , dass du dir sehr viel Mühe gegeben hast um mir zu helfen. Das hast du auch ohne Zweifel. Sogar über mein Problem hinweg. Ich hab noch dazu gelernt.
    Aber deine Demo war auch in meinen Augen "nur" eine Demo um mir eine Lösung vor zu schlagen. (und zwar so dass auch ich was kapiere)
    Und das bedeutet viel einen zu grossen Aufwand für mich deine Demo noch eleganter zu gestalten. Dafür beherrsche ich WPF und VB.NET noch viel zu schlecht um das einfach so zum Spass zu machen...
    Ok auf jeden Fall wäre das dann mal klar. Und ich kann mir jetzt überlegen ob ich das Thema beenden kann/sollte.

    Aber "deine" Events erinnern mich an ein anderes Problem dem ich in meiner App begegnet bin.
    Aber das gehört definitiv in ein neues Thema.
    Naja trotzdem nur damit du weist um was es geht....

    In meiner App werden die Orders in einem Grid angezeigt. An sich wie in deiner Demo ja auch.
    Nur gibt es in meiner App ein paar Eigenschaften der Order die man direkt im Grid editieren/ändern kann.

    Mein grid hat eine IColletionView als ItemsSource. Und die "darunter liegende" (oder wie sagt man dafür) ObservableCollection(Of OrderVm) kriegt diese Aenderungen irgendwie nicht mit! ?(
    Da musste ich auch mit einem Event nachhelfen..... Ist aber nicht logisch für mich, dass der nur mitbekommen soll wenn ein ganzer Order entweder hinzugefügt oder ganz gelöscht wird, nicht aber wenn eine Eigenschaft geändert wurde.
    Um das zu beheben musste ich also Refactorieren... Bin aber überzeugt dass das eher an einem Fehler meinerseits liegt und dass gar kein Refactoring bzw. zusätzliches Event nötig gewesen wäre.

    Aber wie gesagt wenn ich damit nicht klar komme, dann fang ich ein neues Thema an.

    Auf jeden Fall danke ich dir Für deine Hilfe und all deine lehrreichen Erklärungen.

    Jeiss
    Hallo

    Ja. Mach ein neues Thema dafür auf und zeige den XAML und deine OrderVm Klasse.
    Da mpssen definitiv keine Events herhalten. Das macht dir das Binding.

    Grüße
    Saacha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Hallo,
    Muss mich entschuldigen. Das Problem das ich vorhin beschrieben hab, ist in Wirklichkeit etwas anders als ich es vorhin beschrieben hab...... Sorry!

    Es ging nicht darum der ObservableCollection mitzuteilen wenn eine Eigenschaft eines Orders im Grid geändert wird, das schafft die Bindung ganz ohne zusätzliches event.
    Aber wo ich etwas schreckliches "zusammen ge-Refraktoriert" hab um ein Ergebnis zu erzielen war der versuch eine funktionierende SaveCommand_CanExecute Funktion fur meinen Save Button zu basteln.(sollte nur aktiv sein wenn es auch tatsächlich was zu saven gibt)

    Das CollectionChanged Event der ObservableCollection feuert schön brav wenn ein Order hinzugefügt oder gelöscht wird, nicht aber wenn bloß eine Eigenschaft eines Orders im DataGrid geändert wurde.
    Und das Problem das hab ich tatsächlich noh, und das muss definitiv ein Refactoring her....

    Danke,
    Jeiss
    Auch das denke ich wir ohne Event machen können. Wie gesagt. Mach nen Thread auf.

    Im Grunde brauchst di wie im EF ein HasChanges des DBContext.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Hallo,
    ​Ja eben "wie bei EF"....
    ​Aber ich weiß nicht ob du dich dran erinnern kannst.
    ​Anfangs wollte ich meine Orders mit EF verwalten, war dann noch ein paar Nummern zu hoch für mich....

    ​Ok, wenn ich nicht klar komme, mach ich ein neues Thema auf.

    ​Danke,
    Jeiss
    Hallo

    Klar kann ich mich erinnern. Hatten da je einige Diskussionen über EF selbst auch.
    Ich Arbeite SEHR gerne mit EF und kenne aber auch die Fallstricke und damit verbundenen Probleme und hürden.

    Egal wie DU jetzt speicherst, dein vorhaben lässt sich auf jeden Fall umsetzen.
    Es gibt hierfür mehrere Wege. Welcher der beste/einfachste ist kann man ohne dein Model und dein ViewModel zu sehen nicht wirklich sagen.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.