MaxGui - TextAreaText problem.

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

	PhillipK Betreff: MaxGui - TextAreaText problem.	Sa, Jan 28, 2012 20:31 Antworten mit Zitat
Heyho leute Ich habe grade ein ziemliches problem, was mich nun schon mehrere stunden gekostet hat. Folgendes Szenario: Ich möchte grade, überwiegend zu lernzwecken, eine art code-einfärbung anhand eines TextArea gadgets vornehmen. Sourcecode ist ein spiel welches ich in Lua geschrieben habe. (Für MOAI, also nichts blitzbezogenes) Die datei hat 977 zeilen insgesamt. Nach etlichen versuchen, mit eigenen methoden und RegEx-suchen den Code nach wörtern etc zu filtern, bin ich immer wieder auf "verschiebungen" gestoßen. Erst konnte ich mir das ganze nicht erklären und dachte, ich habe etwas falsch programmiert. Tja, workarround ward geschrieben, wörter werden nun korrekt eingelesen. Aber nun kommts: Im 2ten Schritt möchte ich nun Kommentare / Kommentarblöcke einfärben. Hier wurde das problem deutlich: Ich hole mir den text aus dem TextArea über verschiedenste methoden. Wenn ich nun eine Regexp drüberlaufen lasse, findet die RegExp-engine alles ganz richtig. Aber, die string-positionsrückgabe entspricht nicht direkt der, die die TextArea annimmt, um einzufärben. Hier die regexp: Code: [AUSKLAPPEN] [EINKLAPPEN] \s(--.[\s]) (beschreibung: Sucht nach einem whitespace char, also zb ein zeilenumbruch, leerzeichen oder TAB zeichen), danach fängt es eine gruppe (-> rückgabe), worin -- vorkommt, gefolgt von unbekannten-nicht-zeilenumbruch-zeichen in beliebiger anzahl (und bis unendlich), bis es wieder einen whitespace-char findet) Kurzum: --DAS ist ein Komisch er string undso zeilenumbruch* würde gefunden werden. Ergebnis: Das Printen zeigt auch, das diese zeilen passend gefunden werden. Aber: Beim einfärben zeigt sich eine unbestimmte verschiebung nach hinten. Ich kann nicht erklären, wie die verschiebung aussieht, nur das eine auftritt. Erst hatte ich angenommen, das pro zeile ein zeichen mehr existiert, als ich mir vom TextArea-gadget holen kann. Dies stimmt aber nicht. Ebenso hatte ich angenommen, das die Reg-exp engine etwas falsches zurückgibt (zb ein zeichen mehr bzw weniger pro fund, pro zeilen, what ever) Aber sämtliche offsets beim färben blieben ohne erfolg. Nun frage ich mich, wieso ist das so ist Bzw, was mache ich falsch? Die prints des Regex-zeugs sind eindeutig richtig. Nur die färbung, die beim Area-text ankommt, passen nicht. Kurzum: Wenn ich mir positionen etc mit dem Area-gadget hole, zb line-start etc, klappts. Aber wenn ich mit totalen positionen anhand des strings arbeite, schlägts fehl. Abschließend noch der kurze code: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] Function MarkComment:Int(area:TGadget) Local pattern:TRegEx = TRegEx.Create("\s(--.[\s])") Local text:String = area.GetText() Local match:TRegExMatch = pattern.Find(text) Local i:Int = 0 While match Print("text: " + match.SubExp(1)) FormatTextAreaText(area, 255, 0, 0, 0, match.SubStart(1), Len(match.SubExp(1))) match = pattern.Find() i:+1 Wend Return i End Function Solangsam bin ich echt überfragt Ich möchte ungern einen riesen-wrapper zum suchen der zeilen und positionen schreiben, einfacher wäre es, direkt zu verstehen wie das ding arbeitet und dementsprechend vorzubereiten :/ Edit:* Okay, ich muss mich nochmal korrigieren. Es scheint, als ob doch Brucey's RegEx-engine den fehler verursacht. Nun, ich habe grade testweise den string nach den gefundenen zeichenketten durchsucht und die positionen verglichen. Alle 3-4 funde ist die regex-sufu noch ein zeichen weiter "hinten" als string.find - nun weiß ich garnichtsmehr. Das heißt, ich habe hier fälschlicherweise 2 unterschiedliche fehler für einen gehalten. Falls nun jemand ein paar ideen hat, was ich mal testen könnte, wäre ich sehr offen. Ich für meinen teil werde das verhalten nun genauer untersuchen und gucken, ob zb eine anderes Pattern bei der problemlösung helfen könnte. schnief

PhillipK

Betreff: MaxGui - TextAreaText problem.

Sa, Jan 28, 2012 20:31
Antworten mit Zitat

Heyho leute Smile

Ich habe grade ein ziemliches problem, was mich nun schon mehrere stunden gekostet hat.

Folgendes Szenario:
Ich möchte grade, überwiegend zu lernzwecken, eine art code-einfärbung anhand eines TextArea gadgets vornehmen.
Sourcecode ist ein spiel welches ich in Lua geschrieben habe. (Für MOAI, also nichts blitzbezogenes)

Die datei hat 977 zeilen insgesamt.

Nach etlichen versuchen, mit eigenen methoden und RegEx-suchen den Code nach wörtern etc zu filtern, bin ich immer wieder auf "verschiebungen" gestoßen. Erst konnte ich mir das ganze nicht erklären und dachte, ich habe etwas falsch programmiert.
Tja, workarround ward geschrieben, wörter werden nun korrekt eingelesen.
Aber nun kommts:

Im 2ten Schritt möchte ich nun Kommentare / Kommentarblöcke einfärben. Hier wurde das problem deutlich:
Ich hole mir den text aus dem TextArea über verschiedenste methoden. Wenn ich nun eine Regexp drüberlaufen lasse, findet die RegExp-engine alles ganz richtig.
Aber, die string-positionsrückgabe entspricht nicht direkt der, die die TextArea annimmt, um einzufärben.

Hier die regexp:

Code: [AUSKLAPPEN]

\s(--.*[\s])

(beschreibung: Sucht nach einem whitespace char, also zb ein zeilenumbruch, leerzeichen oder TAB zeichen), danach fängt es eine gruppe (-> rückgabe), worin -- vorkommt, gefolgt von unbekannten-nicht-zeilenumbruch-zeichen in beliebiger anzahl (und bis unendlich), bis es wieder einen whitespace-char findet)
Kurzum:
--DAS ist ein Komisch er string undso *zeilenumbruch*
würde gefunden werden.

Ergebnis:
Das Printen zeigt auch, das diese zeilen passend gefunden werden.
Aber: Beim einfärben zeigt sich eine unbestimmte verschiebung nach hinten.

Ich kann nicht erklären, wie die verschiebung aussieht, nur das eine auftritt.

Erst hatte ich angenommen, das pro zeile ein zeichen mehr existiert, als ich mir vom TextArea-gadget holen kann. Dies stimmt aber nicht.
Ebenso hatte ich angenommen, das die Reg-exp engine etwas falsches zurückgibt (zb ein zeichen mehr bzw weniger pro fund, pro zeilen, what ever)
Aber sämtliche offsets beim färben blieben ohne erfolg.

Nun frage ich mich, wieso ist das so ist Very Happy

Bzw, was mache ich falsch? Die prints des Regex-zeugs sind eindeutig richtig. Nur die färbung, die beim Area-text ankommt, passen nicht.

Kurzum: Wenn ich mir positionen etc mit dem Area-gadget hole, zb line-start etc, klappts. Aber wenn ich mit totalen positionen anhand des strings arbeite, schlägts fehl.

Abschließend noch der kurze code:

BlitzMax: [AUSKLAPPEN]

Function MarkComment:Int(area:TGadget)
	Local pattern:TRegEx = TRegEx.Create("\s(--.*[\s])")
	
	Local text:String = area.GetText()
	
	Local match:TRegExMatch = pattern.Find(text)
	
	Local i:Int = 0
	While match
		Print("text: " + match.SubExp(1))
		FormatTextAreaText(area, 255, 0, 0, 0, match.SubStart(1), Len(match.SubExp(1)))
		
		match = pattern.Find()
		i:+1
	Wend
	Return i
End Function

Solangsam bin ich echt überfragt Smile

Ich möchte ungern einen riesen-wrapper zum suchen der zeilen und positionen schreiben, einfacher wäre es, direkt zu verstehen wie das ding arbeitet und dementsprechend vorzubereiten :/

Edit:
Okay, ich muss mich nochmal korrigieren. Es scheint, als ob doch Brucey's RegEx-engine den fehler verursacht.
Nun, ich habe grade testweise den string nach den gefundenen zeichenketten durchsucht und die positionen verglichen. Alle 3-4 funde ist die regex-sufu noch ein zeichen weiter "hinten" als string.find - nun weiß ich garnichtsmehr.

Das heißt, ich habe hier fälschlicherweise 2 unterschiedliche fehler für einen gehalten.
Falls nun jemand ein paar ideen hat, was ich mal testen könnte, wäre ich sehr offen. Ich für meinen teil werde das verhalten nun genauer untersuchen und gucken, ob zb eine anderes Pattern bei der problemlösung helfen könnte. Sad

*schnief*