MVVM OpenSource Communityprojekt - HomeStorage

  • WPF

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

    Es ist kein problem wenn du später erst fragen stellst.
    Im Moment ist es noch nicht viel. Ich sage mal. mit 20-30 Minuten bist du SICHER mit dem aktuellen code durch, so das du dir ein paar Fragen zusammengetragen hast.
    Ich mache immer nur Stückchen für Stückchen weiter, so das es nicht zu viel auf einmal wird. So kann man von Commit zu Commit immer schön sehen was sich getan hat und welcher Code hinzugekommen ist.

    Zu viel innerhalb eines Comit ist nicht gut, dan kann niemand mehr folgen.

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

    "MichaHo" schrieb:

    Hi,
    Ich weis nicht ob das jetzt richtig war, aber wenn ich in der GitHub Desktop in den Einstellungen des Repository den Remote auf https://github.com/NoFear23m/HomeStorage.git ändere, bekomme ich alle änderungen direkt mit, (man muss dann auf Fetch origin drücken, wobei das glaub auch ab und an automatisch gemacht wird.
    vb-paradise.de/index.php/Attac…e4edaec370a0dc06a23a6a638vb-paradise.de/index.php/Attac…e4edaec370a0dc06a23a6a638vb-paradise.de/index.php/Attac…e4edaec370a0dc06a23a6a638vb-paradise.de/index.php/Attac…e4edaec370a0dc06a23a6a638


    Hi,

    Im Prinzip spricht nichts dagegen, allerdings hättest du dir den Fork dann sparen können und direkt von @Nofear23m 's Repository klonen können.
    Du hast dann die Repository lokal, kannst diese auch ständig auf den aktuellen Stand bringen, aber du hast nicht die Möglichkeit deine Änderungen publik zu machen.
    Wenn du wirklich vor hast dich am Projekt zu beteiligen musst du einen Fork machen und deine Repository so verwalten wie ich gezeigt habe. Andererseits kannst du keine Pull Requests erstellen, denn um direkt zur Repository zu pushen fehlen dir die Rechte. Sonst könnte jeder einfach in die Repository rein schreiben. ;)

    Ich empfehle übrigens sich Git wirklich mal genauer anzuschauen und versuchen zu verstehen wie es funktioniert bzw. wie man damit arbeitet.
    Für mich ist Git bei jedem Projekt wo man länger als ne Stunde dran arbeitet mittlerweile ein Muss! :D
    Hi,

    OK, Danke für den Hinweis... dann bügel ich das noch mal um...
    Ich arbeite hier eigentlich mit VisualSVN und nicht mit Git...

    EDIT: @seh hat wunderbar geklappt.... :thumbsup: (und hat auch garnicht weh getan)
    "Hier könnte Ihre Werbung stehen..."

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „MichaHo“ ()

    Hallo Leute

    Am Weekend hatte ich leider wenig Zeit. Heute werde ich allerdings wieder etwas machen. Nicht zu viel damit jeder folgen kann aber denn

    Akanel schrieb:

    Aber heute Abend nehme ich es mir Mal fest vor und schaue mir das Projekt an. Sonst komme ich im halben Jahr erst mir meinen Fragen.

    Falls du bereits dazu gekommen bist kannst du gerne noch Fragen einwerfen. Gerade der Code am Anfang des Projekts ist enorm wichtig diesen zu verstehen da alles weitere auf diesem Aufbaut.

    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 Leute

    Wie versprochen habe ich heute wieder was getan.

    Es wurde noch ein Projekt der Projektmappe hinzugefügt. HomeStorage.DAL (DAL = DataAccessLayer)
    Und noch eines mit dem Namen HomeStorage.BL (BL = Businesslogik)

    Dieser DAL Zwischenlayer wird dafür zuständig sein die Daten über EntityFramework Core abzurufen oder wieder darüber zu persistieren.
    Jetzt fragt Ihr euch sicher "Wozu in einem extra Layer"? Warum kann ich das nicht direkt im ViewModel machen?
    Berechtigte Frage und man kann es auch machen. Dann bin ich aber auf EF Core gebunden. Ich kann also die Art und weise wie oder von wo ich Daten abrufe nicht mehr ändern ohne eigendlich das ganze Programm neu zu schreiben.
    Habe ich mal zig ViewModels und überall in meinem Programm Prozeduren verteilt wo ich Daten über EF abrufe oder speichere kann ich nicht plötzlich sagen "Ja, ich will jetzt aber auf ein Webservice umstellen".
    Habe ich eine eigene Datenzugriffsschicht wird dies schon mal um einiges einfacher. Hat man es wie in unserem Fall sogar noch als generisches Repository wirds noch viel einfacher, dazu später aber mehr.

    Tja, und die BL - Schicht? Das wird unsere Businesslogik, hier wird die Logik verpflanzt. Ja, auch hier habe ich mich dazu entschieden eine eigene Schicht zu erstellen. Auch dies könnte man im ViewModel haben und sich damit die Struktur und die Übersicht zerstören. Viele haben am Anfang das Problem das sie darüber klagen durch die vielen Schichten keine Übersicht mehr zu haben, jedoch ist genau das Gegenteil der Fall was allerdings nicht sofort auffällt. Aber mit jeder Zeile Code welche in den einzelnen Schichten geschrieben wird kommen immer mehr die Vorteile der "Layertrennung" zu Tage. Immer und immer mehr Ordnung!! Mit jeder Zeile Code. Am Anfang vieleicht schwer zu glauben, es ist aber dennoch so. Vieleicht kann evtl. @Thomi was hierzu sagen!

    In die Businesslogik kommt der ganze "Denkkram" rein. Damit meine ich Dinge wie: Ein Artikel wird verlangt -> Ist eines Lagernd? -> vom Lagerstand abgziehen -> ist Mindestlagermenge unterschritten dann auf Einkaufsliste setzen -> usw.
    Das sind Dinge die will ich nicht in meinem ViewModel haben, das ist nicht schön und auch schnell mal unübersichtlich.

    Wie funktioniert das generische Repository:

    Ich will nicht zu sehr in die Theorie gehen, wir haben ein Interface IGenericRepository(Of T As Class)
    Dieses Interface gibt einiges an Eigenschaften und Methoden vor. Hier sollten die einzelnen Namen der Methoden eigendlich für sich selbst sprechen, ansonsten kann ich diese gerne Kommentieren.
    Unsere Repository-Basisklasse GenericRepository(Of T As Class) implementiert dieses Interface und haucht den Methoden leben ein.
    (Aber da diese Klasse eine Basisklasse ist kann auch dies noch nicht instanziert werden.)
    Hier wird in den einzelen Methoden erstmals auf die Methoden und Eigenschaften vom EntityFramework zurückgegriffen.

    VB.NET-Quellcode

    1. Public Overridable Function Find(id As Integer) As T Implements IGenericRepository(Of T).Find
    2. Debug.WriteLine($"Find (Direct return) for T of Type {GetType(T).ToString}")
    3. Return CType(_entities, StorageContext).[Set](Of T).Find(id)
    4. End Function

    Beispielsweise wird hier über den DB Context welchen wir erstmal Casten müssen da _entities vom Typ Object ist eine Entität mit einer gewissen ID vom EF Core verlangt.
    EF Core bietet für das Object vom Typ DBSet die Methode Find an welches eine Entität anhand eines Primärschlüssels finden kann.

    Hier eine Frage in die Runde: Warum ist _entities oder das Property Context ein Object und NICHT vom Typ StorageContext????

    Hier findet Ihr das Commit zwecks besserer übersicht der Änderungen.

    Grüße
    Sascha

    PS: Bei Fragen bitte keine scheue.
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Nofear23m“ ()

    Nofear23m schrieb:

    Unsere Repository-Basisklasse GenericRepository(Of T As Class) implementiert dieses Interface und haucht den Methoden leben ein.
    Wozu implementiert sie es?
    Eine Basisklasse kann doch von sich aus Basis-Funktionalität bereitstellen - da braucht sie doch nicht auch noch ein Interface erfinden und implementieren?

    Also einfach so:

    VB.NET-Quellcode

    1. Public Overridable Function Find(id As Integer) As T
    2. Debug.WriteLine($"Find (Direct return) for T of Type {GetType(T).ToString}")
    3. Return CType(_entities, StorageContext).[Set](Of T).Find(id)
    4. End Function
    In meinen Augen schon mehr als genug.

    ErfinderDesRades schrieb:

    Eine Basisklasse kann doch von sich aus Basis-Funktionalität bereitstellen - da braucht sie doch nicht auch noch ein Interface erfinden und implementieren?

    Wie bereits geschrieben soll für jeden einzelnen Layer auch möglich sein UnitTests zu schreiben. OK, EF Core kann man durch die Einführung eines InMemoryProviders zwar auch schön ohne ein Interface Testbar machen aber hier geht es ja nicht nur um EF Core, sollte sich die Art und weise WIE ich Daten abrufe ändern möchte ich auch in diesem Fall meine UnitTests weiter verwenden können. Ohne einem Interface kann ich keine Mocks erstellen womit meine Klassen ALLE untestbar sind. Ich muss dann also nachträglich(!) wieder hand anlegen was eher mühsahm ist da ich dann jede Klasse wieder bearbeiten muss.
    Das ist der Grund warum ich gerne von Haus aus ein Interface schaffe. Ich kann diese sowohl für Mocks als auch für Stubs verwenden. Ausserdem tuts nich weh, ich weis das du gerne puristisch denkst, ich bin eher der jenige der lieber eine Möglichkeit mehr in Betracht zieht als eine zu wenig. Wenn ich schon die Layer brav trenne um UnitTests machen zu können und die Art wie ich Daten abrufe oder speichere evtl. tauschbar zu machen dann möchte ich mir keine dieser Möglichkeiten zerstören nur weil ich eines dieser Dinge dann tatsächlich mache :huh:

    ErfinderDesRades schrieb:

    In meinen Augen schon mehr als genug.

    Was meinst du genau?

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

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Nofear23m“ ()

    naja - sieht mir aus, als wollest du für jede Entität ein eigenes Repository basteln.
    in meim Verständnis wäre ein Repository aber eine größere Einheit, die mehrere miteinander zusammenhängende Entitäten abdecken würde.
    Ausserdem enthält die gezeigte Methode so wenig Logik, dassich drüber nachdenkte, obs nicht eine schmerzfreie Möglichkeit gibt, sie ganz wegzulassen.

    ErfinderDesRades schrieb:

    naja - sieht mir aus, als wollest du für jede Entität ein eigenes Repository basteln.

    Richtig, es wird dann für so gut wie jede Entität eine Klasse geben welche von GenericRepository erbt.

    VB.NET-Quellcode

    1. Imports HomeStorage.DbContext
    2. Public Class ArticleRepository
    3. Inherits GenericRepository(Of Model.StorageModel.Article)
    4. Public Sub New()
    5. MyBase.New
    6. End Sub
    7. Public Sub New(context As Object)
    8. MyBase.New(kontext:=CType(context, StorageContext))
    9. End Sub
    10. Friend Sub New(ctx As StorageContext)
    11. MyBase.New(kontext:=ctx)
    12. End Sub
    13. End Class


    ErfinderDesRades schrieb:

    in meim Verständnis wäre ein Repository aber eine größere Einheit, die mehrere miteinander zusammenhängende Entitäten abdecken würde.
    Ausserdem enthält die gezeigte Methode so wenig Logik, dassich drüber nachdenkte, obs nicht eine schmerzfreie Möglichkeit gibt, sie ganz wegzulassen.

    Mmmhhhhh, meinst du eine UnitOfWork? Schau mal hier bitte rein.
    Wenn du eine "schmerzfreie" Möglichkeit weist würde mich das freuen. Für mich war bis Dato immer dieses Pattern das "schmerzfreieste" ohne Verlust von "komfort".
    Aber gerne, genau dafür ist dieser Thread ja da. Wir möchten ja eine gute und solide MVVM Applikation bauen welche so gut wie möglich Skalierbar ist und dazu zählt auch das man die Art wie CRUD Operationen ausgeführt werden änderbar ist. Denn Anforderungen ändern sich nun mal.

    Ich weis, es ist in der Basisklasse recht wenig Code enthalten, dies hat aber damit zu tun das EF Core bereits im UnitOfWork erstellt wurde. Hierdurch ist es für uns in diesem Fall einfach, das ändert sich aber schnell wenn auf eine andere Art und weise Daten abgerufen werden sollen.

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

    Nofear23m schrieb:

    Hier eine Frage in die Runde: Warum ist _entities oder das Property Context ein Object und NICHT vom Typ StorageContext????

    Es könnte ja sein das künftig noch weitere Contexte hinzukommen, smit kann man jedesm Context da rein schmeißen und in den dann richtigen typ casten... oder so... kanns nicht genau erklären...

    Die generic Klasse sieht kompliziert aus... von der Logik her ist es mir klar, wofür sie da ist...
    "Hier könnte Ihre Werbung stehen..."

    MichaHo schrieb:

    Es könnte ja sein das künftig noch weitere Contexte hinzukommen, smit kann man jedesm Context da rein schmeißen und in den dann richtigen typ casten... oder so... kanns nicht genau erklären...

    Nicht ganz, ne. In diesem Fall könnte der Typ auch DBContext sein den davon erbt unser Context.
    Jemand noch eine Idee. Ein kleiner Tipp. Seht euch an was ich ErfinderDesRades geschrieben habe.

    VB.NET-Quellcode

    1. Imports HomeStorage.DbContext
    2. Public Class ArticleRepository
    3. Inherits GenericRepository(Of Model.StorageModel.Article)
    4. Public Sub New()
    5. MyBase.New
    6. End Sub
    7. Public Sub New(context As Object)
    8. MyBase.New(kontext:=CType(context, StorageContext))
    9. End Sub
    10. Friend Sub New(ctx As StorageContext)
    11. MyBase.New(kontext:=ctx)
    12. End Sub
    13. End Class

    Der Grund ist nämlich der selbe wie der warum hier der Konstruktor dem der Context als StorageContext und nicht als Object übergeben wird Friend sein MUSS. Vieleicht kommt man nun drauf.

    MichaHo schrieb:

    Die generic Klasse sieht kompliziert aus...

    Soltest du etwas nicht verstehen frag bitte nur.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Ich muss gestehen daß mir das ganze zu hoch ist. Hier werden Sachen genutzt wo ich mich noch zig Mal einlesen muss, weil ich es selbst noch nie genutzt habe.
    Über unterschied Inherits / Implements, das wurde irgendwo in einer Klasse genutzt.
    Dann Interfaces, noch nie benutzt. Msdn Mal nachgelesen, aber mir fehlt die praktische Erfahrung damit. Ich lerne es meist wenn ich sehe wie es funktioniert. Die Theorie alleine bringt mir nichts.
    Dann kommt EFCore hinzu, damit habe ich noch gar keine Berührungspunkte gehabt.
    Ich glaube mir fehlt zuviel wissen und Praxis um denn Sinn gewisser Sachen zu verstehen.
    Ich werde aber weiter den Thread verfolgen und mir die Sachen ansehen. Irgendwann verstehe auch ich es. Es dauert halt alles etwas.
    Trotzdem nochmal ein fettes Danke für deine Mühe @Nofear23m, kann man nicht oft genug sagen.
    Rechtschreibfehler betonen den künstlerischen Charakter des Autors.
    Hallo @Akanel

    Das kann ich verstehen. Wenn man mit Interfaces und BAsisklassen noch nicht viel zu tun hatte bringt das auch nichts. Hier Hilft nur: Buch in die Hand und von vorne bis ende lernen. Irgendwas "aufschnappen" bringt nix.

    Das ist auch das was ich meinte im ersten Kapitel meines MVVM Tutorials. Man muss die Grundlgen der OOP können. Ohne dem wird das nichts, schon gar nicht mit der WPF unter der Verwendung eines Pattern. Da muss sowas sitzen. Du kannst ja wenn du möchtest weiterhin "zusehen" und versuchen daraus zu lernen.

    Aber wenn du etwas nicht verstehst oder du dich mit Interfaces nicht auskennst kannst du gerne auch hier im Thread oder in einem eigenen Thread danach Fragen.
    Mach einfach einen Thread auf und wir können versuchen Anhand von Beispielen dir Interfaces zu erklären oder dir gute Links liefern. Wenn man lernen WILL dann kann man das auch relativ leicht. Ein paar Links in die Favoriten und dann vorm schlafen gehen Tablet in die Hand.

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

    Nofear23m schrieb:

    Aber mit jeder Zeile Code welche in den einzelnen Schichten geschrieben wird kommen immer mehr die Vorteile der "Layertrennung" zu Tage. Immer und immer mehr Ordnung!! Mit jeder Zeile Code. Am Anfang vieleicht schwer zu glauben, es ist aber dennoch so. Vieleicht kann evtl. @Thomi was hierzu sagen!


    Hallo Leute,
    da mich der Nofear23m hier so direkt anspricht, möchte ich mich auch mal kurz dazu äußern:Also ich kam vor ca. einem Jahr aus der Spagetti-Code-Fraktion. Dann habe ich mich dank Nofear23m an WPF und MVVM gewagt. Zum Anfang war es eine echte Katastrophe. Laufend kam ein neuer Layer dazu und in jedem Layer ein paar Codeschnipsel. Da war ich oft verzweifelt, aber mit der Zeit hat sich die Arbeit „bezahlt gemacht“. So undurchsichtig es auch manchmal zum Anfang scheint (ich habe mich oft nach meinem alten Code gesehnt), dieser Aufbau hat durchaus Sinn. Wenn es dann einmal „Klick“ macht und sich der Nebel lüftet, macht es richtig Spaß zu programmieren. Nur nicht den Mut verlieren.

    Und wenn es mal nicht weiter geht, es gibt da einen kompetenten Berater im Forum. Ich denke Nofear23m hat ein großes Lob für seinen Einsatz verdient.

    GrüßeThomas
    Warum implementierst du für jede Entität ein eigenes Repository auch wenn die einzelnen Implementierungen keinen Mehrwert zur Base bringen? Du könntest ein generisches Repository machen und dieses über DI laden:

    Unity.RegisterType(typeof(IRepository<>), typeof(Repository<>))
    Der Container löst dann automatisch auf wenn du IRepository<Article> haben willst.
    Hallo @ThuCommix

    Der Einwand ist berechtigt und dein Ansatz gut. (Muss ich mal probieren)
    Im Moment sind unsere Repositoryklassen auch noch leer, ich möchte aber die möglichkeit haben für "Spezielle" Abfragen eine eigene Methode im jeweiligen Repository zu erstellen.
    Die Basisklasse gibt uns einiges an möglichkeit, aber leider nicht alles. Es gibt viele Dinge welche man nicht so einfach generisch machen kann. Ich habe zumindest noch keinen Weg gefunden.
    Ein Beispiel hierfür ist EF.function.Like oder andere spezielle Abfragen welche ich einfach dann gerne im Repository hätte. Klar im Moment haben die Klassen keinen Mehrwert und sind nur "vorangelegt".

    Oder kennst du hierfür einen Weg? Wäre cool. Vieleicht versteife ich mich jetzt zu sehr am RepositoryPattern welches nun mal so implementiert wird.

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

    C#-Quellcode

    1. public class Repository<T> : IRepository<T> where T : Model
    2. {
    3. private readonly XelmoDbContext _xelmoDbContext;
    4. /// <summary>
    5. /// Initializes a new Repository class.
    6. /// </summary>
    7. /// <param name="xelmoDbContext">The xelmo db context.</param>
    8. public Repository(XelmoDbContext xelmoDbContext)
    9. {
    10. _xelmoDbContext = xelmoDbContext;
    11. }
    12. /// <summary>
    13. /// Gets the model by id async.
    14. /// </summary>
    15. /// <param name="id">The id.</param>
    16. /// <returns>Returns the model or null.</returns>
    17. public Task<T> GetAsync(int id)
    18. {
    19. return _xelmoDbContext.Set<T>().FindAsync(id);
    20. }
    21. /// <summary>
    22. /// Inserts a model async.
    23. /// </summary>
    24. /// <param name="model">The model.</param>
    25. /// <returns>Returns true on success.</returns>
    26. public async Task<bool> InsertAsync(T model)
    27. {
    28. await _xelmoDbContext.Set<T>().AddAsync(model);
    29. return await _xelmoDbContext.SaveChangesAsync() > 0;
    30. }
    31. /// <summary>
    32. /// Updates a model async.
    33. /// </summary>
    34. /// <param name="model">The model.</param>
    35. /// <returns>Returns true on success.</returns>
    36. public async Task<bool> UpdateAsync(T model)
    37. {
    38. _xelmoDbContext.Set<T>().Update(model);
    39. return await _xelmoDbContext.SaveChangesAsync() > 0;
    40. }
    41. /// <summary>
    42. /// Deletes a model async.
    43. /// </summary>
    44. /// <param name="model">The model.</param>
    45. /// <returns>Returns true on success.</returns>
    46. public async Task<bool> DeleteAsync(T model)
    47. {
    48. _xelmoDbContext.Set<T>().Remove(model);
    49. return await _xelmoDbContext.SaveChangesAsync() > 0;
    50. }
    51. /// <summary>
    52. /// Creates the query.
    53. /// </summary>
    54. /// <returns>Returns a queryable.</returns>
    55. public IQueryable<T> AsQuery()
    56. {
    57. return _xelmoDbContext.Set<T>();
    58. }


    C#-Quellcode

    1. public static class QueryableExtensions
    2. {
    3. public static Task<T> FirstOrDefaultAsync<T>(this IQueryable<T> queryable, Expression<Func<T, bool>> predicate)
    4. {
    5. return EntityFrameworkQueryableExtensions.FirstOrDefaultAsync(queryable, predicate);
    6. }
    7. public static Task<T> FirstOrDefaultAsync<T>(this IQueryable<T> queryable)
    8. {
    9. return EntityFrameworkQueryableExtensions.FirstOrDefaultAsync(queryable);
    10. }
    11. public static Task<bool> AnyAsync<T>(this IQueryable<T> queryable, Expression<Func<T, bool>> predicate)
    12. {
    13. return EntityFrameworkQueryableExtensions.AnyAsync(queryable, predicate);
    14. }
    15. public static Task<bool> AnyAsync<T>(this IQueryable<T> queryable)
    16. {
    17. return EntityFrameworkQueryableExtensions.AnyAsync(queryable);
    18. }
    19. }


    Somit bleiben alle Ef Verweise im DAL Layer und falls du das Framework ändern willst musst du nur die Extension und die Repository Klasse anpassen. Durch das exposen das IQueryable im Repository hast du alle Möglichkeiten :)
    Sorry @ThuCommix und Sorry an alle anderen.
    Ich hatt die Tage/Wochen jetzt viele private probleme und konnte einfach nicht Online gehen (Trennung, Umzug usw.)

    @ThuCommix, ich werde mir das mal Übersetzen und ansehen, sieht aber soweit gut aus. Mal sehen. Ich werde auf jeden Fall Berichten!!
    Danke dir erstmal.

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

    Nofear23m schrieb:

    Sorry @ThuCommix und Sorry an alle anderen.
    Ich hatt die Tage/Wochen jetzt viele private probleme und konnte einfach nicht Online gehen (Trennung, Umzug usw.)

    @ThuCommix, ich werde mir das mal Übersetzen und ansehen, sieht aber soweit gut aus. Mal sehen. Ich werde auf jeden Fall Berichten!!
    Danke dir erstmal.

    Grüße
    Sascha


    Von mir auch alles Gute. Das wird wieder.