Probleme mit num. Gets mit Picture-Klausel

[Markus Walter]

Hi,

kann mal jemand, der Express benutzt und ein deutsches Windows hat (wohl jeder von Euch) etwas ausprobieren:

Code: Alles auswählen

#include "dcdialog.ch"
#include "appevent.ch"

function Appsys()
return NIL

procedure main()
local nWert1 := 100, nWert2 := 100

  @ 10, 10 DCGET nWert1
  @ 11, 10 DCGET nWert2 picture "999999.99"

  DCREAD GUI FIT

RETURN

Was passiert, wenn Ihr im 2. Feld "Entfernen" drückt und dann Enter? Bei mir steht dann 10000 im Eingabefeld.

Offensichtlich gibt es nach wie vor Probleme mit express mit deutschem Windows in numerischen Feldern mit picture-Formatierung. Auch mit einem Paste aus der Zwischenablage bestehen ähnliche Probleme. Kann das mal jemand bestätigen. Ich habe schon vor Monaten ein Beispiel in Rogers Webboard gepostet (damals wegen dem paste), aber der Fehler ist nich beseitigt (wahrscheinlich kann er ihn mit englischem Windows / Xbase / Dezimaltrennung nicht nachvollziehen...)

[Martin Altmann]

Hallo Markus,

(wohl jeder von Euch)

ich gehöre nicht zu denen - tut mir leid.
Aber was passiert bei folgender picture: "@E 999999.99"

Viele Grüße,
Martin

[Wolfgang Ciriack]

Hallo Markus,
mit deinem Beispiel habe ich keine Probleme.
Bei "Entfernen" löscht er ein (Leer-)Zeichen, dann Enter, es steht immer noch 0,00 da.

Express++ Version 249

[Koverhage]

Markus,


warum nicht pict '@E 999999.99'

ich benutze das immer bei numerischen Eingaben die einen Wert mit Komma erlauben.

Bisher habe ich damit keine Probleme, außer die bekannten (Cut und Paste, sowie solche Werte wie Du sie jetzt bekommst, aber das Problem ist ja bekannt und kommt nur vor wenn der Cursor nicht am Anfang steht)

[Klaus Stebner]

Hallo Markus,

Bei einmal "Entfernen-Taste" wird ein (Leer-)Zeichen gelöscht,
die 100 wandert ein Stelle nach links.
Vor dem Dezimalkomma ist jetzt ein Leerzeichen,
dann Enter, es steht der Wert 10000,00 im Feld

Express++ Version 249

_________________
Gruss Klaus

[Markus Walter]

Hallo Martin, Wolfgang, Klaus & Klaus,

@Martin: es passiert das Gleiche

@Klaus Stebner: exakt das Gleiche Verhalten wie bei mir und definitiv falsch. Einverstanden?

@Wolfgang: Bist Du sicher? Vor allem wieso steht 0 da? Der Wert ist mit 100 vorbesetzt? Kannst Du das nochmal überprüfen, bitte?

@koverhage:

Bisher habe ich damit keine Probleme, außer die bekannten (Cut und Paste, sowie solche Werte wie Du sie jetzt bekommst, aber das Problem ist ja bekannt und kommt nur vor wenn der Cursor nicht am Anfang steht)

Hast Du das mit meinem Sample ausprobiert? Das passiert auch wenn der Cursor am Anfang steht. Ablauf: Programm starten, Enter, Entfernen, Enter, dann steht 10000 im Feld. Evtl. setzt Du in Deinen Programmen noch irgendwelche Voreinstellungen? Ich habe das bewusst weg gelassen.


Es gibt auch keinen Unterschied im Verhalten zwischen Xb331/express249 und Xb346/express251.

Vielleicht gibt es ja wirklich irgendeine globale Einstellung, die das bewirkt?! Ihr müsst doch auch numerische Eingabefelder mit picture haben?! Mit dem Verhalten kann man doch nicht leben... Bei einem Paste in ein solches Feld, passieren ähnliche Effekte...
???????

[AUGE_OHR]

hi,

Hast Du das mit meinem Sample ausprobiert? Das passiert auch wenn der Cursor am Anfang steht. Ablauf: Programm starten, Enter, Entfernen, Enter, dann steht 10000 im Feld. Evtl. setzt Du in Deinen Programmen noch irgendwelche Voreinstellungen? Ich habe das bewusst weg gelassen.

also ich kann es nachvollziehen ... aber das passiert auch mit XbpGET() !
in der _dcApplyKey() steht :

Code: Alles auswählen

 CASE (nInkey == K_DEL)
           oGet:Delete()

also das selbe wie in XbpGET(), ergo reagiert es auch so ... eigendlich müsste ein oGet:Delete()
doch das ganze GET Feld löschen ... aber nicht unter Windows ... weil ja nicht "markiert" !

Nun bin ich noch nicht so in Express++ drin, aber ich denke doch mal das Roger sicherlich ein
SetMark() implementiert haben müsste ... nur wie heisst die Option in Express++ ?

in SLEpic gibt es nun folgendes :

Code: Alles auswählen

           IF ::DataType != "N" .AND. nPos <= ::BufferLength + 1 .AND. nPos <= LEN( ::EditBuffer() )
               IF ::cMask[ nPos ] $ "AXN9#LY!, "
                  ::XbpSLE:SetData( STUFF( ::Editbuffer(), nPos, 1, IF( ::HoldFormat, " ", "" ) ) )                     // jwl 8/3
                  ::SetMarked( { IF( ::HoldFormat, nPos + 1, nPos ), IF( ::HoldFormat, nPos + 1, nPos ) } )
               ELSE
                  ::SetMarked( { nPos + 1, nPos + 1 } )
               ENDIF
            ELSE
               IF ::DataType == "N" .AND. AT( ::cDecimalPoint, ::EditBuffer() ) >= nPos
                  IF "," $ ::cMask .AND. AT( ::cDecimalPoint, ::EditBuffer() ) != nPos                                  // del did not move right jwl 4/1
                     ::XbpSLE:setData( " " + STUFF( ::Editbuffer(), nPos, 1, "" ) )
                     ::XbpSLE:setData( TRANSFORM( ::transformToOrgDataType(), ::cmask ) )
                  ELSE                                      // at decplace
                     ::XbpSLE:setData( " " + STUFF( ::Editbuffer(), nPos, 1, ::cDecimalPoint ) )                        // del did not move right jwl 4/1
                     ::XbpSLE:setData( TRANSFORM( ::transformToOrgDataType(), ::cmask ) )
                  ENDIF
                  ::SetMarked( { nPos + 1, nPos + 1 } )     // del did not move right jwl 4/1
               ELSE
                  ::XbpSLE:Keyboard( nKey )                 //Normal SLE behaviour
               ENDIF
            ENDIF
            IF ::isAtR .AND. nPos > 1 .AND. !::cMask[ -- nPos ] $ "AXN9#LY!, "
               ::XbpSLE:SetData( STUFF( ::Editbuffer(), nPos, 1, " " ) )
               ::SetMarked( { nPos + 1, nPos + 1 } )
            ENDIF
            IF ::DataType == "D" .AND. EMPTY( ::Editbuffer() )                                                          // Olaf Teickner 19.12.2002
               ::XbpSLE:setData( TRANSFORM( ::transformToOrgDataType(), ::cmask ) )                                     // Olaf Teickner 19.12.2002
               ::SetMarked( { 1, 1 } )                      // Olaf Teickner 19.12.2002
            ENDIF                                           // Olaf Teickner 19.12.2002

damit wird auch die Transform "Maske" verschoben.

Frage : Kann man eigentlich die Express++ LIB selbst debuggen ? wenn wie ?

[Wolfgang Ciriack]

Hallo Markus,
ich weiss nicht, was ich gestern getestet habe , heute kann ich deine Beobachtungen voll nachvollziehen
Wenn du nachdem 10000,00 drin stehst die erste Null nach der 1 löscht, dann steht danach 100000,00 drin.
Scheinbar Probleme mit der Trennung der Nachkommastellen.

[AUGE_OHR]

hi,

Scheinbar Probleme mit der Trennung der Nachkommastellen.

Nein, mit dem "markieren" ... aber das hat XbpGet() doch auch !?

Da Roger nun die selben "invisible GET" Routinen benutzt, welche von Alaska kommen, wäre es
also kein BUG sondern ein Futures was du dir "wünscht" ala SLEPic (siehe Code oben).

aber auch SLEPic hat seine Probleme ... auf einem chinesischen OS() kommt alles "ddooppppeelltt"

zurück zu Express++ : wie "markiert" man den unter Express++ den Feldinhalt eines "GET" ?
Da gibt es doch sicherlich eine "fertige" Option ...

[Markus Walter]

Hallo Jimmy,

bei XbpGet() ist es offenbar anders...

Das Beispielprogramm von Alaska (test.exe/prg in X:\ALASKA\XPPW32\source\samples\solution\xbpget) hat das Problem NICHT?! Dort wirkt ein "Entf" offenbar nur an einer Stelle, an der auch eine Ziffer steht. Dort werden zwar auch die hinteren Ziffern nach vorne gezogen (sieht komisch aus), aber der Wert scheint anschließend immer zu stimmen...

Der Code von Alaska sieht so aus (aus xbpget.prg):

Code: Alles auswählen

CASE nKey == xbeK_DEL
        IF Set(_SET_INSERT) .AND. aMarked[1] == aMarked[2]
           aMarked[2] := aMarked[1] + 1
           ::SetMarked(aMarked)
        ENDIF
        ::DeleteMarked()

Ich vermute, dass Roger da Anpassungen vorgenommen hat... Ich weiß aber nicht, wo ich in seinem Quell-Code suchen sollte. Wahrscheinlich geht das "Paste-Problem" auch in diese Richtung, evtl. hängt das Ganze auch mit Länderspezifika zusammen und Roger hat was gebaut, was zwar mit englischem Windows/Xbase funtioniert, aber nicht mit deutschem...

[AUGE_OHR]

hi,

Der Code von Alaska sieht so aus (aus xbpget.prg):

Code: Alles auswählen

CASE nKey == xbeK_DEL
        IF Set(_SET_INSERT) .AND. aMarked[1] == aMarked[2]
           aMarked[2] := aMarked[1] + 1
           ::SetMarked(aMarked)
        ENDIF
        ::DeleteMarked()

Ich vermute, dass Roger da Anpassungen vorgenommen hat...

Ah ja klar, ich hatte mich auf das "invisible GET" bezogen aber es gibt ja auch noch den Event
handler in XbpGet.

Ich weiß aber nicht, wo ich in seinem Quell-Code suchen sollte.

hm ... ich habe nach xbeK_DEL gesucht und 7 Möglichkeiten gefunden. Ich denke es ist :
C:\EXP19\Source\Dclipx\_dcxbpgt.prg
dort steht :

Code: Alles auswählen

   CASE (nKey == xbeK_DEL .OR. nKey == xbeK_CTRL_G)
...
          ::DeleteMarked()

METHOD DC_XbpGet:DeleteMarked()
LOCAL aMarked := ::QueryMarked()                   //, i     ist das ein typo ?
//
// remove this for test
//
*   IF ! ::EditBuffer() == ::Get:Buffer
*      ::SetEditBuffer( ::Get:Buffer )
*      DC_GetEditUpdated(.t.)
*   ENDIF

jetzt funktioniert es mit K_DEL ... nun müsste ich nur den Debugger zum arbeiten bekommen ...

Frage : WIE debugge ich den Express++ Source ?

also wenn du Änderung vorgenommen hast dann per build19.bat eine neue DClipX.LIB erstellen
und testen ob du damit klar kommst. Wenn ja dann schreib Roger eine Msg ob er die Stelle mit
deinem Beispiel überarbeiten könnte.

[Markus Walter]

Hi Jimmy,

ich werde mich an Roger wenden. Die Zeilen, die Du rauskommentiert hast werden ja wahrscheinlich schon in anderen Situationen Ihren Sinn haben...

[AUGE_OHR]

hi,

ich werde mich an Roger wenden. Die Zeilen, die Du rauskommentiert hast werden ja
wahrscheinlich schon in anderen Situationen Ihren Sinn haben...

naja ... ich würde es einfach ausprobieren und sehen wie es in deinen Applicationen "wirkt", den
das musst du ja eh wenn Roger was ändern sollte

sehen wir uns doch mal den Code an:

Code: Alles auswählen

   IF ! ::EditBuffer() == ::Get:Buffer

wenn also der Editbuffer nicht dem Get:buffer entspricht

Code: Alles auswählen

//
//  hier wird der Editbuffer überschrieben 
//
*     ::SetEditBuffer( ::Get:Buffer )

dann überschreibe den:Editbuffer mit dem Get:buffer.
Da läuft es bei deinem Beispiel ja nicht ...

Code: Alles auswählen

      DC_GetEditUpdated(.t.)

und nun wird der Update Flag gesetzt.

Es geht also nur um das "überschreiben" mit ::SetEditBuffer() was man "testen" müsste.

Natürlich wäre es optimal wenn du verschiedene PICTURE und ValType() ausprobieren würdest
und die gesamte Resultate mit Beispielen Roger präsentieren würdest ...

[Tom]

Hallo, Markus.

Ich habe es mit Build 249, 250 und mit der aktuellsten Version (252/14) getestet. Sobald man im zweiten Get-Feld "Entf" drückt, rutscht der numerische Wert um eins nach links, und wenn man dann "ENTER" betätigt, wird das dieserart vor dem Komma entstandene Leerzeichen mit einer Null aufgefüllt. Aus "100,00" wird dann "1000,00". Das ist definitiv falsch im Sinne von "nicht das Ergebnis, das man erwartet hätte". Und Roger meldet sich nicht dazu?

[Markus Walter]

Ich habe es mit Build 249, 250 und mit der aktuellsten Version (252/14) getestet. Sobald man im zweiten Get-Feld "Entf" drückt, rutscht der numerische Wert um eins nach links, und wenn man dann "ENTER" betätigt, wird das dieserart vor dem Komma entstandene Leerzeichen mit einer Null aufgefüllt. Aus "100,00" wird dann "1000,00". Das ist definitiv falsch im Sinne von "nicht das Ergebnis, das man erwartet hätte". Und Roger meldet sich nicht dazu?

Hi Tom,

also bei mir wird aus der 100,00 eine 10000,- (also Faktor 100). Ich bin mir relativ sicher, dass dieser Effekt vom Dezimalzeichen kommt. Roger werkelt da sicher im internen :buffer des :get-Objekt aus dem XbpGet herum. Express-User mit englischem Windows haben den Effekt wohl nicht (hat schon jemand aus Rogers Webboard getestet). Den gleichen Effekt hat man übrigens bei einem Paste aus der Windows-Zwischenablage (Ergebnis im Windows-Taschenrechner: 6,45 -> Paste -> 645,00 im Eingabefeld). Das Ganze ist immer dann, wenn ein Picture verwendet wird.

Leider reagiert Roger wirklich nicht auf meine Fragen im Webboard...
Ich habe ihm aber eigentlich nichts getan...

Benutzt Du in Deiner Applikation keine numerischen Eingaben mit Picture?

[Tom]

Hallo, Markus.

Stimmt, Faktor 100. Ist bei mir auch so.

Ja, ich benutze genau das ziemlich häufig in meinen Apps (also numerische DCGETs mit PICT). Und, man höre und staune: Die App verhält sich "richtig" - Entf, ENTER - der Wert rückt wieder an das Komma heran. Ich schaue mal, ob ich herausbekomme, woran das liegt. Verblüffend.

[Tom]

Aha.

Es geschieht nur dann, wenn vor dem "." in der PICT-Klausel mehr als drei Neunen stehen. Das hier:

Code: Alles auswählen

n := 10.00

@ 1,1 DCGET n PICTURE "999.99"
DCREAD

erzeugt keine Probleme, aber sobald man aus dem PICT "9999.99" macht, treten sie auf. Offenbar nimmt Roger fälschlicherweise an, dass Tausenderpunkte vorhanden wären oder sein sollten.

[Markus Walter]

Stimmt, Faktor 100. Ist bei mir auch so.

Ja, ich benutze genau das ziemlich häufig in meinen Apps (also numerische DCGETs mit PICT). Und, man höre und staune: Die App verhält sich "richtig" - Entf, ENTER - der Wert rückt wieder an das Komma heran. Ich schaue mal, ob ich herausbekomme, woran das liegt. Verblüffend.

Hi Tom,

damit wäre mir sehr geholfen...

Evtl. eine SET COLLATION/CHARSET/LocaleConfigure-... Einstellung ?!

[Tom]

Hallo, Markus.

Keine Einstellung. Es hat mit der Anzahl der Neunen vor dem Punkt zu tun. Mit bis zu dreien geht es, ab da geht es schief. Irgendeine Sache mit dem Tausender-Trennzeichen (das man überhaupt nicht benutzt an dieser Stelle). Ich habe dazu was ins Webboard geschrieben.

[AUGE_OHR]

hi,

Leider reagiert Roger wirklich nicht auf meine Fragen im Webboard...

ich habe doch die Lösung gepostet und ihr hab doch den Source, also warum macht ihr nicht
selbst die Änderrungen ? Solange man selbst sich helfen kann warum soll man das auf andere
abschieben ?
... und "testen" muss man sowieso und dabei wird man dann schon feststellen ob es einen
"Sideeffect" gibt ... also nicht alles auf Roger abschieben.

[Tom]

Hallo, Jimmy.

Ich glaube nicht, dass das die Lösung war.

Es macht durchaus Sinn, Roger um Prüfung und Korrektur zu bitten, und zwar aus folgenden Gründen:

1. Die Korrektur muss ja sowieso eingepflegt werden, sonst ist sie mit der nächsten Version wieder weg
2. Es ist bei der Größe von eXpress++ zu erwarten, dass z.B. Get/Set-Funktionen unerwartet reagieren, wenn man an so einer entscheidenden Stelle wie im GetReader etwas ändert - gefährlich
3. Die (eXpress++)-Community hätte in dieser Variante auch etwas von der Korrektur

Ich habe schon einige Fehler in eXpress++ gefunden und auch korrigiert, bin aber inzwischen dazu übergegangen, solche Fehler - günstigerweise mit Hinweis auf mögliche Korrekturen - Roger zu nennen, statt sie selbst zu beheben. Letztlich aus den drei hier genannten Gründen.

[AUGE_OHR]

hi,

Ich glaube nicht, dass das die Lösung war.

wieso ? ... ich habe es doch ausprobiert

Es macht durchaus Sinn, Roger um Prüfung und Korrektur zu bitten, und zwar aus folgenden Gründen:

1. Die Korrektur muss ja sowieso eingepflegt werden, sonst ist sie mit der nächsten Version wieder weg
2. Es ist bei der Größe von eXpress++ zu erwarten, dass z.B. Get/Set-Funktionen unerwartet reagieren, wenn man an so einer entscheidenden Stelle wie im GetReader etwas ändert - gefährlich
3. Die (eXpress++)-Community hätte in dieser Variante auch etwas von der Korrektur

Ich habe schon einige Fehler in eXpress++ gefunden und auch korrigiert, bin aber inzwischen dazu übergegangen, solche Fehler - günstigerweise mit Hinweis auf mögliche Korrekturen - Roger zu nennen, statt sie selbst zu beheben. Letztlich aus den drei hier genannten Gründen.

Ja das ist mir auch klar, deshalb sprach ich ja über "Sideeffect". Ich habe auch Roger meine
"Resultate" übersandt und genau das meine ich doch. Das es einen BUG gibt ist ja nun bekannt,
aber nun wird eine "Lösung" gebraucht. Wenn Roger also die Stelle ändert MUSS jeder es noch
anschliessende mit "seiner" Application testen und dabei gibt es dann auch wieder "Resultate".

Also kann man den Weg doch auch "umkehren" und erst die Proben machen und die "Resultate"
an Roger schicken statt darauf zu "warten" bis Roger was ändert !?

Wer mit der SL1 arbeitet hat doch auch täglich mit dem Problem zu kämpfen. Wenn man einen
BUG findet muss man 1.) ein Sample machen und 2.) "andere" Wege finden um weiterarbeiten zu
können. Man kann also nicht auf Alaska oder irgend jemanden "warten" sondern muss es selbst
versuchen.

Nun bin ich ja gar kein Express++ User und trotzdem nehme ich mich des Problem an, genauso
wie das "transparency" Problem mit XpButtons. Wenn nun keiner die "Lösungen" ausprobiert,
kann ich es mir ersparen euch solche Lösungen mitzuteilen und ihr müsst eben warten bis Roger
euch irgendwann mal eine Lösung liefert ... aber auch die müsst ihr testen.

Also Jungs, das Forum ist nicht nur dazu da Informationen "anzugreifen", es wäre auch schön
wenn "Lösungen" erarbeitet werden wozu es der Mithilfe jedes einzelnen Teilnehmers bedarf.

[Markus Walter]

Hi Jimmy,

grundsätzlich ist es ja schön, dass Du Dich dem Problem angenommen hast und wohl eine Lösung erarbeitet hast, die funktioniert.

Ich möchte trotzdem eine Lösung von Roger aus folgenden Gründen (aus denen, die Tom schon gepostet hat, die sehe ich genauso):
a) Das Problem tritt offensichtlich nicht mit englischen Windows auf. Offenbar liegt die Problematik also in einem "Lokalisierungs-Problem (weiß nicht, wie ich es anders nennen soll) begründet. Ich vermute, dass Roger an irgendwelchen Stellen innerhalb von ::SetEditBuffer oder "tiefer" begründet. Da bin ich einfach nicht tief genug drin in Rogers Quellen um da Änderungen "vernüftig" machen zu können, die dann auch funktionieren (auch dann mit englischem oder russischem Windows...).
b) Das gleiche Problem besteht offenbar mit einem Paste in ein solches GET mit Picture. Auch hier kommt es - unter deutschem - Windows zu falschen Ergebnissen (6,45 wird durch paste zu 645,00).
c) Nicht zuletzt ist das ein klarer Fehler, der einige (eben zumindest alle deutschen) Express-Anwender berührt, in einer "alltäglichen" Situation (ist ja jetzt wirklich nichts aussergewöhnliches, was ich hier tue). Ich habe ein einfaches, kurzes Beispiel geliefert (was Roger -verständlich - immer haben will) und dann darf ich auch erwarten, dass Roger sich darum kümmert, zumindest antwortet. Meine Kunden erwarten von mir ja auch, dass ich Fehler beseitige...

[brandelh]

Hi,

nach Euren Beschreibungen vermute ich mal, dass Roger auf das Zeichen '.' abfragt um Zahl vor dem "Komma" zu beenden und die "Nachkommastellen" zu beginnen.
Dies funktioniert nur in Ländern die dieses Zeichen auch wirklich verwenden. Ein ähnliches Problem hatte ich bei meiner Eingabe, wobei ich zwischen 1000er Trennpunkten und DezimalPunkt unterscheiden musste ...

Statt "." oder "," direkt zu verwenden, sollte man dieses Zeichen über SetLocale(NLS_SDECIMAL) abfragen.
Wenn es dann schief läuft, hat der Anwender seine Windowseinstellungen nicht richtig

[AUGE_OHR]

hi,

nach Euren Beschreibungen vermute ich mal, dass Roger auf das Zeichen '.' abfragt um Zahl vor dem "Komma" zu beenden und die "Nachkommastellen" zu beginnen.

eben nicht, es wird nichts abgefragt.

Dies funktioniert nur in Ländern die dieses Zeichen auch wirklich verwenden. Ein ähnliches Problem hatte ich bei meiner Eingabe, wobei ich zwischen 1000er Trennpunkten und DezimalPunkt unterscheiden musste ...

und genau da sehe ich das Problem das Roger nicht lösen kann, Wie soll er es ohne eine deutsche Version machen sprich "prüfen" ? Das selbe Problem hab ich mit meinen chinesischen
Sachen wo Alaska zwar die Sample hat aber es ohne chinesischen OS() nicht zu "prüfen" ist.

Es geht doch effektiv nur um die eine Zeile

Code: Alles auswählen

//
//  hier wird der Editbuffer überschrieben
//
* ::SetEditBuffer( ::Get:Buffer )

und die kann doch jeder "lesen". Ein Sample an Roger ist zwar gut, aber eine Lösung wäre besser.

Da es sich ja "nur" um die numerischen Datentypen handelt könnte man ja mit VALTYPE() vorher
prüfen und dann ein TRANSFORM() ansetzten oder ...

dass Roger sich darum kümmert, zumindest antwortet.

sicherlich hat Roger deine Mail gesehen und es auf seine todo Liste gesetzt, aber ich denke er
hat z.Z. andere Probleme als sich um ein "speziell deutsches" Problem zu kümmern.

Meine Kunden erwarten von mir ja auch, dass ich Fehler beseitige...

Da du den Source hast kannst du es doch machen. Es ist ja nicht so, wie bei der SL1 v347, das
man nichts dagegen unternehmen könnte als auf Alaska zu warten bis ich eine funktionsfähige
DLL bekomme um weiter debuggen zu können.

p.s. es würde mich mal interessieren ob noch jemand anderes als ich den Source von Express++
"gelesen" hat ... ich habe von der v249 ca. 40% bislang "gelesen" (in 3 Wochen)