Is there any way to escape the horrible limitation of under 1MB for a TextArea? If it’s a native OS control it should accept more… According to Microsoft’s MSDN, the limitation of a default system “EDIT” field with multi-line set, is 32KB (Xojo can’t use that, it’s well over the number of bytes and not RTF compatible). If Xojo uses Comctl32.dll for the native RichTextEdit control (is the only RTF compatible field…), a default RTE field is limited to 2GB of character input.
The issue is, the file is 1.2 MB in length (starting) and must be RTF compatible plus have the ability to be edited if needed. Is there a cross-platform way around this show-stopper? I know on Windows I can use ActiveX and load a real RTF field, but 1/3rd the users are Mac users and will need a solution as well. Should I perhaps write a plugin in obj-c to programmatically create an NSTextView?
Any suggestions greatly appreciated. I thought about HTMLViewer but it’s a hassle especially with editing and everything that “could go wrong”.
[quote=103948:@Matthew Combatti]Is there any way to escape the horrible limitation of under 1MB for a TextArea? If it’s a native OS control it should accept more… According to Microsoft’s MSDN, the limitation of a default system “EDIT” field with multi-line set, is 32KB (Xojo can’t use that, it’s well over the number of bytes and not RTF compatible). If Xojo uses Comctl32.dll for the native RichTextEdit control (is the only RTF compatible field…), a default RTE field is limited to 2GB of character input.
The issue is, the file is 1.2 MB in length (starting) and must be RTF compatible plus have the ability to be edited if needed. Is there a cross-platform way around this show-stopper? I know on Windows I can use ActiveX and load a real RTF field, but 1/3rd the users are Mac users and will need a solution as well. Should I perhaps write a plugin in obj-c to programmatically create an NSTextView?
Any suggestions greatly appreciated. I thought about HTMLViewer but it’s a hassle especially with editing and everything that “could go wrong”.[/quote]
In the past, we used to go around the 64 K limits by paginating and using the UI view as a “window” on a longer, paginated series of documents each 64 k maximum in size. You could use such a trick and manage the TextArea content as a view on a big array of strings. The visible part of the text is usually pretty small, which means you have ample time even during a scroll to update modified content in the strings and load the next or previous part.
The alternative, which I believe may very well be used internally by Word to allow unlimited document size, is to open or create the big document as binary, then load and update only the UI view content, then save it when a scroll or overflow occurs. Disk access is slower, though, so you may want to verify response time for really big documents in case of content insertion.
I just quickly checked Word behavior with really big documents. The program does access the disk when a scroll occurs. Interestingly enough, it seems update of the view/work buffer to disk when a chunk of text is added (the TextArea.Text in this hypothesis), is done when the user has left the keyboard alone for a few seconds. Maybe asynchronously. Otherwise changes are taking place in memory.