> Shortly after this Monte Goulding was assigned to repair the standalone 
> builder, which he did with great success - maybe using some of my 
> recommendations (I do not know) or along his own lines - obvious to his 
> analytical and practical mind.

OK, I know what you are talking about. Richard this is that slowness when 
parsing object properties when the stack isn't toplevel. We discussed it a 
while back on improve in the middle of a data storage request you had. The 
LiveCode SB has to parse the stack to remove some IDE properties, make sure 
images etc are moved from libraries and so forth. Wilhelm's test stacks have 
many thousands of controls on one card and so they are slow. I did resolve the 
issue but it resulted in stacks flashing up on screen and obviously that wasn't 
appreciated. I can't remember why I didn't use go invisible but there must have 
been a reason... 

Your test stacks are in my opinion such a unique use case (I'd be interested to 
see a real app that requires 100000 controls) that it's probably reasonable to 
ignore it to avoid the visually disturbing flashing up of stacks. The MC SB 
doesn't or didn't do anything like this so the issue was never present there 
which leads you to believe there is an issue in the LiveCode SB. It does more 
and therefore takes more time. Standalone building isn't or at least I don't 
believe it should be a regular part of your day. Particularly working in MC 
where the standalone builder doesn't include anything you really only have to 
build once for each app per engine. So if it takes half an hour go and get a 

As for the protection of the standalone builder I assume RunRev believe it's 
critical to protect their investment and therefore my investment in my 
business. As a result when I considered some development I was considering for 
the GLX framework and I realised it could be used to circumvent LiveCode 
deployment packs I decided not to implement it. I would be concerned if the MC 
IDE included unprotected code that could be used in the same way. 

My recommendation to anybody working on the MC SB would be to create code that 
extracted the SB and SB settings from LiveCode and any supporting handlers and 
insert it into the MC IDE. Obviously there's going to continue to be regular 
development of deployment options and that seems the only reasonable way to 
spend your time given the limited number of users and developers of MC.


metacard mailing list

Reply via email to