Wie könnte man sowas am besten angehen?

  • VB.NET

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Wie könnte man sowas am besten angehen?

    Hallihallo,

    hier mal was für die Denker unter euch^^

    Ich sitze gerade an einem etwas größeren Projekt, zumindest soll es das werden. Was genau es ist, will ich noch nicht verraten^^ Es geht darum, dass der Benutzer bestimmte Dinge dynamisch auf einer Art Karte platzieren kann. Ich denke an dieser Stelle eignet sich GDI am besten. Aber das ist erstmal nicht das Problem. Eher, wie man sowas speichern könnte. Denn es soll nachher noch da sein, aber auch nicht mit dem Hintergrund "verschmolzen sein". Der Benutzer soll es wieder entfernen können.

    Die ganze Geschichte soll also dynamisch bleiben. Nun die Frage: Wie realisiert man sowas am besten/Wie könnte man sowas speichern bzw. wieder laden?

    mfg,
    Lukas
    „Was daraus gefolgert werden kann ist, dass jeder intelligentere User sein Geld lieber für Bier ausgibt, um einen schönen Rausch zu haben, und nicht dieses Ranzprodukt.“

    -Auszug aus einer Unterhaltung über das iPhone und dessen Vermarktung.
    Ähm.....so kann man es sich in etwa vorstellen, ja^^
    „Was daraus gefolgert werden kann ist, dass jeder intelligentere User sein Geld lieber für Bier ausgibt, um einen schönen Rausch zu haben, und nicht dieses Ranzprodukt.“

    -Auszug aus einer Unterhaltung über das iPhone und dessen Vermarktung.
    Da würde ich doch XML gut eignen. Da muss man aber die Speichern- und Laden-Routine komplett selbst schreiben, aber man kann sie sehr effizient gestalten und hat volle Kontrolle. Das könnte dann so aussehen:

    XML-Quellcode

    1. <map>
    2. <object id="bla">
    3. <state>Repairing</state>
    4. </object>
    5. </map>

    Wenn man eine Klassenstruktur mit den Daten hat, dann kann man auch die Serialisierung nutzen. Standardmäßig ist das aber nicht abwärtskompatibel, was man beim manuellen Erstellen evtl. einfacher machen könnte.

    Viele Grüße, Phil.
    nimm am besten ne xml wo du die "gebäude" abspeicherst und anschließend auch wieder lädst. In die xml muss natürlich position, vll größe kp was du eben alles so brauchst. :)


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.
    Schonmal Danke für den Tipp mit XML. Werd mir mal ein paar Beispiele anschauen/schreiben, um zu sehen, wie kompliziert oder einfach(^^) das ist.
    „Was daraus gefolgert werden kann ist, dass jeder intelligentere User sein Geld lieber für Bier ausgibt, um einen schönen Rausch zu haben, und nicht dieses Ranzprodukt.“

    -Auszug aus einer Unterhaltung über das iPhone und dessen Vermarktung.
    Also viel Lust habichjanet, bei so "Rat den Lukas!" mitzuspielen. Prinzipiell simmer wieder bei einer datenverarbeitung, und die DatenObjekte müssen sich auch zeichnen können.

    Gugge Control mit beweglicher Figur, Outlined und ziehbare Schrift, Gezieltes OwnerDrawing, ZeichenObjekte im Dataset - vlt. geht letzteres am meisten in deine Richtung - ist aber c#

    Xml ist verglichen mit einem typisierten Dataset eine ziemliche Krücke, und wenn sich m:n - Relationen eröffnen (kann man bei deiner Geheimniskrämerei ja nicht erahnen) ist Xml überfordert
    Danke für die Links.

    "Rat den Lukas"? :rolleyes:
    „Was daraus gefolgert werden kann ist, dass jeder intelligentere User sein Geld lieber für Bier ausgibt, um einen schönen Rausch zu haben, und nicht dieses Ranzprodukt.“

    -Auszug aus einer Unterhaltung über das iPhone und dessen Vermarktung.
    ich muss da auch noch meinen Senf dazu geben ...
    wieso die Arbeit mit GDI :D??
    geht doch mit PictureBoxen viel einfacher ;)
    Hintergrund transparent und dann einfach setzen, die Positionen zu speichern ist nicht schwer und die verschmelzen ganz bestimmt nicht mit dem Hintergrund ;)

    //edit .. also ihr müsst diesen post nicht unbedinkt in die diskusion mit einbeziehen, es war nur nen Tipp ;)
    Vielleicht legst Du eine List(Of MyObjects) an.
    Die Klasse MyObjects sollte laden und Speichern können sowie ihren eigenen Inhalt per Übergabe eines Graphics-Pbjekts darstellen können.
    Per MouseOver / MouseKlick das aktuelle Objekt erkennen und markieren, um es zu verschieben und zu editieren.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Solche selbstgebastelten DatenObjekte erfüllen nicht die Anforderungen relationaler Datenmodellierung.

    Beispiel:
    Gebäude X, Y, Z liegen in der Straße A, und gehören Besitzer C.

    Wie willst du nun die Klassen für Besitzer und Straße implementieren? Enthält Straße eine Auflistung von Gebäuden? Enthält Besitzer nicht ebenfalls eine Auflistung von Gebäuden?
    Dann hastedie Gebäude doppelt, und damit allein beim Abspeichern der Gesamtheit ein nettes kleines Problemchen, (was dich letztendlich zwingen wird, relationale Logik zumindest teilweise nachzuprogrammieren.)

    Aber vlt. benötigt der TE auch gar kein relationales Modell, nämlich etwa, wenn gar keine Besitzer vorgesehen sind. Blos wenn sich dann später herausstellt, dasser doch eines benötigt hätte, wirds wieder ungemütlich.
    Ähnlich wie ErfinderDesRades würde ich dir DRINGEND empfehlen Objektorientiert zu arbeiten, das heißt erstell dir für alles was du auf dem bildschirm platzieren wilslt ein Objekt.

    Desweiteren sollte alle diese Objekte eine Schnittstelle (Interface) implementieren, dass diese als Spielfeldobjekte markiert sodass du diese in einer Liste zusammen ablegen kannst. Dim liste As List Of(IGameObject) <- Beispiel

    Das hat einen Großen Vorteil, da du diese Liste oder das Wrapperobjekt dieser Liste einfach serialisieren könntest, damit hast du dir das XML Gedöns gespart und alles wird automatisch geregelt.

    Wenn du des Weiteren in der Schnittstelle eine Methode wie "ZeichneMich()" implmenetiertst, kannst du dann alle Objekte sehr bequem Zeichnen in dem du diese über eine Schleife durchläufst: For Each(o as IGameObject in liste) o.ZeichneMich() End For

    PS: Den Quatsch mit den Pictureboxen solltest du getrost ignorieren, machs lieber Richtig.
    Danke Basti. Ich werde mir alle Möglichkeiten mal ansehen.

    Warum nicht mit PictureBoxen? Zu unübersichtlich, extrem unsauberer Code, ich darf 20 Eigenschaften jeder dynamischen PB speichern bla bla bla.... Zudem dürfte es bei 90 Objekten sicherlich einfacher gehen, die ganze Geschichte zu zeichnen anstatt überall PictureBoxen hin zu pflanzen.

    Ganz einfach. Würde man alles mit PictureBoxen machen, hätte man GDI nicht erfunden...
    „Was daraus gefolgert werden kann ist, dass jeder intelligentere User sein Geld lieber für Bier ausgibt, um einen schönen Rausch zu haben, und nicht dieses Ranzprodukt.“

    -Auszug aus einer Unterhaltung über das iPhone und dessen Vermarktung.

    bigbasti schrieb:

    Das hat einen Großen Vorteil, da du diese Liste oder das Wrapperobjekt dieser Liste einfach serialisieren könntest, damit hast du dir das XML Gedöns gespart und alles wird automatisch geregelt.

    Für Serialisierung gilt dasselbe wie für Xml: sobald eine m:n - Relation zwischen den Objekten auftaucht (Straße - Gebäude - Besitzer) hat Serialisierung verloren, weil ein Gebäude, welches sowohl in eine Straße gehört, als auch einem Besitzer, bei Serialisierung verdoppelt wird.
    Immerhin hat Serialisierung den Vorteil, dass die Werte gleich korrekt typisiert rekonstruiert werden, bei Xml muß man ja erst noch XElement-Values parsen.

    Ich sach immer: typisiertes Dataset. Ist ebenso typisiert wie ein deserialisiertes Objekt, aber noch einfacher zu bedienen.