mmmm... ok. But first, can you provide an example of ANY application that displays that much text or that many lines in a field? A-Whaaay back when, Microsoft ran into this problem with large Word and Excel files. They got around it by developing a paging system that only kept in memory a certain number of pages before and after the currently displayed page.
If it is absolutely necessary for this app to display that much data, I suggest developing a paging engine that tracks the vScroll to determine what to display and cache. (caching just for speed.) Re-engineering the field object is not the solution methinks. It would probably negatively impact the performance of the field object. FWIW the Datagrid Library ALSO has paging built in. Bob S On Jan 19, 2023, at 12:16 , Paul Dupuis via use-livecode <use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>> wrote: All the responses about crashing - because lines are too long (exceeding 65K chars or 32K x in line length) or there are too many lines (and so 32,767px of scrollable height is not enough) - strongly indicated that an overhaul of the standard field object is needed in LC 10, or, more likely, in LC11. No matter what a developer or user tries to do with a field, it should not crash. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
