how to clear residual garbage in a stack?

[Brian Milby]

Ok, I can summarize what is happening here.  When a card that contains a
background with shared text disabled on a field, the data is indeed
retained.  The extra data survives saves and "compact this stack" as long
as the shared group remains on any card.  If you remove the group from the
last card and then do a compact, then all of the extra space is recovered.
When you place the group back on a card, the fields are now empty.

As implied by the documentation, if you remove the group from the last card
and do a save from the menu, the space is also reclaimed.

I'm inclined to call this a bug although I'm not sure where to place the
blame.  It could be in the "remove group" process (which would happen when
deleting the card) - if the share text is false and the group is on more
than one card (current + n>=1), the current text should be discarded (undo
doesn't work, so that isn't a reason to keep the data around).  It could be
in the "compact this stack" process - extra data for background fields
should be removed.  My guess is that for performance, the second one will
take the blame here though.  Would be good for someone from LC to respond
(Ali or Monte probably) with their thoughts.  I'm not sure where that lives
in the source code.  It does make me curious about how text field data is
stored for shared groups.

On Wed, May 23, 2018 at 4:53 PM, Brian Milby <brian at milby7.com> wrote:

> I’ll need to test further. I created a stack that ends up with a bunch of
> groups and could delete them after. Have not tried putting text in a field
> like you described though.
>
> On Wed, May 23, 2018 at 4:29 PM Neville Smythe <
> Neville.Smythe at optusnet.com.au> wrote:
>
>> That’s if you use copy-paste to create the cards, because each group will
>> have lost its original card. The groups are still available in the Place
>> menu (and the browser?) and OK I suppose this is not a bug, but that there
>> is no mention of this in the Dictionary for Delete is a serious deficiency.
>>
>> But if you use new to create the cards, there is only one background
>> stack for the whole group, and it is still in card 1 after deleting the
>> other cards. In the case that the background field does not share text, the
>> bug is that the text for all the deleted cards is still in the stack, but
>> with no way to reference it (I believe), and is not removed by compact.
>> [Even in the copy case, I wonder of the shared text is still there… will
>> have to check that, but not today…]
>>
>>
>> On 24 May 2018, at 1:32 am, Brian Milby <brian at milby7.com> wrote:
>>
>> You have to go to the Object menu and choose Place Group to see all of
>> the orphaned groups. All I did to replicate was put the big field inside a
>> group and made it a background. I’m sure it would be possible to delete
>> them, but I would need to look for the process.
>> On Wed, May 23, 2018 at 7:12 AM Neville Smythe via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>>
>>> Thanks Richard.
>>>
>>> Disregard my nonsense about the EOF at 28KB, I misread the BBEdit
>>> output. The file did indeed have extra garbage after deleting all but 1
>>> card.
>>>
>>> The extraneous data actually consists of the text of the background
>>> field from the deleted cards: “Lorem ipsum” occurs 2024 in the hex dump,
>>> but Find and Replace can only find 18 instances, all in the single card
>>> remaining.  Very similar to the unplaced background groups left over as you
>>> reported if the cards are created by copy-and-paste, but in this case I
>>> created them with new card (with a field in a background group). This bug
>>> is worse because there is no handle to the orphaned text in the browser or
>>> menus! Note that I’m still thinking of this as a bug, rather than a problem
>>> with my system :-) - it happens in Windows as well.
>>>
>>> Brian Milby tells me that he could not replicate the bug in LC 9 if the
>>> cards are created with with copy-and-paste and no background groups.  I’ll
>>> do some more testing with LC9, with and without a background group and the
>>> two methods of creating cards (and on Windows and Linux). My guess is that
>>> compact stack is not working correctly in the case of deleting cards with
>>> background fields in LC8, and this may or may not have been fixed in LC9.
>>>
>>> Brian does also confirm the slow saving in Windows 10, in fact his times
>>> are much worse. Are there no longer any Windows 10 users of LC? (to be fair
>>> my stacks compiled under LC 8.1.x do perform well under Windows 10 except
>>> for the terrible saving problem).
>>>
>>> Neville Smythe
>>> _______________________________________________
>>> 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
>>
>>
>>