[Bugreport] Bereichsvariable

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

  • Mal ne Frage,
    warum ist den die Bereichsvariable zu klein?



    [Blockierte Grafik: http://s13.postimage.org/ww2bcjccj/Text_Datei.jpg]

  • Hab die Textdatei ohne CRLF erstellt und die hat dann 175 Bytes. Laden will er Sie erst ab 179 Bytes, was für mich unlogisch ist. Ein Nullbyte sollte genügen, aber selbst wenn XProfan von alleine ein CRLF anhängt sollten 3 Bytes genügen.


    Ich würde das als Bug sehen.

  • In meiner Testdatei, ist nicht ein CRLF enthalten, so hab ich das von GT43A
    auch verstanden, des weiteren habe ich auch doppelte Backslashes genutzt,
    was Aufgrund des Pfades auf meinem System aber auch keine Rolle spielt
    (d:\3.txt)


    Es ist und bleibt ein Bug ;)

  • Zitat von THFR;922200

    Ich habe, auch noch schnell mit X2.0c getestet, kein Problem. Den Text in den Editor und als 3.txt gespeichert.


    Hast Du wirklich mit X2 getestet? Das Bild sagt was anderes und bei mir
    passt es mit X2 nämlich nicht!


    PS: Ist Deine 3.txt auch 175 Bytes groß?


    Ich vermute mal, Du hast ein CRLF am ende eingefügt, dann geht es. Es muß aber auch ohne gehen!

  • Ja, dann auch bei mir eine Fehlermeldung. Im Prinzip müsste ja Dim Bereich#,@FileSize($) reichen. Ist leider nicht immer so und ich, wenn ich es verwende, erhöhe es pauschal um 500. Kann ja nicht schaden. In diesem Fall würde 4 reichen.


    Gruß Thomas

  • Zitat von ts-soft;922194

    In meiner Testdatei, ist nicht ein CRLF enthalten, so hab ich das von GT43A
    auch verstanden, des weiteren habe ich auch doppelte Backslashes genutzt,
    was Aufgrund des Pfades auf meinem System aber auch keine Rolle spielt
    (d:\3.txt)

    Es ist und bleibt ein Bug ;)



    Hallo Thomas richtig Interpretiert.:-)

    Und nun Speichern wir mal den Inhalt der eingetragen werden kann!
    Ist ja ein Multiedit



    Und da haben wir es wieder das Tapfere Schneiderlein, 7 auf einen Streich.;)

  • Zitat von Frabbing;922236

    Denke eher an ein CR/LR Zählfehler.


    Fehler = Bug ;), in der Datei gibt es kein CR/LF, deshalb sollte XProfan
    auf EOF (EndOfFile) reagieren und nicht sinnlos weiterlesen, wo nichts ist.


    Das Problem tritt mit jeder Textdatei auf, die nicht mit einer Leerzeile, bzw. CR/LF endet.

  • Dass Readtext noch CR abhängt ist doch aber schon seit Jahren bekannt und dass man eine Zugabe zum Speicher machen muss auch, in der Regel + 4.


    Aber das Beispiel mit dem Speichern ist kein Bug, da wurde ja alles falsch gemacht, was man falsch machen kann. In einem Multiedit hat gettext$() nur einen Parameter und holt immer den gesamten Text aus dem Edit. Wenn das Edit 7 Zeilen hat holt er auch 7 x den gesamten Text heraus. Zeilenweise wird ab X2 mit getString$() und getCount() ausgelesen, vorher mit getLine$() und getLineCount(). Profan müsste aber wenn ich zwei Parameter auf ein Multiedit anwende aber einen Fehler melden. Stattdessen wird der zweite Parameter einfach nur ignoriert.

  • Zitat von Unregistriert;922249

    Profan müsste aber wenn ich zwei Parameter auf ein Multiedit anwende aber einen Fehler melden. Stattdessen wird der zweite Parameter einfach nur ignoriert.


    Nun, Profan hält es schon immer so, dass überzählige Parameter einfach ignoriert werden. Fehlermeldungen gibt es nur bei fehlenden Parametern.


    Gruß
    Roland

    (Intel Duo E8400 3,0 GHz / 4 GB RAM / 250 GB HDD / ATI Radeon HD4770 512 MB / Windows Vista - ausgemustert zum Verkauf)
    AMD Athlon II X2 2,9 GHz / 8 GB RAM / 500 + 1000 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X4


    http://www.xprofan.de

  • Zitat von Unregistriert;922249

    Dass Readtext noch CR abhängt ist doch aber schon seit Jahren bekannt und dass man eine Zugabe zum Speicher machen muss auch, in der Regel + 4.

    Aber das Beispiel mit dem Speichern ist kein Bug, da wurde ja alles falsch gemacht, was man falsch machen kann. In einem Multiedit hat gettext$() nur einen Parameter und holt immer den gesamten Text aus dem Edit. Wenn das Edit 7 Zeilen hat holt er auch 7 x den gesamten Text heraus. Zeilenweise wird ab X2 mit getString$() und getCount() ausgelesen, vorher mit getLine$() und getLineCount(). Profan müsste aber wenn ich zwei Parameter auf ein Multiedit anwende aber einen Fehler melden. Stattdessen wird der zweite Parameter einfach nur ignoriert.




    Re: Speichern ist kein Bug -> das hat niemand behauptet das es einer ist!

    Assign #1,("C:\XProfanX2\Rossdam\3.TXT")
    Rewrite #1

    'Und was ist das
    WhileLoop @GetCount(M_Edit&) :?: 'habe ich bereits verwendet
    Print #1,@GetString$(M_Edit&, &Loop) 'Und nun:?:
    'Print #1,@GetText$(M_Edit&, &Loop)
    EndWhile
    Close #1

    das Ergebnis ist dasselbe!
    Ist das auch schon seit Jahren so?

    Recht hast du natürlich mit GetText.

  • Wie oben schon geschrieben wurde holt Gettext$() den gesamten Text aus dem Multiedit. Eine Schleife ist also überflüssig bzw. falsch !


    Das Speichern sollte wohl eher so aussehen:


    Code
    Assign #1,("C:\\3.TXT")
      Rewrite #1
      Print #1,@GetText$(M_Edit&)
    Close #1

    Gruss
    Andreas


    ______________________
    http://www.ampsoft.eu


    Profan 3.3 - XProfanX2
    Windows 95,98,ME,2000,XP
    Vista - Windows 7 32 / 64 Bit


    ASUS X93S - Intel Core I7 - NVIDIA GForce GT540M - 8GB Arbeitsspeicher