LiveCode Forums

Have you checked for unplaced groups and non-visible objects?

Yes, early on, to make sure, I wrote a routine that counted all controls and scripts everywhere and worked until I got to zero. Unplaced groups are always hard to track down if you are not relentless.

I had forgotten that one could compact a stack. A holdover from HC, I assume? Anyway, no effect. The stack file dump is unchanged. I would be interested to see how the binFile of the stack file develops as one adds controls and handlers. And whether that data changes if a control is deleted.

Interestingly, though the dump is over 2 Megs in length, a "get info" on the stack file itself only shows a size of about 75K. I guess I do not know what either of those two figures actually mean.

Craig

What is a "dump"?

dunbarx wrote: ↑

Fri Apr 26, 2019 7:37 pm

I would be interested to see how the binFile of the stack file develops as one adds controls and handlers. And whether that data changes if a control is deleted.

Actually, I think that should be pretty easily accomplished. This is klutzy, but certainly could be polished... For instance, you'd probably have to put a save stack as line in there after making the button or whatever and like that.

I think it was Mikey who had an even better way in a different thread, but I seem to have misplaced the link

Mr Richard Gsaskin, of Fourth World Computing, asked:

What is a "dump"?

Mr Gaskin, sir, I learned this term only recently. Let me see from where and from whom...

AHA! Found it. The source of this highly technical term may be seen in the first reply in this thread. I have used it extensively since.

Craig

dunbarx wrote: ↑

Fri Apr 26, 2019 10:22 pm

Mr Richard Gsaskin, of Fourth World Computing, asked:

What is a "dump"?

Mr Gaskin, sir, I learned this term only recently. Let me see from where and from whom...

AHA! Found it. The source of this highly technical term may be seen in the first reply in this thread. I have used it extensively since.

I used it as a verb. I understand the verb. There are many ways to obtain metrics about data. Just trying to help.

So when you read the stack file as binary, and get "the number of bytes of" whatever variable it's in, that's ~2MB, but the file manager shows that same file to contain only ~75k?

That's either magic, a bug in the file manager, or an early warning sign of disk media damage.

FourthWorld wrote: ↑

Fri Apr 26, 2019 1:02 am

It's been a long time since I tried reverse engineering the file format.

If so motivated, no reverse engineering is required (at least for non-encrypted stacks) since we can read the source.

Having looked at it briefly a while back it is a little curious that data is hanging around. There was a bug where orphaned data didn't get removed (non-shared text in background objects after being removed from cards). That one was fairly easy to construct a test that demonstrated the issue. If something else like that still exists it would be worth tracking down and fixing.

bwmilby wrote: ↑

Fri Apr 26, 2019 10:47 pm

FourthWorld wrote: ↑

Fri Apr 26, 2019 1:02 am

It's been a long time since I tried reverse engineering the file format.

If so motivated, no reverse engineering is required (at least for non-encrypted stacks) since we can read the source.

That's how long it's been.

Having looked at it briefly a while back it is a little curious that data is hanging around. There was a bug where orphaned data didn't get removed (non-shared text in background objects after being removed from cards). That one was fairly easy to construct a test that demonstrated the issue. If something else like that still exists it would be worth tracking down and fixing.

Hmmm...let's confirm that the file was read as binary and that the length was measured with "the number of bytes", and we'll see what can be done.

The weird part here is the file manager reports a very different size. If that's not accounted for by reading as text and/or getting length using any non-binary means (e.g., "len" or "number of chars") then the source of this mystery may be outside LC.

Richard.

I suspect you are not as sophomoric as I. This is not necessarily a bad thing.

I know you were just trying to help. I always know that. You are nothing if not both helpful and knowledgeable. I am afraid, though, that you are usually serious as well. But behavior of that sort will not prevent me from acting like a 13-year-old.

Now then.

The length of the stack file, er, dump, seems to increase in the stack I was fooling around with every time I close and reopen it. I will have to verify this next week, but it is now up to 34M. I noticed it because in the few lines of code I used to read it, I asked for the length of the dump itself. It got to that size in about 10 openings and closings. Opening the stack now takes about 15 seconds, and I get a beachBall to look at as lagniappe.

This is odd. Getting info about that file from the desktop "get info" seems to stick at about 75K.

This ought to be fun.

Craig

I'm not sure what this would prove, but try locking messages, opening the stack, and getting the length.

Unplaced groups are always hard to track down if you are not relentless.

They should all be in the Objects - > Place group menu.

How does one get the "length" of a stack object?

Jacque, you mean, of course, the length of the binFile dump?

Craig

I hope she means "the number of bytes of" the data in a variable read from a binary read the stack file. The length function will attempt tell you the number of characters, likely incorrect for non-textual data. And if you obtain that value only after LiveCode transforms it for display in a field I have no idea how far the count will be further off.

I'm not sure what I was thinking, but yes, the binfile data in a variable. And now that I've had coffee, it occurs to me that getting binfile data won't do any conversions so locked messages wouldn't apply.