Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

Post a reply

Confirmation code
Enter the code exactly as it appears. All letters are case insensitive.
Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :| :mrgreen: :geek: :ugeek: :arrow: :angel: :clap: :crazy: :eh: :lolno: :problem: :shh: :shifty: :sick: :silent: :think: :thumbup: :thumbdown: :salute: :wave: :wtf: :yawn: :facepalm: :bravo: :dance: :beard: :morebeard: :xmas: :HeHe: :trollface: :cookie: :rainbow: :monkeysee: :monkeysay: :happybday: :headwall: :offtopic: :superhappy: :terms: :beer:
View more smilies

BBCode is ON
[img] is OFF
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by just me » 27 Sep 2021, 01:40

densch wrote:Das nach Jahren ahk dahingehend nicht besser geworden ist, sagt Manches.
Du solltest mal schauen, ob Du irgendwo Informationen über AHK v2 findest. Für private Skripte kannst Du jederzeit umsteigen. Viel Spaß!

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by densch » 26 Sep 2021, 16:26

"Unflat"
Diese Wort habe ich auch noch nie gehört.

Die englischsprachigen Nutzer, ja...

Meine Attitüde nennt sich Vernunft.
Mag ja Masochisten geben die das Chaos um expesion vs legacy so richtig geil finden.
Zu denen gehöre ich allerdings nicht und kann es daher leider auch nicht kommentarlos stehen lassen, wenn es schön geredet wird.

Das nach Jahren ahk dahingehend nicht besser geworden ist, sagt Manches.

Wozu dieser Mist rund um expression vs legacy erfunden wurde weiß keiner.
Wie ich auch shcon x mal schrieb, hätten die Erfinder es wie anderswo auch machen sollen und eine fixe Syntax festlegen sollen.
Weil nicht jeder will für jeden befehl 5 verschiedene Schreibweisen auswendig lernen, von denen man jede aber nur in bestimmten Situationen anwenden kann oder es in den anderen Modus" umzwingen muss.

Ja, mein eigenltiches Thema habe ich von just me erwähnt gelöst.

ungeachtet was von der 6stelligne hexadezimalzahl nun die 2 rot, grün oder blau stellen sind, so wir die Farbe "hellrot", die immer im selben Farbton auftaucht, bspw. ja immer mehr oder wneiger den selben Hexadezimalcode haben.

Was auch zumnindest bei meiner Anwendung so ist,

Im Worstcase schwankt mal ein Farbanteil zwischen A5 und A6 hin und her.

Aber da die 3 von mir betrahcteten Farben eh fast grundvershcieden sind, reicht es mir dass die erste Stelle immer ein A sein wird.

Insofern beläuft sich meine lösung auf ein simples Vorgehen:
1 Farbe unter Pixel bestimmen, ergibt eine 6stellige Hexzahl wie A4 B6 12
2. betrachte die 1. 3. und 5. Stelle (damit also die erste zahl eines jeden Anteil Tupels)
und gleiche es mit einer vorgegebenen Tabelle mit if anfragen ab.


Also wenn ich weiß dass hellrot D_4_F_ ist, dann muss ich nur prüfen ob 1.Stelle=D, 3. Stelle=4 und 5. Stelle=F ist.

So alle 3 Farben abgeglichen, passt so.

Und ansosnten lasse ich auf dem Pixel 50 mal, mit einem abstand von 100 Milisekunden, die Farbe prüfen und merke mir wie oft hellrot bspw. vorkam.
Wurde mehr als 13 mal hellrot festgestellt, kann man ziemlich totsicher sein dass die eine Weile angezeigte Farbe auch hellrot war
(natürlich ausgenutzt dass nur eine der 3 Farben auf einmal vorkommen kann)


Insofenr, Farberkennung läuft.
Nur ist das Skript an sich, vermutlich durch die dutzenden Messageboxen zwischendrin, noche twas langsam.
Insofern muss ich da mal noch ausmisten und auch so manche unnötige Warteperiode verkürzen oder rauslöschen :-)

@just me:
Leider kenne ich keine gute Programmiersprache für Klickaktionen und so, wo man so frei programmieren kann wie hier (fertige Programme sind nur nahc dem Schema "Klicke x mal auf Pixel Y", da kann man nix komplexes mit machen).
Sosnt wär ich gewiss shcon gewechselt :-)

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by just me » 30 Aug 2021, 06:01

Moin,

die Syntax einer Skriptsprache mag dem Einen gefallen, dem Anderen nicht. Über die 'Confusion', die durch die beiden Syntaxzweige 'traditional' und 'expression' entsteht, haben sich schon immer Leute beklagt. Man kann sich aber auch immer dafür entscheiden, fast ausschließlich die 'expression' Syntax einzusetzen, notfalls mit 'erzwungenen' Ausdrücken. Auch dann muss man aber immer mal wieder die Dokumentation lesen. Wer das nicht will, sollte sich eine andere Sprache suchen.

Zum Thema PixelGetColor:
Das Format des zurückgegebenen Wertes ist in der Doku beschrieben. Es handelt sich um einen hexadezimalen Wert, der die drei Farbkomponenten, aus denen sich die Farbe zusammensetzt, wie folgt darstellt:
0xBBGGRR - BB = Blaunanteil, GG = Grünanteil, RR = Rotanteil
Wenn man die Option RGB nutzt, wechseln Blau- und Rotanteil die Seiten
0xRRGGBB

Wenn ein Pixel genau 3 Farbwerte annehmen kann, solltest Du die mit einem Hilfsskript ermitteln (Farbe unter dem Mauscursor). Wenn Du dann im Skript dasselbe Farbformat benutzt, reduziert sich der Vergleich auf diese 3 Farbwerte.

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by gregster » 30 Aug 2021, 04:36

@densch:
Dein ständiges Rumgenöle - über Monate oder sogar Jahre hinweg - macht eben nicht gerade sexy; und obgleich ich dir in der Vergangenheit mehrmals auf deine Anfragen geantwortet habe, verliere ich dazu inzwischen die Lust. Aber das ist eher nachrangig.

Allerdings: Englischprachige Nutzer haben sich kürzlich massiv über dich beschwert, worauf ich dich ja via PM ernsthaft zur Mäßigung deiner Sprache aufgerufen habe. Die fanden deine ganzen Exkurse zu AHK auch eher abtörnend. Wenn du diese Attitüde nun auch auf den deutschsprachigen Bereich ausdehnen willst, dann ist es wahrscheinlich besser, wenn du dich in Zukunft auf deine unzähligen bevorzugten Programmiersprachen konzentrierst.

Oder wir entfernen das ganze Offtopic-Geschwurbel demnächst kommentarlos. Insbesondere, aber nicht nur, wenn es wieder sprachlichen Unflat enthält. Es ist ja auch immer wieder das Gleiche. Oder aber du konzentrierst dich ab jetzt auf das Wesentliche...

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by densch » 30 Aug 2021, 04:14

Meine "extremen" Äusserungen von mir basieren nur darauf dass dieser legacy vs expression Mode Mist mit abstand das unnötigste ist, was eine Programmiersprache haben kann.
Von sich im laufe der Versionen ändernder Syntax ganz zu schweigen.

So langsam habe ich mal eine AHnung wie manches in AHk v1 funtkioniert. Da will ich eigentlich nicht noch eine neue Sorache lernen.
Schlimm genug dass man mit dem expression vs legacy Mist so schon 2 befehlssätze lernen muss und durch himmlische Eingebung (oder Wiki) wissen muss welcher befehl oder Funktion welchen modus erwartet.

Und ja, jede andere Sprache wie java, python, C, etc. ist da einfach besser, die haben den Müll nicht.
Da hat eine zuweisung bspw. die Form int a=5; und fertig.
Da gibts nicht den Mist wo ein Programm völlig was anderes tut weil irgendwo ein anderer Modus erwartet wird von einer Funktion.

Im Prinzip frage ich mich nur, wie betrunken der Erfinder der Sprache gewesen sein muss als er die 20 verschiedenen Schreibvarianten für gut befunden hat. Scheinbar nicht viel.

Kannst du auch wieder einordnen.

Geht übrigens nicht um unter meienr Würde, sosnt würde ich ja nciht shcon ewig an einem AHK Script werkeln.
Was nicht heißt dass ich den legacy vs expression Mode Kram einfach nur sche*ße finde! Braucht kein Mensch.

Aber egal.


Zum Code:

Code: Select all

GetResultColor(){

	;MsgBox,,,% "GetResultColor()",2
	cr:=0
	cs:=0
	cz:=0
	Sleep 600
	Loop,40{
		Sleep, 80
		;do Color Search on ( 823,340)
		colour:=PixelColorSimple(chromeid, 1000,340)
		;do SingleTestColor(colour)
		L:=SingleTestColor(colour)
		;depending on result increase cr cs or cz by 1
		Switch L
		{
		Case "R":
			cr:=cr+1
		Case "S":
			cs:=cs+1
		Case "Z":
			cz:=cz+1
		}
		
	}
	result:="R"
	;depending on which one is the biggest return R S or Z
	/*
	if(cr>cs)&&(cr>cz){
		result:="R"
	}
	if(cs>cr)&&(cs>cz){
		result:="S"
	}
	if(cz>cs)&&(cz>cr){
		result:="Z"
	}
	*/
	if(cr>8){
		result:="R"
	}
	if(cs>8){
		result:="S"
	}
	if(cz>8){
		result:="Z"
	}
	MsgBox,,,% "cr=" . cr . "cs=" . cs . "cz=" . cs . "Color Result is " . result,5
	
	return result	
	/*
	#Persistent
	CoordMode Pixel, Screen 
	CoordMode Mouse, Screen 
	SetTimer, WatchCursor, 100
	return

	;changed to watching the testpixel nonstop
	WatchCursor:
	;MouseGetPos X, Y 
	;PixelGetColor Color, %X%, %Y%, RGB
	a:=PixelColorSimple(chromeid, 823,340)
	ToolTip, %a% %X% %Y%
	*/

}


; Coordinates are related to the window's client area (false, is using screen coordinates from (0,0) to (1919,1079))
PixelColorSimple(pc_wID, pc_x, pc_y) {
    if (pc_wID) {
        pc_hDC := DllCall("GetDC", "UInt", pc_wID)
        pc_fmtI := A_FormatInteger
        SetFormat, IntegerFast, Hex
        pc_c := DllCall("GetPixel", "UInt", pc_hDC, "Int", pc_x, "Int", pc_y, "UInt")
        pc_c := pc_c >> 16 & 0xff | pc_c & 0xff00 | (pc_c & 0xff) << 16
        pc_c .= ""
        SetFormat, IntegerFast, %pc_fmtI%
        DllCall("ReleaseDC", "UInt", pc_wID, "UInt", pc_hDC)
				
				pc_c := "0x" SubStr("000000" SubStr(pc_c, 3), -5)
				
        return pc_c
    }
}

;depending on the color search result, find the kind of number that was just played
SingleTestColor(colour){
  R:=SubStr(colour, 3, 1)
	G:=SubStr(colour, 5, 1)
	B:=SubStr(colour, 7, 1)
	
	;R=Red,S=Schwarz,N=normal,Z=Null
	
	if(R=8){
	  return "R"
	}
	else if(R=1){
	  return "S"
	}
	else if(R=0){
	  return "N"
	}
	else{
	  return "Z"
	}
}

Was passiert:
Zu einem bestimmten Zeitpunkt während der Laufzeit des Skriptes wird die Funktion GetResultColor aufgerufen.
Letztlich habe ich eine Internetseite mit einem Pixel, das ich beiobachte und das in dem zeitraum die Farbe wechselt.

Welche Farbe es in der Zeit annimmt, will ich letztlich rausfinden.
Dazu bestimme ich in der zeit so alle paar Milisekunden die Farbe des Pixels, machd as so 30 mal hintereinander.
Und wenn bspw. mindestens 15 mal rot gemessen wurde, kann man eben davon ausgehen dass es in der Zeit rot war.

Grundsätzlich hat das pixel immer eine , sich nur leicht, verändernde Standardfarbe.

In der Zeit hingegen kann es für 1-2 Sekunden jedoche entweder rot, schwarz oder grün werden.
Welche der 3 Farben es in der Zeit angenommen hat, ist rauszufinden.

Dazu nehme ich wie gesagt alle paar Millisekunden ne Farbstichprobe und das wa mit Abstand am Öftesten gemsessen wurde, das war dann wohl die erschienene Farbe :-)

Zur Farberkennung konkret:
Die Funktion PixelColorSImple habe ich hier irgendwo aus dem Forum, ich habe nicht mal ansatzweise eine Ahnung was es genau tut.
Aber es scheint zu funktionieren.

Ich gehe alsoi bei jeder meiner 30 Sticjhproben hin, bestimme erst die Hex Darstellung der Pixelfarbe und werfe das dann in die SingleTestColor funktion, die mir letztlich die hexdarstellung in eine Farbe rot, schwarz und so übersetzt (zero steht für null, weil die, wenn sie auftaucht, eben die farbe grün hat).
jedenfalls bildet die funktion die hexdarstellung auf eine der 3 zu erwartenenden farben ab.

Woher ich weiß welche farbe welchen hexcode hat?
Genau gar nicht, aber ich hatte vorab, indem dauernd die farbe unter dem mauszeiger zurückgegeben wird, eben beobachtet dass bspw. wennn das pixel rot ist, die hexdarstellung die form 0x08.... hat. also die erste komponente immer 8 ist.
rest hintne kann sein was es will, schwankt auch mal um +1 oder -1, aber die eine komponente ist so gut wie immer 8 wenn die pixelfarberot ist.
Ähnliche beobahctungen habe ich auch für die anderen Farben gemacht.

So auf die art soll das funktionieren.

Nur bestimmt er mir manchmal schwarz wenn da eigentlich rot ist und ähnliches, weiß noch nicht warum dies so ist.
vermutlich müsste ich da einfach mal meine farbwerte prüfen, vll. gucke ich auch auf die falsche komponente oder so.

habe mir da noch keine tief durchdachten plan für die farberkennung überlegt, bisher funktionierte das skript wegn dem thema mit dem globalen und so nicht.

Übrigens, die erforderliche chrome id oben ist nun, wie vieles Andere auch, nun superglobal, also auf jeden Fall von überall aus lesbar und änderbar :-)

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by gregster » 29 Aug 2021, 17:01

densch wrote:
29 Aug 2021, 16:04
Scheint mal derzeit zu laufen, nur die Farbfunktion liest mir aus der Hexadezimaldarstellung der Pixelfarbe 0x123456 und so noch nicht korrekt die betreffende Farbe ab, irgendwas passt da noch nicht ganz.
Ein Kommando wie PixelGetColor (und das ist nicht das einzige) verwendet ja standardmäßig Farben im BGR-Format - für RGB müsstest du die entsprechende Option in den Parametern hinzufügen. Aber ohne Code zu sehen, bleibt das nur ein best guess.

Davon abgesehen hat sich natürlich vieles in AHK dadurch ergeben, dass es über die Jahre (seit 2003) massiv erweitert wurde, bei gleichzeitigem Bekenntnis zu möglichst großer Rückwärtskompatibilität. AHK wurde ja überhaupt von AutoIt geforkt, weil Chris nicht mit AutoIt zufrieden war - dennoch basierte natürlich zunächst vieles auf der damaligen AutoIt-Codebasis und -syntax. An zahlreichen Erweiterungen wie sie Lexikos dann in AHK 1.1 einbrachte, hatte Chris jedoch überhaupt kein besonderes Interesse mehr (afaik). Er war im Grunde mit AHK 1.0 zufrieden und hat wahrscheinlich nie daran gedacht, AHK zu etwas wie dem heutigen v1.1 oder v2 weiterzuentwickeln.
Aber du kannst sicher sein, dass AHK v1.1 sich in Sachen Rückwärtskompatibilität nicht mehr ändern wird - die wird bleiben! Alles Lamentieren wird daran nichts ändern. Mit v2, auf das du schon wiederholt hingewiesen wurdest, erfolgt jedoch ein größerer Bruch mit der v1-Syntax.

densch wrote:
29 Aug 2021, 16:04
wozu dieser Msit überhaupt erfunden wurde.
Ich glaub wir haben nach zahlreichen ähnlicher und auch extremerer Äußerungen von dir inzwischen verstanden, dass die Verwendung von AutoHotkey unter deiner Würde ist, während du über Erfahrung mit unheimlich vielen tollen Sprachen verfügst... ist nochmals zur Kenntnis genommen, und wird entsprechend eingeordnet. Danke, reicht so.

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by BoBo » 29 Aug 2021, 16:48

Wenn dir etwas an Eindeutigkeit liegt könnte AHK 2.x für dich vorteilhafter sein. Hab’s mir selbst noch nicht angeschaut, der Befehlssatz soll aber Funktionsbasiert sein, womit legacy-Gedöns zur Erhaltung von Abwärtskompatibilität wegfallen dürfte. Go 4 it :thumbup:

https://ahkde.github.io/v2/docs/v2-changes.htm
Interessant dürfte perspektivisch auch Key#Sharp werden: viewtopic.php?f=80&t=77248

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by densch » 29 Aug 2021, 16:04

habe jetzt mal überall die Zahlen auch wieder als Zahlen, also ohne Anführungszeichen geschrieben.
Scheint mal derzeit zu laufen, nur die Farbfunktion liest mir aus der Hexadezimaldarstellung der Pixelfarbe 0x123456 und so noch nicht korrekt die betreffende Farbe ab, irgendwas passt da noch nicht ganz.

Ja, dieses Chaos mit legacy und expression Mode ist so ziemlich das Unnötigste, was man bei Erfindung von Autohotkey einbauen konnte, gerade wenn manche Funktionen und Befehle expressions wollen, andere wollen legacy Ausdrücke, bei Manchen kann oder muss man es auch küsntlich von einen in den anderen Modus wechseln und am Ende vom lied blict keiner durch was hinten und vorne ist und wozu dieser Msit überhaupt erfunden wurde.

und warum es nicht, wie in jeder Sprache dieser Welt, nicht einen einzigen klaren Regelsatz ohne Ambivalenzen und Co. gibt :-/

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by BoBo » 29 Aug 2021, 08:15

wenn ich dann später im Skript die Zahl a bspw. um 5 erhöhen will mit einem befehl wie a=a+7, würde er mir da dann trotzdem a=12 berechnen und zuweisen?
Versuch macht klug! Du musst dabei zwischen legacy- (a=a+7) und expression schreibweise (a:=a+7) unterscheiden.
legacy wird dir hier 'a+7' als string ausgeben.
expression, den wert von a + 7 als number (sofern a ebenfalls vom typ number war)

:arrow: Variables (en) Variablen (de)

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by just me » 29 Aug 2021, 04:27

Zeichenketten, die nur Zahlen enthalten, werden von AHK als Zahlen behandelt, wann immer es AHK für angebracht hält.
Ich verstehe aber nicht, warum AHK 'bei Vergleichen meckern' sollte, wenn Du statt A := "5" A := 5 verwendest.

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by densch » 29 Aug 2021, 03:50

Hallo, ja, das war vermutklich die lösung meines kleinen Problems.

Letztlich will ich wie du auch bspw. in der func() Methode a=a+1 machen, aber bisher hatte such das eingangs deklarierte a trotz Methodenaufruf nicht erhöht.
Nun scheint es zu gehen :-)

Eine Frage hätte ich noch:
Weil ahk ansosnten bei den Vergleichen immer meckerte, habe ich jegliche Zahl im Skript in Anführungszeichen gesetzt, also
a:="5" usw.

wenn ich dann später im Skript die Zahl a bspw. um 5 erhöhen will mit einem befehl wie a=a+7, würde er mir da dann trotzdem a=12 berechnen und zuweisen?

oder würde er da das stringmässig zu 57 konkatenieren?
Wobei + ja kein zeichen ist, was für konkatenation benutzt wird.

Kurzum, würde er es trotzdem als zahl erkennen wenn ich irgendwo + oder - rechne?

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by just me » 29 Aug 2021, 03:37

Moin,
densch wrote:Noormalerweise wird die Funktion aufgerufen, erhält eine fenster id, sowie x und y koordinate und sollte eine Farbe in der Form 0x123456 oder so zurückgeben.
Ich würde dann folgenden Funktionsaufruf vermuten:

Code: Select all

ID := 0
X := 100
Y := 200
...
...
Farbe := ErmittleFarbe(ID, X, Y)
...
...
ErmittleFarbe(ID, X, Y) {
	Return FarbWert
}
Wenn Werte der übergebenen Parameter innerhalb der Funktion verändert werden sollen, gibt es dafür ByRef-Parameter:

Code: Select all

ID := 0
X := 100
Y := 200
...
...
Farbe := ErmittleFarbe(ID, X, Y)
...
...
ErmittleFarbe(ByRef ID, X, Y) {
	ID := 42
	Return FarbWert
}
Wenn Du die Variable nicht als Funktionsparameter nutzen kannst oder willst, bleibt die Möglichkeit, sie entweder im globalen Bereich als super-global zu erklären

Code: Select all

Global ID := 0
X := 100
Y := 200
...
...
Farbe := ErmittleFarbe(X, Y)
...
...
ErmittleFarbe(X, Y) {
	ID := 42
	Return FarbWert
}
oder sie innerhalb der Funktion als global zu kennzeichnen

Code: Select all

ID := 0
X := 100
Y := 200
...
...
Farbe := ErmittleFarbe(X, Y)
...
...
ErmittleFarbe(X, Y) {
	Global ID
	ID := 42
	Return FarbWert
}

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by BoBo » 28 Aug 2021, 18:36

Bin nicht sicher ob dich das weiterbringt ... ?

Code: Select all

#SingleInstance, Force
global a:=0			; setzen der globalen variablen a mit dem wert 0
func()				; function call ohne übergabe eines wertes.
MsgBox % a			; anschließende anzeige des wertes der globalen variablen a (hier nun geändert auf 1)

func(){				; function
	MsgBox % a		; anzeige des wertes der globalen variablen a (hier noch 0)
	a+=1			; änderung des wertes der variablen a
	}
Übrigens müssen Zahlenwerte in der Expression-Schreibweise nicht in Anführungszeichen eingeschlossen werden (werden so in AHK nicht explizit als "String" deklariert). HTH

Re: Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by densch » 28 Aug 2021, 15:21

Von dem was ich gerade so ergoogelt habe, müsste ich da wohl das stichwort global benutzen.
Unklar ist mir da nur gerade ob ich global nur vor die anfängliche Deklaration der Variable ganz am Anfang des Skripts
oder global vor die stelle in der Methode wo die globale variable überschrieben werden soll
oder beides machen muss?

Sichtbarkeit von globalen variabeln und deren Änderbarkeit?

by densch » 28 Aug 2021, 15:16

Hallo, ich bin mittlerweile am verzweifeln.
ich habe ein, für meine verhältnisse, recht umfangreiches Skript zusammengebastelt.

Darin enthalten ist ein Colorcheck, den ich über eine Methode realisiere die ich mir aus einem Forum geklaut hatte.

Noormalerweise wird die Funktion aufgerufen, erhält eine fenster id, sowie x und y koordinate und sollte eine Farbe in der Form 0x123456 oder so zurückgeben.
Mit der ehraltenen Farbe wird dann weitergearbeitet.

Durch Nutzung von msgboxes überall weiß ich dass die Funktion offenbar nix zurückgibt da die Variable, in der ich das ergebnis des Funktionsaufrufs speichere, offenbar leer ist.

Nach langem Testen fiele mir nur eine Idee ein:
Dass die window id und die x und y werte erst gar nicht richtig übergeben werden.


Weil der Aufbau meines Skriptes ist so:
Ich habe ein paar "globale Variabeln", die einfach so im Skript stehen.

Also bspw.
windowid:="0"

Weiterim Skript wird dann eine Funktion aufgerufen, die womöglich selbst wieder eine andere Funktion ändert und in der Funktion wird dann was gerechnet und getan und dann mit dem Befehl windowid:=waserrechnetwurde
der globalen variable ein neuer Wert zugewiesen werden.

Ich würde nun vermuten dass diese, aus einer vershcachtelten Methode heraus, Übershcreiben einer globalen methoden weiß der geier warum gar nicht funktioniert bzw. schlicht nicht gemacht wird.

dementsprechend hat windowid durchgängig den eingangs zugewiesenen Wert 0, weshalb es natürlich später zu problemen kommt weil 0 keine zulässige window id ist (war nur so ein Beispiel gerade).

Falls das das Problem ist, würde das auch andere Probleme später erklären.


Die Frage wäre dann nur, ist das richtig so dass ich nicht inenrhalb von aufgerufenen Methoden globale Variabeln ändern kann?
(Kann man es mit etwas trickserei vielelicht doch)
Und wie könnte ich das ansosnten bewerkstelligen?

Weil eigentlich will ich, ie in anderen Sprachen auch, die variable mal eingangs mit initialisieren und mit einem Standardwert belegen,
Und später, egal in welcher Untermethode oder wo es mir passt, nahc Belieben ändern und überschreiben können.

Gibts da was was man tun kann? so wie man bspw. in java mit abstrakten Variabeln und Co. manches tricksen kann?

Innerhalb einer aufgerufenen methode, sind da diese globalen methoden überhaupt sichtbar?
Oder meint das Skript, wenn ich in der Methode einen befehl wie windowid:="7" ausführe, dass hier eine brandneue variable mit diesem wert erstellt wird (weil er eben die ausserhalb der methode befindliche BVariable nicht kennt, die er eigentlich übershcrieben soll?

Top