> I haven't actually tried it but would it work to just put empty into the
> field before deleting the card? That would be sort of a "clean as you go"
> approach.
That’s a very neat workaround which should leave at most a couple of bytes of
uncollected garbage, until the bug is squashed.
Of
I haven't actually tried it but would it work to just put empty into the
field before deleting the card? That would be sort of a "clean as you go"
approach.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On May 25, 2018 9:26:21 PM
So now we have confirmed the
“delete-card-with-unshared-textfield-leaves-unreferenced-text-which-compact-does-not-remove”
bug (thanks to Brian and Richard) the question remains how to actually remove
the garbage.
As Brian says deleting the background groups will remove the residual text; you
Brian Milby wrote:
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
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
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
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
I can reproduce the time issue (100 cards - 8.5MB file - 71s), but not the
space issue. Have a button copy a card and paste it 100 times and then
“save this stack”. Another button deletes the last card until there is only
one left and then does the same. File size goes to 85kb in 673ms. This is
on
Neville Smythe wrote:
> Actually I just did a hex dump of the 8MB file saved from the 1 card
> stack; and lo! it has an EOF at about the 28KB position, at which
> point BBEdit stops dumping the file; up to that point it appears to be
> the correct data for a 1 card stack, no extraneous garbage.
Did you attempt to do a “save as” on the stack? From what you described it
sounds like LC wrote the file in place but did not truncate what was there
after the EOF so extra data was there on the end. Need to try this on
Mac/Linux to see if it does the same thing.
On Tue, May 22, 2018 at 9:14 AM
Hmm, excellent suggestions from Phil and Richard, but evidently something else
is going on.
> Use "compact stack" to get rid of space formerly used by now-deleted
> objects.
compact stack did not recover the 8 MB after deleting all but the first card
from my test stack to reduce it to what
Thanks Phil, I knew there had to be a command. Of all the synonyms I tried I
got close with compress ;-)
Turns out a stack of mine used by national organisation for 20 years had
bloated from 3MB to 9MB.
> Use "compact stack" to get rid of space formerly used by now-deleted
> objects.
Does your card contain a group with its backgroundBehavior set to true?
If so, and if the cards are created with copy and paste, I believe you
may find a large number of unplaced groups in the stack.
In the IDE menus see Object -> Place Group
If that submenu is long, you've found your
Neville,
Use "compact stack" to get rid of space formerly used by now-deleted
objects.
See the docs.
Phil Davis
On 5/21/18 5:42 PM, Neville Smythe via use-livecode wrote:
I am constructing a large stack as a test for a bug report (to report the slow
saving of large stacks for a
I am constructing a large stack as a test for a bug report (to report the slow
saving of large stacks for a standalone Windows 10 app under LC 8.x). I start
with a stack with a single card which saves as a 28 KB file. I then use a
script to create 299 copies of card 1. The resulting stack saves
15 matches
Mail list logo
