Removing a stack from memory - is this a bug?

[Stephen Barncard]

Joe, welcome to the list. I didn't get serious with Rev until 2003. 
I've been around xTalks since I built many stacks for 
<http://barncard.com/amstudios/htdoc/Pages/TC.html>A&M Records in 
1986-1998 and was on the MacMarines and Evangelist lists.

I too came to Rev seeking immediate conversion of many HC stacks.

My first hurdle was that I was using a lot of XCMDs and XFCNs. Since 
rev has almost everything you need natively, a lot of these can be 
'patched' by defining the HC functions in syntax in a stack script 
(or library) that is always available.

Even common functions that were in HC have different syntax, like replace()

FUNCTION replace2 stringToReplace,ReplacementString,textBlockToReplaceIn
     replace stringToReplace with ReplacementString in textBlockToReplaceIn
     return textBlockToReplaceIn
END replace2

The error messages could keep you busy on a freshly imported stack.

Sometimes it's easier in the long run to export the data while still 
in Hypercard land... and recreate on the rev end, or better yet, use 
a real database like Valentina or MySQL.

One tends to end up starting from scratch redesigning newer and 
better ways to do the task in Rev vs HC, because the feature set is 
so rich. Only the simplest of stacks (1 background, x cds)  can be 
imported into rev directly, but by re-thinking the data and using the 
really good controls included, you could find yourself building 
things even more quickly than HC.

One example. I often used to have to use over 100 xcmds in a stack to 
make it do things I wanted it to do. A pair of them was created by 
the great Rinaldi, and were called TextRes() and ResText().  All they 
did was to save text data as a resource file inside the stack, and 
retrieve it.

tada! In Rev one can have custom properties...  and add TextRes() and 
ResText() handlers to take their place and eventually replace them 
after stuff gets working..

and laying out of the elements is a lot more fun....and real color!!

anyway, Hang in there! We on this list have figured it takes about a 
couple of weeks working with a project where it all starts to make 
sense  - the proverbial AHA moment - followed by moments of complete 
bafflement, after which one gives in and asks on this list what the 
hell is going on. You'll get your answer in about 4 flavors in about 
an hour. And eventually it will become second nature.

It was easy for me to say at first  "ah this will be easy because I'm 
an Hypertalk power user" and then get down to actually learning the 
exceptions and new commands. But it's quick and fun and beautiful (at 
least on a Mac!!) and the cross platform thing is a bonus.

I'm sure others would have some tips for converting stacks.

sqb



>I've only been exploring Rev for a week or so, and have already 
>unearthed a number of significant differences. To be expected, but 
>somewhat discouraging at times. So much alike and yet so different. 
>Patience is the keyword! Thanks for the reference to the tutorial. 
>There are obviously tons of things that have been written. Frankly, 
>I don't want my articles to be TOO "Rev polished" in the beginning. 
>I want to stumble around much as others might do, discovering as 
>many Revolution pitfalls and idiosyncrasies as possible. Since I 
>have hundreds of HC stacks, one of my initial challenges will be the 
>conversion of some of the more  interesting ones to Rev. It's not as 
>if I'm going to be cutting through a lot of brand new turf, so much 
>as doing my own stumbling; much as I did in the early years with HC. 
>Incidentally, I'm a practicing Architect, so some of these HC stacks 
>are fairly mathematically intense. Seems like everyone "practices" 
>something these days. Don't we have any experts these days? (smile)
>
>Thanks JLG,
>
>Joe Wilkins

-- 
stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -