>Thanks for the link. Whilst it doesn't *explain* in so many words, the >article does clearly *demonstrate* why a HyperCard developer might have >reservations about switching to REALBasic. This paragraph from middle of >the second page really summed it up for me: > >> This relies on two things we get for free in HyperCard: the clicktext >> property, and the ability to "find." But we don't get either of those in >> REALbasic! Thus we must implement them ourselves. So the first >>thing that the >> txt EditField's mouseup event handler must do is to work out the >>"click text." >> To do this, I start with the point of the selection and expand in both >> directions until I hit a character that isn't a word character: > >What follows is a lot of code to implement a really short HyperTalk script. >In fact, from the example provided in this article, I counted 52 lines to >implement an 8 line HyperTalk script. Had Matt used Revolution, he wouldn't >have needed to do that... >
Yes, but let's be clear that this is just a difference between the environments not a clear advantage of one or the other. Such code needs to be written once (or copied from elsewhere) and then can be reused. So the advantage of xTalk is kinda short lived. The strongest point that article makes is that for people who are not afraid to do more "real" programming, RB is an option but it is a give-some-get-some situation. However, for quite a few xTalkers, Hypercarders in particular, the reason for staying with it is exactly that they don't want to switch or have "reservations," as you said it rightly, to that style of programming. One thing that seems to be omitted is a mention that RB also supports extensions (in form of plugins) to supplement the environment and address shortcomings. Robert
