Yes, I know that's possible. But it can't do: switch temp case < 4 break case > 10 break end switch
Pete Haworth On Mar 2, 2011, at 4:33 PM, dunb...@aol.com wrote: > No, I think it can resolve any LC statement, no? > > > put 3 into temp > switch > case temp < 4 > put "lessThan" > break > case temp = 11 > put "never see this" > break > end switch > > > Craig Newman > > > > > > -----Original Message----- > From: Peter Haworth <p...@mollysrevenge.com> > To: How to use LiveCode <use-livecode@lists.runrev.com> > Sent: Wed, Mar 2, 2011 6:19 pm > Subject: Re: A curious case > > > Switch is definitley very handy but I wish it was more flexible. As far as I > can tell, the case statement can only test for equality, for example: > > switch myvar > case begins with "xyz" > > ... generates an error as does anything else other than just a straight value > on > the case line. > > I know you can do > > switch > case myVar begins with "xyz" > > ...just seems like conditions other than = would be more elegant on the case > line. > > Pete Haworth > > On Mar 2, 2011, at 3:03 PM, Bob Sneidar wrote: > >> I think the switch control structure is pretty handy for this. If you put >> all > the conditions that will not require a break at the top, then the program > will > flow down through your conditions and only execute the code inside your case > statements if the conditions are true. Towards the end of the switch > statement > put the conditions that will break when met (if any). It reads much cleaner. >> >> Bob >> >> >> On Mar 2, 2011, at 2:39 PM, Peter Brigham MD wrote: >> >>> On Mar 2, 2011, at 11:26 AM, Richard Gaskin wrote: >>> >>>> Andre Garzia wrote: >>>>> I tend to work on the same way. longer forms makes shorter understanding >>>>> time. I'd rather write more and understand more than write faster and then >>>>> one week from now, be completely lost in nested mazes >>>> >>>> Well said. >>>> >>>> And sometimes lengthy deeply-nested IFs are good candidates for a switch > block. >>>> >>>> I once stumbled across two tips about code style that have been very > helpful: >>>> >>>> 1. If a given function has nested IFs more than three levels deep, it may >>>> be > a good candidate for breaking it up into smaller functions. >>>> >>>> 2. If a function is longer than can be viewed in one screen, it may be a > good candidate for breaking it up into smaller functions. >>>> >>>> Sometimes those can't be applied for sound practical reasons, but where >>>> they > can oh boy does it make code more readable. >>> >>> I grapple with this all the time. My status with LC is "dedicated amateur," > so I may not use the best practices, but.... One other consideration is > breaking > out a chunk of code when it needs to be reusable, but this is not without > problems too. >> <snip> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > _______________________________________________ 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