PureBoard

Verfasst: **29.11.2004 18:31**

Ich habe dazu schon was gelesen, aber bin mir nicht mehr sicher.
Ich habe ein Programm, dass eine 55k große Textdatei in ein Editorgadget list und auch wieder schreibt.
Was passiert wenn die Datei mal größer als 64K werden sollte?
(zu Zeit schreibe ich einfach mit writestring())

danke

Verfasst: **29.11.2004 18:40**

Bei mir wurde der String, der länger als 64k war einfach abgeschnitten. d.h. es ist einfach Schluss, der Text hört scheinbar auf. Ich glaub, es kam kein Critical Error oder sowas.

Wenn du längere Strings verwenden musst, musst du das über den Speicher lösen

Verfasst: **29.11.2004 19:29**

Ein Editorgadget behandelt die Einträge wohl irgendwie anders, nicht mit Strings. Jedenfalls hatte ich gerade ein paar Tests mit meinem Texteditor verantaltet und dabei kam raus, dass auch Dateien welche größer 64 Kb waren problemlos komplett eingelesen werden können. Ich hatte konkret als Beispiel 95 Kb an Daten und diese eingelesen. Danach auch wieder abgespeichert in eine Textdatei und es waren nachher alle Daten vollständig da. Also wenn du nicht den ganzen Inhalt der Textdatei in EINEN String laden willst, sollte es gehen. Demnach musst du auch den Inhalt später Zeilenweise auslesen und speichern. Ansonsten könnte es stringtechnisch Probleme geben.

Verfasst: **29.11.2004 19:37**

ok, dann mal konkret:
Das Programm macht folgendes:

1. Im source wird bereits ein textfile mit includebinary eingebunden.
Dieses setze ich mit setgadgettext und peeks(*mem) in das editorgadget.

2. Man kann das textfile auch aus dem web laden (nach *mem). von dort setze ich es wieder mit setgadgettext in das editorgadget. (und von dort speichern)

3. Man kann das textfile auch von Platte laden, da nehme ich zur zeit readdata und lese nach *mem usw.

Um die 64k Stringgrenze zu umgehen kann ich also memory nehmen. Ich muss nur noch wissen wie ich einen memory Bereich in das Editorgadget bekomme und wie ich es wieder auslese.
Und natürlich ob das Editorgadget dann mehr als 64K schafft.

Verfasst: **29.11.2004 20:08**

mit sendmessage

Verfasst: **29.11.2004 20:24**

@RINGS
Ich liebe dein Antworten.

Ich habe da was von EL_CHONI gefunden,aber es geht bei mir nicht.

#listing ist ein Editorgadget mit SendMessage_(GadgetID(#listing), #EM_LIMITTEXT, -1, 0)

Code: Alles auswählen

Global RTFPtr.l,RTFStart.l,RTFEnd.l

Procedure StreamFileInCallback(dwCookie, pbBuff, cb, pcb) 
  result = 0 
  Debug RTFPtr
  Debug cb
  If RTFPtr>=RTFEnd 
    cb = 0 
    result = 1 
  ElseIf RTFPtr+cb>=RTFEnd 
    cb = RTFEnd-RTFPtr 
  EndIf 
  CopyMemory(RTFPtr, pbBuff, cb) 
  RTFPtr+cb 
  PokeL(pcb, cb) 
  ProcedureReturn result 
EndProcedure 

Procedure _PutRTF() 
  RTFPtr=RTFStart 
  uFormat = #SF_RTF 
  edstr.EDITSTREAM 
  edstr\dwCookie = 0 
  edstr\dwError = 0 
  edstr\pfnCallback = @StreamFileInCallback() 
  SendMessage_(GadgetID(#listing), #EM_STREAMIN, uFormat, edstr) 
EndProcedure 

;Aufruf
RTFStart=?listing
RTFEnd=?endlisting
Debug RTFStart
Debug RTFEnd
_PutRTF()

EDIT:
geht doch. Musste nur aus #SF_RTF #SF_TEXT machen.

Wunderbar. Jetzt muss ich nur noch den Inhalt des Editors wieder ins Memory bekommen. Mal sehen...

Kein Fehler, keine Meldund, Editor bleibt leer...

Verfasst: **29.11.2004 20:43**

Kann man den Speicher nicht aufteilen? Angenommen du hast einen Speicherbuffer von 100 KB und willst diesen übertragen. Per PeekS() gehts nicht da die Grenze mit 64 K steht (deine These, nicht getestet). Dann nimm doch von diesem Speicher erst einmal die ersten 64 Kb und daraufhin die nächsten 64 Kb (falls es noch so viele über sein sollten). Also einfach den Speicher aufteilen. Wenn die Datei per Includebinary eingebunden ist, hängt sie doch an einem bestimten Byteteil der Exe. Dann kann man doch die ersten 64.000 byte reinschreiben und von dort 64.000 drauf zählen und dort weiter machen. Oder kann man das nicht so einfach machen?

EDIT: Ich hab aus Bequemlichkeit 64.000 geschrieben, ich weiß dass 1 KB 1024 byte sind.

EDIT2: ALso es klappt zwar mit dem Aufteilen des Speichers größerer Dateien, allerdings kann SetGadgetText() nur bis zu 64 Kbyte große Strings verwalten. Will man also per Aufteilung in mehrere Strings den gesamtresultierenden Text hinzufügen, darf dieser auch wieder nicht größer als 64Kbyte sein. Demnach bringt das ganze getrenne nix...

Verfasst: **29.11.2004 21:58**

Code: Alles auswählen

options.SETTEXTEX
options\flags = #ST_DEFAULT
options\codepage = #CP_ACP
SendMessage_(GadgetID(#RichEdit),#EM_SETTEXTEX,@options,*mem)

oder

Code: Alles auswählen

SendMessage_(GadgetID(#RichEdit),#WM_SETTEXT,0,*mem)

*mem ist ein Nullterminierter Pointer, sprich ein Pointer auf
den ASCIIZ-String.

Oder EM_REPLACESEL zum einfügen/verändern.

Verfasst: **29.11.2004 22:31**

@DANILO
Danke,
jetzt habe ich es mit EM_STREAM_IN und STREAM_OUT auch schon geschafft.
Hätte ich einfacher haben können...

Oder hat WM_SETTEXT nicht auch wieder die 64K Grenze?

Verfasst: **30.11.2004 00:13**

wichtel hat geschrieben:@DANILO
Danke,
jetzt habe ich es mit EM_STREAM_IN und STREAM_OUT auch schon geschafft.
Hätte ich einfacher haben können...

Oder hat WM_SETTEXT nicht auch wieder die 64K Grenze?

Nein, keine Grenze bei 64 Kb, es geht mit WM_SETTEXT auch wenn der Buffer größer ist. hab ich gerade getestet.

PureBoard

Editorgadget und String - maximale Länge ?

Editorgadget und String - maximale Länge ?