save dialogue stuck

[J. Landman Gay]

On 2/22/04 10:03 PM, Friedrich F. Grohmann wrote:

> I am now thinking of moving to Rev and you mention 5500 cards come close 
> to the limit. This is indeed very, very bad news for me. I rushed to 
> check the Rev  documentation and it says that the maximum number of 
> objects in a stack is "unlimited." Admittedly I'm getting confused. The 
> stack in question has now 1.2 MB. Is this too much for Rev under OS X? 

No, not at all. I should explain more. There is no theoretical limit to 
the number of cards, and you can create as many cards as you like within 
the limitations of your hardware and RAM. There are two things, however, 
that make very large database stacks less practical in Revolution than 
they were in HyperCard.

The first is that HyperCard is disk-based; you can have very large 
stacks that run in a very small amount of memory because each card loads 
as needed. Revolution loads the entire stack into RAM at once, which 
makes it run much faster, but which also requires that the user have as 
much RAM as the stack takes on disk (plus a little more for the engine.) 
It doesn't sound like memory is a problem yet with your stack, though.

The second thing that is much different is the "find" command which is 
commonly used in HyperCard to search a card-based database. HC used its 
famous "hint bits" to create an incredibly fast search. Revolution does 
not use hint bits and Rev's card and field searching is noticeably 
slower than HyperCard's. This was the primary limitation I was talking 
about. If you are using typical HC search routines to look up words in 
your dictionary, you may find in very large stacks that the "find" 
command becomes too slow to be suitable. Under these conditions, it is 
usually recommended that MC/Rev be used as a front-end to a more 
traditional, dedicated database.

However, if you are using a custom indexing routine rather than using 
"find", you may be just fine.

Scott Raney used to recommend that stacks not go above 3-5,000 cards or 
so before being moved to a more formal database. That isn't a hard 
number, just a suggestion. I always took it to mean that performance 
slowed enough after that to make a difference. Speed would also probably 
depend on how many objects and backgrounds are in the stack

>>Finally, try setting the HCAddressing property to false. You don't need 
>>it in Rev. I don't really think this will make all that much difference, 
>>but I usually do it anyway. It does affect some aspects of stack 
>>behavior sometimes, and you don't need it to be true when working in 
>>Revolution.
>>
> 
> I was not aware of this property and happily followed your suggestion. So 
> far, saving works fine and hopefully stays that way. 

So that made the delay go away? That's good to know. :)


-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com