Re: Hard CASE: cracking the nut?
OK, I think I have this worked out. I spread my scripts around (reminded me of my HyperCard days and running into the 32k script limit!) and got everything below the 10 statement limit and it seems to be working now. Thanks, Marty Marty Knapp wrote: What I have is a standalone that contains template stacks from which a user creates their own stacks. These stacks are saved outside of the standalone. I wanted to institute an updating feature, where the user's stack version is compared to the template (which may have had revisions from being updated) on launch and if needed to have the standalone copy the scripts from the template into the user stack, rather than making them create a new stack. But if any of these scripts exceed the 10 statement limit it will not work. So I stripped the template stack of as much code as I could, which also minimizes the need for updating in the first place :) But this user stack needs access to the standalone stacks and scripts to function properly, so now I've found that if the user launches the standalone by double-clicking their stack, that once in a while the stacks/scripts it needs are not available and I get errors when the user stack loads. Not always, but probably 1 in 10 times. I've tried a number of routines to check for this, but these routines need to be in the user stack and I run into the 10 statement limit . . . I hope that's understandable! Only sort of, I'm still a little confused. But basically when I have a system with templates, I put almost nothing in the template except very generic handler calls. I put all the actual, working handlers in the app's script, where I can change them without updating the templates. I'm not sure why your templates need to contain any updating code. They should just call a handler like checkUpdates, which the main stack executes. It can then act on any stacks it needs to change (with the exception of long scripts, but if you use the generic approach to handlers, that shouldn't be a problem.) If your users double-click a stack to launch your app, your app will first get all the startup, preOpenStack, openStack etc. messages, and then will open the user stack. The mainstack's script should automatically be shared as a backscript, but if that isn't always happening you can specifically insert it on preOpenStack. That should clear up any issues your user stacks may have accessing the mainstack script. Also make sure the handlers in the user stack pass any necessary system messages if your mainstack needs to operate on those. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Hard CASE: cracking the nut?
Marty Knapp wrote: What I have is a standalone that contains template stacks from which a user creates their own stacks. These stacks are saved outside of the standalone. I wanted to institute an updating feature, where the user's stack version is compared to the template (which may have had revisions from being updated) on launch and if needed to have the standalone copy the scripts from the template into the user stack, rather than making them create a new stack. But if any of these scripts exceed the 10 statement limit it will not work. So I stripped the template stack of as much code as I could, which also minimizes the need for updating in the first place :) But this user stack needs access to the standalone stacks and scripts to function properly, so now I've found that if the user launches the standalone by double-clicking their stack, that once in a while the stacks/scripts it needs are not available and I get errors when the user stack loads. Not always, but probably 1 in 10 times. I've tried a number of routines to check for this, but these routines need to be in the user stack and I run into the 10 statement limit . . . I hope that's understandable! Only sort of, I'm still a little confused. But basically when I have a system with templates, I put almost nothing in the template except very generic handler calls. I put all the actual, working handlers in the app's script, where I can change them without updating the templates. I'm not sure why your templates need to contain any updating code. They should just call a handler like checkUpdates, which the main stack executes. It can then act on any stacks it needs to change (with the exception of long scripts, but if you use the generic approach to handlers, that shouldn't be a problem.) If your users double-click a stack to launch your app, your app will first get all the startup, preOpenStack, openStack etc. messages, and then will open the user stack. The mainstack's script should automatically be shared as a backscript, but if that isn't always happening you can specifically insert it on preOpenStack. That should clear up any issues your user stacks may have accessing the mainstack script. Also make sure the handlers in the user stack pass any necessary system messages if your mainstack needs to operate on those. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Hard CASE: cracking the nut?
A while back Scott Rossi wrote: Maybe because standalones have an (editable) script limit of 10 lines, meaning you can't build scripts dynamically in standalones that exceed 10 lines. There is no such limit in the IDE. seems not to, directly refer to my script problem; EXCEPT; my problematic script (that works in a stack, but not in a standalone) thread through a variety of scripts that exceed 10 lines and reside in fields. Does anybody know if reffing scripts infields is interpreted as building scripts dynamically as they are not directly entered in the 'script space' of a particular object ? If the above is so; would I be able to circumvent the need to store socking-great scripts many times over in each object by stroing a script as a custom prop in an object than can be reffed from other objects (why do I get a funny feeling that scripts stored in custom props can only be accessed by that particular object???)? How about storing the script in the stack / card script and calling it How about running down the main street with a plastic bag on my head shouting noodly, noodly, noodly, pip, pip, pip, poop ? sincerely, Richmond Mathewson. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Hard CASE: cracking the nut?
One cannot 'set the script of' inside a standalone. But perhaps a script of a stack outside the app could be written to by a SA. ( Richmond: please let us know..) I know in HC I would 'point' to various fields and get past the 30k limit of their field system. However, I don't remember how I put them in the path. I think I had some kind of handler switching system. That was over 20 years ago. Is script swapping really necessary? We've got so many ways to do things, substacks, etc without the workarounds we had to do in HC. Is there really a reason to 'do' more than a few lines? I'm sure that do'ing runs slower, too, so not good for repetitive tasks. On 26 May 2010 10:29, Richmond Mathewson richmondmathew...@gmail.comwrote: A while back Scott Rossi wrote: Maybe because standalones have an (editable) script limit of 10 lines, meaning you can't build scripts dynamically in standalones that exceed 10 lines. There is no such limit in the IDE. seems not to, directly refer to my script problem; EXCEPT; my problematic script (that works in a stack, but not in a standalone) thread through a variety of scripts that exceed 10 lines and reside in fields. Does anybody know if reffing scripts infields is interpreted as building scripts dynamically as they are not directly entered in the 'script space' of a particular object ? If the above is so; would I be able to circumvent the need to store socking-great scripts many times over in each object by stroing a script as a custom prop in an object than can be reffed from other objects (why do I get a funny feeling that scripts stored in custom props can only be accessed by that particular object???)? How about storing the script in the stack / card script and calling it How about running down the main street with a plastic bag on my head shouting noodly, noodly, noodly, pip, pip, pip, poop ? sincerely, Richmond Mathewson. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- - Stephen Barncard San Francisco ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Hard CASE: cracking the nut?
noodly, noodly, noodly, pip, pip, pip, poop ? Sounds like a great start to me. Must try that :-) If you are using do field xyz, then indeed you are running into the script limits. Write handlers at stack or library level and execute those. example at stack level on noodly answer pip end noodly now you can call noodly from any control in your stack. Example for a button: on mouseUp noodly end mouseUp Cheers, Malte___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Hard CASE: cracking the nut?
Richmond Mathewson wrote: A while back Scott Rossi wrote: Maybe because standalones have an (editable) script limit of 10 lines, meaning you can't build scripts dynamically in standalones that exceed 10 lines. There is no such limit in the IDE. seems not to, directly refer to my script problem; I'm pretty sure that's the problem, and was going to mention it except Scott beat me to it. EXCEPT; my problematic script (that works in a stack, but not in a standalone) thread through a variety of scripts that exceed 10 lines and reside in fields. Does anybody know if reffing scripts infields is interpreted as building scripts dynamically as they are not directly entered in the 'script space' of a particular object ? They are. Any script that isn't pre-compiled in the script editor is dynamic. If the above is so; would I be able to circumvent the need to store socking-great scripts many times over in each object by stroing a script as a custom prop in an object than can be reffed from other objects (why do I get a funny feeling that scripts stored in custom props can only be accessed by that particular object???)? You can access custom properties of an object from anywhere, even another stack, but even so it will be a dynamic script. So that won't work for you either. Any script that needs do in order to execute is dynamic. How about storing the script in the stack / card script and calling it That will work, and is what you should do. But note that you can't set the script of an object to more than 10 lines in a standalone either, so the script has to be static. Any script longer than that has to be pre-written and compiled in the IDE. Since you need the script for several objects, have you considered using behaviors instead? Compile the script in a button, and then assign that button as the behavior for all the objects that need to use it. How about running down the main street with a plastic bag on my head shouting noodly, noodly, noodly, pip, pip, pip, poop ? If you decide to do that, take videos, please. :) -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Hard CASE: cracking the nut?
Thank you for all the good advice: especially the last bit: - How about running down the main street with a plastic bag on my head shouting noodly, noodly, noodly, pip, pip, pip, poop ? If you decide to do that, take videos, please. :) However; being a bit of a slob, I have taken the easy route: instead of having 19 faux buttons (images) reffing a script stored in a field I have copied the offending script into each button. Oddly enough, considering the offending script is somewhere near 2000 lines (serious stuff), it doesn't seem to slow things down noticeably: compiles and builds as a standalone that WORKS. --- is Any script that needs do in order to execute is dynamic. adequately documented in the documentation ? When using a standalone application created by Revolution, you can include up to ten statements in the statementList. This limit is set by line 2 of the scriptLimits function. This limitation does not apply when using the development environment. Um . . . not terribly clear (well, at least not to the likes of me); how do sillybillies like me understand that a statementList ( a what ??) refers to a field or some other sort of container? --- Peter Sarstedt is singing I am balanced well, you see, I am a Cathedral locked in stain glass windows, I am a Cathedral dimly lit. and hemmed in solitude, and yet, I see a shangri-la, whenever the mountain wind blows, I see shangri-la and I touch it. And will you share, your crust of bread with me, and will you dare, to trust your head and see. and I know the feeling right now . . . :) -- relieved to have jumped that hurdle . . . ! ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Hard CASE: cracking the nut?
Richmond Mathewson wrote: is Any script that needs do in order to execute is dynamic. adequately documented in the documentation ? When using a standalone application created by Revolution, you can include up to ten statements in the statementList. This limit is set by line 2 of the scriptLimits function. This limitation does not apply when using the development environment. Um . . . not terribly clear (well, at least not to the likes of me); how do sillybillies like me understand that a statementList ( a what ??) refers to a field or some other sort of container? The term statementlist here is in italics, which means it's a variable name. That's the convention for all syntax descriptions in the docs. The variable in this case consists of a list of statements or a series of commands (which can be stored anywhere.) The example section on the page show several types of statementlists. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Hard CASE: cracking the nut?
I've been running into the 10-statement script limit issue myself. Is there a way to put a script into a field or custom property and execute it without a do command? If so, could someone offer an example? In my current scenario, speed is not a big issue. Thanks, Marty Richmond Mathewson wrote: is Any script that needs do in order to execute is dynamic. adequately documented in the documentation ? When using a standalone application created by Revolution, you can include up to ten statements in the statementList. This limit is set by line 2 of the scriptLimits function. This limitation does not apply when using the development environment. Um . . . not terribly clear (well, at least not to the likes of me); how do sillybillies like me understand that a statementList ( a what ??) refers to a field or some other sort of container? The term statementlist here is in italics, which means it's a variable name. That's the convention for all syntax descriptions in the docs. The variable in this case consists of a list of statements or a series of commands (which can be stored anywhere.) The example section on the page show several types of statementlists. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Hard CASE: cracking the nut?
Marty Knapp wrote: I've been running into the 10-statement script limit issue myself. Is there a way to put a script into a field or custom property and execute it without a do command? If so, could someone offer an example? In my current scenario, speed is not a big issue. That depends on what you need to do. If you need to create new scripts with new functionality on the fly then you'll need to stay within the 10 line limit. But most of the time, you can substitute backscripts, behaviors, or custom functions and handlers that accept passed parameters to do whatever you need. If you can say a little more about what you need to accomplish we can probably help better. There's not much that really requires dynamic scripting. Post your dynamic script for us to look at, maybe? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Hard CASE: cracking the nut?
What I have is a standalone that contains template stacks from which a user creates their own stacks. These stacks are saved outside of the standalone. I wanted to institute an updating feature, where the user's stack version is compared to the template (which may have had revisions from being updated) on launch and if needed to have the standalone copy the scripts from the template into the user stack, rather than making them create a new stack. But if any of these scripts exceed the 10 statement limit it will not work. So I stripped the template stack of as much code as I could, which also minimizes the need for updating in the first place :) But this user stack needs access to the standalone stacks and scripts to function properly, so now I've found that if the user launches the standalone by double-clicking their stack, that once in a while the stacks/scripts it needs are not available and I get errors when the user stack loads. Not always, but probably 1 in 10 times. I've tried a number of routines to check for this, but these routines need to be in the user stack and I run into the 10 statement limit . . . I hope that's understandable! Marty Marty Knapp wrote: I've been running into the 10-statement script limit issue myself. Is there a way to put a script into a field or custom property and execute it without a do command? If so, could someone offer an example? In my current scenario, speed is not a big issue. That depends on what you need to do. If you need to create new scripts with new functionality on the fly then you'll need to stay within the 10 line limit. But most of the time, you can substitute backscripts, behaviors, or custom functions and handlers that accept passed parameters to do whatever you need. If you can say a little more about what you need to accomplish we can probably help better. There's not much that really requires dynamic scripting. Post your dynamic script for us to look at, maybe? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
