Re: Problem with writing a patch stack
on 9/17/00 5:29 AM, Raymond E. Griffith at [EMAIL PROTECTED] wrote: >> 2. Edit the old stack as a pure text object. Obviously this is tricky, not >> recommended, perhaps not possible at all, possibly a violation of the >> license agreement, and in general Not A Good Idea. But it would certainly >> not produce the script limits problem your current method does. >> >> gc > But this will not work for two reasons. First of all, the stack is binary, > not text. Editing as text means also saving as text, thus destroying the > stack. Even if your stack has a .txt ending, it is still written as a > binfile. I misspoke saying text, but I believe it _is_ possible. Open the standalone builder to see how. The only roadblock I see possible is if MetaCard stores internal references to the length of a script, for example, that might need to be updated at the same time. Stack integrity could be an issue. > > I tried opening a stack I had so edited. Kablooey. > > And even so, there are some things that should not be done wrg the license > agreement. If changes in the stack's script need to be done so that the > scriptlimits are not violated. > > And there *are* ways to legally handle scripting with the unlicensed version > so that you are doing everything you want to do. I know. I have been doing > it for some time. I never violate the scriptlimits, yet I can do a great > deal. Basically it involves placing code in non-script places, as custom > properties, and running them with do statements. The scriptlimits also apply to do statements, I believe. But Scott, isn't this whole conversation moot? I thought the licensing limitations were to limit an end user's ability to add their _own_ code, not to prevent them from applying a patch that a licensed developer provided them? >There are also other > techniques. If you want to know more, start a new thread and ask. > > One other suggestion. Create the stack with other stacks as plugins that > your main stack accesses. You can upgrade the plug-in. This last is certainly a good suggestion. gc Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Graphic Display
Thanks for all your advice, Scott. I seem to have sorted it all out now. In particular, the delays and grey areas showing graphics on Windows, have been removed by doing everything in a preOpencard handler. I had been a bit wary about preOpencard handlers because of problems in another context. But they work perfectly for this. Good old Metacard - sorted it yet again! Hope it does it for you too, Eva. Mike Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Quitting!
>What Mac are you using/how much memory? I had a similar problem on my iMac >with 46MB memory until I turned system sleeping off, which virtually >eliminated any memory related system crashes. The language lab G3 computers all have 64 Mb of memory. My G4 development machine has 256 mb of ram so I figure lack of memory is not so much of a problem. I will keep a watch out for system sleeping. Thanks Pierre Sahores wrote: >No sure you are wrong. Try : >wait 1 tick >quit The wait 1 tick is something I hadn't thought of I will give that a spin and see what happens. Thankyou. Michael Crawford Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Problem with writing a patch stack
One other thought about patching stacks... Remember that MC's stackfile format changed at certain version releases. That may have an effect on your success, depending on the version of the engine that runs thing you're patching, and what kinds of objects are included in or affected by the patch. Phil "Raymond E. Griffith" wrote: > > > > > on 9/16/00 12:59 AM, Andy Bailey at [EMAIL PROTECTED] wrote: > > > >> I am trying to write a patch to an existing application. > > > and on 9/17/2000 5:10 AM, Geoff Canyon <[EMAIL PROTECTED]> > suggested: > > > Two other possible solutions, which may or may not violate your license, > > would be: > > > > 1. Instead of trying to copy the new stuff into the old stack, copy the > > user-customized stuff out of the old stack into the new stack. This doesn't > > really qualify as a "patch" in my book, but depending on your goals might do > > the trick. > > > This should work. I think. There was a situation some time back that I had > trouble with pasting an object created in a full version using an unlicensed > one... > > > 2. Edit the old stack as a pure text object. Obviously this is tricky, not > > recommended, perhaps not possible at all, possibly a violation of the > > license agreement, and in general Not A Good Idea. But it would certainly > > not produce the script limits problem your current method does. > > > > gc > But this will not work for two reasons. First of all, the stack is binary, > not text. Editing as text means also saving as text, thus destroying the > stack. Even if your stack has a .txt ending, it is still written as a > binfile. > > I tried opening a stack I had so edited. Kablooey. > > And even so, there are some things that should not be done wrg the license > agreement. If changes in the stack's script need to be done so that the > scriptlimits are not violated. > > And there *are* ways to legally handle scripting with the unlicensed version > so that you are doing everything you want to do. I know. I have been doing > it for some time. I never violate the scriptlimits, yet I can do a great > deal. Basically it involves placing code in non-script places, as custom > properties, and running them with do statements. There are also other > techniques. If you want to know more, start a new thread and ask. > > One other suggestion. Create the stack with other stacks as plugins that > your main stack accesses. You can upgrade the plug-in. > > Raymond > > Archives: http://www.mail-archive.com/metacard%40lists.best.com/ > Info: http://www.xworlds.com/metacard/mailinglist.htm > Please send bug reports to <[EMAIL PROTECTED]>, not this list. -- Phil Davis --- [EMAIL PROTECTED] days: (503) 417-7930 eves: (503) 557-5656 --- Facilitator Essentials of eBusiness Computing Information Technology Institute http://www.iti.com Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Problem with writing a patch stack
> > on 9/16/00 12:59 AM, Andy Bailey at [EMAIL PROTECTED] wrote: > >> I am trying to write a patch to an existing application. > and on 9/17/2000 5:10 AM, Geoff Canyon <[EMAIL PROTECTED]> suggested: > Two other possible solutions, which may or may not violate your license, > would be: > > 1. Instead of trying to copy the new stuff into the old stack, copy the > user-customized stuff out of the old stack into the new stack. This doesn't > really qualify as a "patch" in my book, but depending on your goals might do > the trick. > This should work. I think. There was a situation some time back that I had trouble with pasting an object created in a full version using an unlicensed one... > 2. Edit the old stack as a pure text object. Obviously this is tricky, not > recommended, perhaps not possible at all, possibly a violation of the > license agreement, and in general Not A Good Idea. But it would certainly > not produce the script limits problem your current method does. > > gc But this will not work for two reasons. First of all, the stack is binary, not text. Editing as text means also saving as text, thus destroying the stack. Even if your stack has a .txt ending, it is still written as a binfile. I tried opening a stack I had so edited. Kablooey. And even so, there are some things that should not be done wrg the license agreement. If changes in the stack's script need to be done so that the scriptlimits are not violated. And there *are* ways to legally handle scripting with the unlicensed version so that you are doing everything you want to do. I know. I have been doing it for some time. I never violate the scriptlimits, yet I can do a great deal. Basically it involves placing code in non-script places, as custom properties, and running them with do statements. There are also other techniques. If you want to know more, start a new thread and ask. One other suggestion. Create the stack with other stacks as plugins that your main stack accesses. You can upgrade the plug-in. Raymond Archives: http://www.mail-archive.com/metacard%40lists.best.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
