Editorgadget und String - maximale Länge ?
Editorgadget und String - maximale Länge ?
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
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
PB / jaPBe jeweils aktuellste Version, seit 3.62 dabei, XP sp3 de/en & W7 en
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. 
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.
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.
PB / jaPBe jeweils aktuellste Version, seit 3.62 dabei, XP sp3 de/en & W7 en
@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)
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...
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...
Zuletzt geändert von wichtel am 29.11.2004 21:33, insgesamt 1-mal geändert.
PB / jaPBe jeweils aktuellste Version, seit 3.62 dabei, XP sp3 de/en & W7 en
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...
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...
Code: Alles auswählen
options.SETTEXTEX
options\flags = #ST_DEFAULT
options\codepage = #CP_ACP
SendMessage_(GadgetID(#RichEdit),#EM_SETTEXTEX,@options,*mem)Code: Alles auswählen
SendMessage_(GadgetID(#RichEdit),#WM_SETTEXT,0,*mem)den ASCIIZ-String.
Oder EM_REPLACESEL zum einfügen/verändern.
cya,
...Danilo
"Ein Genie besteht zu 10% aus Inspiration und zu 90% aus Transpiration" - Max Planck
...Danilo
"Ein Genie besteht zu 10% aus Inspiration und zu 90% aus Transpiration" - Max Planck
Nein, keine Grenze bei 64 Kb, es geht mit WM_SETTEXT auch wenn der Buffer größer ist. hab ich gerade getestet.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?