Hey Gang: Though I haven't been a contributor to this list, my enthusiasm for Revolution has made me a steady reader of the posts. I've noticed the periodic discussion about how to get more out of the starter kit, a topic about which I'll share my own habits. (I've been a starter kit user in both MetaCard and Revolution.) I also couldn't help but notice that some users of the FREE STARTER KIT felt that the limitations of the FREE STARTER KIT were unreasonable. To anyone who may be dissatisfied with the FREE STARTER KIT, allow me to offer a few words of empathy and support: I feel Runtime Revolution should give you a full refund as soon as practicable. (Sorry, the temptation was just too great to pass up. But please note, my surliness stands in very stark contrast to the extrordinary patience and courtesy of the RunRev team who I think have worked with their customers in a terrific way! You go, Team RunRev! You deserve success!) Anyway, regarding the coding limit, here's what I've been doing. In my earlier projects, I used to establish dedicated cards merely to hold fields, which I used as variables, typically hidden from the user; and buttons, whose only function is to hold code in their scripts. Think of the buttons not as objects that the user interacts with, but Code Storage Objects (CSO's). Recently, I not only put the variables and the CSO's on their own dedicated cards, but also in their own substack. That way, I can view the user-interactive cards on one side of my monitor, and the CSO's on the other. Then, when the code in the CSO's is tested, I can watch the results appear on the user-interactive card to make sure that everything is working OK. (How do you test the code in a CSO? Click on the button!) But remember this: an object need not be visible in order for the script of that object to execute. So, when the application is deployed (not that these are commercial apps or anything...far from it), the substack and cards containing the code need not be visible. If you look at one of my cards containing variables and CSO's, you will probably see 15 to 25 variables lined up vertically on the left side of the card, and perhaps 5 to 15 CSO's lined up vertically on the right side. I usually try to put 5 to 8 lines of code in a CSO. Next to each variable, I put a little lable field which shows the exact name of the variable. That way, I don't have to open up the properties of the variable in order to see what its name is. Oftentimes, all of the code in all of the buttons needs to execute when the user changes an input value in the program. So, I also need to establish CSO's that might be called "controller buttons". Their job is to send mouseUp commands to the other CSO's in their proper sequence. In fact, I might have one controller button send mouseUp's to three other controller buttons, each of which sends mouseUp's to five CSO's. How is this control tracked? Well, there are three things that I do. I try to provide comments within each CSO before the mouseUP handler. Also, I write a descriptive phrase in the tooltip of the CSO. Last, using the graphic tools, I might also draw lines between the "controller button" and all the CSO's to which the controller button sends a mouseUp message. (At times I've made these "lines" look like the "connectors" available in the graphic tools of Microsoft Excel.) Then, when I look at the card I immediately notice, "This button calls the routines in these other five buttons." I agree, it's not as easy as having an application with no limit on coding length. However, it does provide at least one advantage: it forces the programmer to put his code in smaller packets, each of which is easily and independently testable. Does the CSO called "Calc_Moment_of_Inertia" work correctly? All I have to do is click on it once, and see what results are produced. Caveat: Almost all of the programming I do is to solve civil engineering problems. I usually use Excel, but the MetaCard/Rev starter kit is a fun alternative on occasion. I haven't done any programming where I needed to sort a 10,000-member list; nor have I created any animations. So, I can't say that my coding habits would work for a wide range of applications. Also, I haven't shared many of these little applications with other folks. So, I haven't been writing complex routines to make sure that the user input is valid. So far, I am the only goof for which I have to goof-proof my programs. Just wanted to share my little Starter Kit Tips (Ess Kay Tees), and to give Team RunRev what I consider to be a high compliment in the business world: "Job well done." Tom Nally, New Orleans
