Hi Nigel. It helps me to see cards as forms. Also, you do not exactly *have to* embed you code in buttons and fields. You can put all of your nuts and bolts code in the stack script if you like, but it makes large complex apps more difficult to manage, and there is the downside that extremely large scripts take longer to compile than short ones.
Concerning the message path and objects, it also helps me to think about where the highest object (the stack script being the lowest and last to receive a message, barring back scripts) where shared code can be accessed by the objects on a card or background that needs them. That is where I will put the command or function. (Some will say this the other way around, but I am thinking about a flow chart working top to bottom as the message progresses.) The practical upshot of this is that hardly any of my nuts and bolts code, I think that is called business logic, is located in the objects that started the message. So there end up being three places (and a fourth if you use behaviors) that most of my actual code is located. The first is a group containing the objects that generate the message, the second is the card script, the third is the stack script and the fourth and optional one is a behavior script. Behavior scripts are useful to me because I typically make database applications, and I have sets of cards that are similar in function, or that have a lot of shared code, validations routines and table population routines and such for example. So I can put that code in the behavior script for the cards that share that functionality, giving me a one stop shop for the code base for a given set of forms (cards). But my main point is that the objects themselves, buttons, fields and graphics in my applications tend to only contain code necessary to perhaps get some information from the user, and then call the actual command or function that does the work, which in turn calls other commands or functions, and off we go. It does take a little getting used to, especially coming from a high level language like c++ or java, but once you "get it" development becomes much easier and smoother, mainly because so much setup code you used to have to write is already done for you. So think of Livecode as a Rapid Application Development framework, and learn to work within that framework, and you will have it down in no time. Bob On Dec 27, 2012, at 11:07 AM, Nigel Soden wrote: > Craig, you're quit correct. My mind flows in the direction of this cursed OOP > philosophy and have to remind myself to re-wire the grey cells. No. I had > never heard of HyperCard or any of the variants . It was only when I got > LiveCode did I find out the history of the product. The 'beauty' that > attracted me to LiveCode was the concept used to developing application using > "messages" via a route and the Card concept which made sense, but that's were > I trip up mixing the two technologies together while thinking through a > problem. The fact also the syntax is something I've not seen before and I > have to think in terms of a speaking language rather than the 'Enigma" style > been propagated today. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
