Encountering slow navigation to a card containing very large fields? Do this one simple trick.

[Craig Newman]

Dave.

I played around a bit with a field on a card that has 100,000 lines of text and an overall length of 5 Meg. There is not question that such a well-packed field is sluggish in several ways. Just try to make it wider using the pointer tool.

But a simple mouseUp handler in the field takes the value of the clickLine and loads it into a field on a different card. The process is instantaneous. What does your setup have that mine does not, so that you are seeing intolerable delays?

Craig

> On Apr 19, 2022, at 6:38 AM, David V Glasgow via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Maybe context would help.  I receive digital evidence from police Hi Tech Crime Units, consisting of lists/tables of messages, search histories, web histories, files downloaded, etc etc.  These relate to online activities of alleged internet offenders. Some consist of data relating to a few months activity, others may be 10 years or more - so vary hugely in the sheer quantity of data. This is what is imported into the first field.
> 
> I have established a number of sets of keywords/tags  which can be cycled through using ‘filter with’ to find list items which might indicate particular forms of malign motivation of the alleged offender. So, a user clicks button “Filter with X keywords” looking for, for example,  coercive/aggressive tags.
> 
> All ‘filtered with' lines containing selected tags appear in the second scrolling field. Sometimes nothing much will be found, but sometimes this field may become 50 to 74% the size of the field containing the original  imported data.  This (second) field can be scrolled and eyeballed until something of forensic significance is spotted.   Clicking on that line scrolls the first field to display and highlight the line in its original context (i.e showing preceding and following lines).  
> 
> With respect to Bob’s observation about the work to display a background group being 'already done’ if the navigated-to card contains the background group containing the field, that is pretty much what I assumed is happening.  The intriguing question is why the work necessarily  is ‘undone’  when navigating to any card not containing the group.  Does it consume such significant resources the default is to clear it?  It would be nice to be able choose to preserve or cache the work if that has such a significant impact on performance as in this case. 
> 
> Best Wishes,
> 
> David Glasgow
> 
> 
>> On 18 Apr 2022, at 7:02 pm, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> David Glasgow wrote:
>> 
>>> The user just initiates the automatic filtering for various keywords.
>> 
>> What does that mean? What actions do they perform requiring them to review the full list?
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> ____________________________________________________________________
>> Ambassador at FourthWorld.com                http://www.FourthWorld.com
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode