Hi Leude
Also ich min zur Zeit dabei ne GUI für mein Schachprogramm zu entwickeln mit Masm32 unter Windows XP. Ich bin der Meinung,
dass das Thema hier her gehört, da es sich um ein "MASM-Problem"
handelt, welches ich in meinen folgenden Erläuterungen zu beweisen
versuche, es sei denn es überzeugt mich jemand vom Gegenteil.
Jedenfalls ist mir gestern ein Riesenprblem mit LOKALEN VARIABLEN in oder unter meiner WndProc
aufgefallen:
Ich habe in eine lokale 32Bit-Variable einen Wert 00000000h gemovt,
in der Bearbeitungsschleife für die Windows-Nachricht WM_MOUSEMOVE.
In der Bearbeitungsschleife für die Windows-Nachricht WM_PAINT habe ich diese lokale Variable als ein Koordinaten-Parameter für ne BitBlt-API Fnktion verwendet.
Der ganze Code ließ sich dann auch ohne Rumgequese von MASM als
*.EXE compilieren, jedoch wurde das Bild was mit BitBlt erzeugt werden sollte garnicht erst angezeigt.
Also folgte meine Behandlung mit Nebenwirkungen:
Ich habe nichts weiter gemacht, als diese eine Variable aus der WindProc entfernt, das LOCAL davor natürlich auch und als globale Variable in .data? eingetragen.
Und siehe da,das Bild wurde ab Koordinate 00 angezeigt.
HEUREKA!! Oder nicht?: Jetzt frage ich mich natürlich woran das liegt? Jedenfalls bedeutet das, dass ich mit lokalen Variablen in einer Prozedur nichts anfangen kann, was eine gewisse Objektorientiertheit in MASM erheblich erschwert.
Achso. Übrigens kann man Sprunglabels in Prozeduren auch nicht LOCAL(isieren). Und anders herum kann man Variablen in Macros nicht als LOCAL deklarieren. In dieser Hinsicht ist MASM auch nicht unbedingt
intuitiv oder sogar logisch aufgebaut, oder?Das sei aber nur nebensächlich.
Gruß Dinkelchen
MASM hat Probleme mit LOCALen Variablen
Moderatoren: crack, Krüsty, Marwin
-
Dinkelchen
- Newbie
- Beiträge: 3
- Registriert: Samstag 3. März 2007, 01:00
- Wohnort: wird es in 60 Jahren nicht mehr geben
MASM hat Probleme mit LOCALen Variablen
Um so mehr Ich weiß, um so mehr Fragen
fange ich an zu stellen.
fange ich an zu stellen.
WndProc läugt nicht "ewig". Es wird letzendlich bei einem Ereignis von Windows aufgerufen. Die Prozedur kehrt nach der Abarbeitung wieder "ins System" zurück. D.h dass der Stackspeicher wieder freigegeben wird und dieser Speicher dann von Windowsroutinen überschrieben werden kann - somit ändert sich auch der Wert der Variablen. Das wäre auch in C nicht anders - lokale Variablen sind nur innerhalb der Prozedur gültig und behalten ihre Werte nicht darüber hinaus 
-
Dinkelchen
- Newbie
- Beiträge: 3
- Registriert: Samstag 3. März 2007, 01:00
- Wohnort: wird es in 60 Jahren nicht mehr geben
Ja, danke für die Antwort! Mittlerweile bin ich aber auch schon drauf gestoßen.
Wäre aber trotzdem nicht schlecht, wenn Masm sowas wie "Virtual"-LOCAL kapieren würde.
Ich meine damit,dass er theoretisch gesehen Variablen in Prozeduren
oder sogar Macros trotzdem als Globalen ansieht, sie aber von anderen
Macros und Proc's mit gleichen Namen differenziert. So kann eine bessere
Objektorientierung gewährleistet werden!
Warum kann man eigentlich keine Sprunglabes in Proc's als LOCAL deklarieren?
Wäre aber trotzdem nicht schlecht, wenn Masm sowas wie "Virtual"-LOCAL kapieren würde.
Ich meine damit,dass er theoretisch gesehen Variablen in Prozeduren
oder sogar Macros trotzdem als Globalen ansieht, sie aber von anderen
Macros und Proc's mit gleichen Namen differenziert. So kann eine bessere
Objektorientierung gewährleistet werden!
Warum kann man eigentlich keine Sprunglabes in Proc's als LOCAL deklarieren?
Um so mehr Ich weiß, um so mehr Fragen
fange ich an zu stellen.
fange ich an zu stellen.
Warum kann man eigentlich keine Sprunglabes in Proc's als LOCAL deklarieren?
Code: Alles auswählen
hallo: <- lokal
hallo:: <- global -
Nordwind64
- Newbie
- Beiträge: 5
- Registriert: Freitag 28. Oktober 2005, 17:28