Back to LC & Inventive Users

Richmond Mathewson richmondmathewson at
Tue Aug 16 03:57:52 EDT 2011

On 08/16/2011 10:24 AM, Kay C Lan wrote:
> Judy,
> I might be too late to the thread but I'll offer a slightly twisted
> perspective of where to go with this. These are adults, right?
> Don't ask them so much about what they like, instead figure out what ticks
> them off the most, or wastes their time the most or elicits the response
> 'it's a friggin computer, it should be able to......'
> To me, and I don't mean any offense to those who suggested them, but to
> build a calculator,

I had one kid who wanted to make an egg-timer for his Granny.

> address book, music library, etc etc, would having me
> rolling my eyes with I've already got one of those, why reinvent the wheel -
> with one that is worse than the free one I've already got. I'd switch off in
> that class immediately.
> But a special kind of calculator - for specific task as per the Therac-25
> suggestion, or a music library that allows me to search the lyrics - because
> iTunes doesn't, now that would interest me.
> as Peter Brigham said in another tread:
> but I think that the most user-friendly apps are those produced by the
>> people who use them...
>> my own practice management stack is miles ahead of anything else I've seen
>> but then I designed it for just the way I think and work
> To me the key is to have your class members identify a number of small
> 'real' problems that you filter to those you know that LC can quickly solve.
> These might take YOU anywhere from 1 - 6 hrs to solve. You might also
> discover that a couple of problems fall into the same category, like text
> parsing - my favourite ;-) It might then be possible to work with the class
> as a whole to solve one problem, then assign homework to apply their new
> found knowledge to solve the other.
> As an example, I'm interested in buying a second hand car, and I visit two
> websites to check out what's available. It's a hassle flicking through the
> pages and trying to remember how many kms the 2005 model for $14,990 had. So
> for each site I've created a script that takes the data and scrapes it for
> only the info I'm interested in: model, year, kms, number of owners,
> transmission, price. The data is then stored in a db from which I can group,
> compare and order the cars so that I can figure which appear to be better
> value for money.
> As for lesson 1, I reckon a 100% chance that someone will have a text
> manipulation problem so after discussing what people want their computer's
> to do, I'd cover how easy it is to work with text in LC. Simple stack, two
> fields - one to enter data, the other for output. Start with a button, but
> eventually go with 'on closeField'. Show them how they can extract the
> first, second, last and char/word/line 24 from the field. How they can add
> or remove char/word/line. How char/word/line can be rearranged. If the text
> happens to be a list, how they can be referred to as items. How if the data
> has any form of consistency, then extraction of specific data is easy; this
> can be because it's always on line x, it's always word y, it's always the
> word before 'kms', or are the chars immediately after $ - you can avoid grep
> and still find the data, that's the great thing about LC. But if you spark
> someone's interest, you can always teach them a grep solution too :-)
> And just to give you my personal favourite, I'd teach them the switch
> statement.
> switch (tInput)
>    case ("yes")
>       hYesHandle
>    break
>    case ("no")
>      hNoHandle
>    break
>    default
>      answer "An answer I wasn't expecting" title "Case Error!"
>     breakpoint
> end switch
> I hated nested if-then-else statements which can be extremely hard to
> understand, so unless I'm 100% certain that it's yes/no, true/false, or 1/0
> , I always use a switch statement similar to above - with the default set to
> tell me I'm missing something followed by a breakpoint. As soon as I get a
> "maybe" input, I'm prompted that I need extra code, presented with the
> Script Editor exactly in the handler where the extra code is needed and the
> Variable Pane showing what's in tInput so I can immediately figure out why
> the script didn't proceed as expected. For newbie programmers this can save
> a huge amount of time wasted (read - turn you off programing frustration)
> trying to figure out why the outcome is wrong.
> Good luck,
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the Use-livecode mailing list