flds and cd flds

[Devin Asay]

On Apr 16, 2009, at 3:44 PM, DunbarX at aol.com wrote:

> This one killed me.
>
> I imported an old HC stack, and ungrouped a few groups. I kept getting
> errors that there was "no such object" when I referred to certain  
> fields. Rev
> apparently groups HC bg objects (but not cd objects) when it imports.
>
> The problem went away when, on a lark, I added "cd" to my field  
> references:
>
> I can put "foo" into cd fld myField, but cannot put "foo" into fld  
> myField.
>
> I just assumed that since there was only one kind of field in Rev (a  
> nice
> simplification when you get used to it) that the engine would know  
> what I was
> talking about and make all imported fields, of whatever original kind,
> well, fields.
>
> So I made a new HC stack with two cd flds, two bg flds, two cd btns  
> and two
> bg btns. I brought this into Rev and saved it. All imported fields,  
> whether
> cd or bg in HC, must be referenced with "cd fld" in Rev.
>
> There is no such issue with buttons. Though bg buttons are also  
> imported in
> a group, ungrouping them leaves only one kind of Rev button. Both  
> "btn" and
> "cd btn" references are valid, regardless of what sort they started  
> out as.
> This syntax holds also for buttons created in Rev itself.
>
> I get the accommodation for HC script compatibility, but this is  
> backwards
> for fields at a minimum, and wierd to boot. There are two kinds of Rev
> fields, no? Any way to make the "cd" version without importing from  
> HC?

Craig,

Are you familiar with the HCaddressing property? It determines whether  
the cd or bg domain modifiers are required when referring to fields.  
When I import HyperCard stacks the first thing I do is set the  
HCAddressing to false and go through and change all of the cd and bg  
object references to plain old button or field.

Devin

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University