Removing a stack from memory - is this a bug?

[Joe Lewis Wilkins]

Thanks for the welcome wagon, Stephen. Even though I do have a number  
of HC stacks to convert, with the realization of the problems, I've  
just about come to the conclusion, that the easiest way may be to  
create the Rev stacks from scratch and merely copy and paste the HC  
scripts in the appropriate places in the Rev stack and tweaking them  
as needed. One of the major problems I see is the "background"  
situation which is so much different than with HC. It requires a  
major change in "mind-set".

I have hundreds of XCMDs and XFCNs that I created using CompileIt  
that enabled me to number crunch very fast, even with an SE30, in HC.  
I haven't come to a conclusion as to whether these Externals can be  
put into a Library and called directly from Rev Stacks or not. Lots  
to read. At least I'm doing it on a Mac.

I have a major graphics application that I hope to implement using  
Rev. It'll be done from scratch. I looked at Valentina some time  
back. With the amount of memory and speed we have these days, I'm  
inclined to think that we can probably load our data into memory,  
keep it there and use it, instead of even using a database. We'll see.

Joe Wilkins

On Dec 27, 2006, at 2:04 PM, Stephen Barncard wrote:

> 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
> - - -  - - - - - - - - -
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution