Variablen je nach Programmstelle deaktivieren bzw. aktivieren

  • VB.NET

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von Mad Andy.

    Variablen je nach Programmstelle deaktivieren bzw. aktivieren

    Hallo, ich habe eben durchgezählt. In meinem Programm befinden sich mittlerweile rund 160 Variablen im Public Bereich.
    Diese gehören auch wirklich alle dort hin da sie Modulweit erreichbar sein müssen.
    Ich kann sie leider auch nicht nach der Benutzung deaktivieren da sie je nach Benutzer immer mal wieder gebraucht werden könnten. Da es noch sehr viel mehr Variablen werden, brauche ich eine Möglichkeit diese Programmabhängig zu deaktivieren bzw. wieder zu aktivieren. Die nehmen ja auch alle Speicher in Anspruch...

    Da ich die unterschiedlichen Programmstellen über eine Menüsteuerung aufrufe würde ich es zum Beispiel dann so machen das je nach Programmstelle die einzelnen notwendigen Variablen aktiviert bzw. deaktiviert werden.

    Hai !
    Eine Variable kannst du nicht Deaktivieren, übrigens soviel Speicher Platz nimmt die Variable auch nicht, wenn du soviel Variablen hast, ich würde mir überlegen über eine Klassen Bibliotek, hast auch besseren übersicht.

    Wenn eine Variable Deklarirt dann ist die schon in Verwendung egal welche und wocher die Werte werden zugewiesen.

    Mfg Alex

    Du hast noch nie was von OOP gehört, ne? :D
    Module sind generell zu vermeiden, stattdessen solltest du dem Hauptformular public Variablen zuweisen. Naja.. angenommen du bleibst dabei.

    VB.NET-Quellcode

    1. Public Class myClass
    2. 'hier irgendwelche Variablen rein, die auf die Klasse bezongen ist
    3. Public myVar as String
    4. Public myVar2 as myType
    5. ...
    6. End Class

    VB.NET-Quellcode

    1. Public Module myModule
    2. ' hier alle public Instances rein
    3. Public myInstance as myClass ' ist am Anfang nur ein paar Bytes groß, da es ein NULL-Pointer / Nothing ist.
    4. Public myInstance2 as someOtherClass
    5. End Module

    VB.NET-Quellcode

    1. Public Class Form1
    2. Private Sub mySub1
    3. 'ab hier wird myInstance benötigt
    4. myInstance = new myClass() ' ist jetzt etwa so größ wie 1xPointer, 1xString und 1xmyType
    5. ' irgendwelche Werte zuweisen. (siehe OOP)
    6. End Sub
    8. Private Sub mySub2
    9. 'ab hier wird myInstance2 benötigt
    10. myInstance2 = new someOtherClass() ' s.o.
    11. End Sub
    13. Private Sub mySub3
    14. 'ab hier wird myInstance nicht mehr benötigt
    15. myInstance = Nothing ' Alles außer dem Pointer wird freigegeben, sobald der Garbage Collector drüber läuft
    16. ' ACHTUNG!
    17. ' Der Speicher wird nur freigegeben, wenn es _keine_ Referenz mehr auf diese Instanz von myClass mehr gibt!
    18. End Sub
    20. 'gleiches für myInstance2
    21. End Class


    Module sind, wie gesagt, sehr unsauber.. besonders weil sie einen dazu verleiten unsaubere Methoden (lauter nicht-Member Public Variablen) anzuwenden

    @Alex2000
    Du hast Recht im Vergleich zum Speicherplatz für die Grafik fallen die Variablen kaum ins Gewicht.
    Ich habe das mal nachgerechnet.
    100 * Integer = 100 * 4Bytes = 400Bytes
    Zweifarbiges Pixelfeld. 100 x 100 Pixel = 10000 Pixel
    1 Pixel = 1 Bit (zweifarbig)
    10000Bit = 1250Byte
    Die Menge der Variablen hat mich getäuscht...

    Habe da auch noch einen Link (die Seite hat einen Rechner zum umwandeln)
    kegeln-erzgebirge.de/bits-bytes.html

    @Mad Andy
    Ich habe mir den Quellcode erstmal als Beispiel in mein Codebook kopiert.
    Du hast es aber ja selber geschrieben, Module sind sehr unsauber. Mir scheint irgendwie auch als ob man viel damit falsch machen kann. Ich sehe mich schon irgendwelchen Bugs nachjagen weil ich ein paar mikrige Bytes wegsparen wollte. Ich lass das für erste...
    Ansonsten werde ich mich mal irgendwann mit den Klassen auseinandersetzen.

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

Facebook
Telefonspende