"unShared" Custom props for new cards?

[Mark Smith]

Does it help to know that CPs are like handler-local variables in one  
respect, in that you can create them simply by putting values into  
them, without any initialising step eg:

put thisTamilSong into the uTamilSong of this cd

and then, if  a CP doesn't yet exist, getting it's value will return  
empty eg:

get the uTamilSong of this cd
if it is not empty then put it into fld "songText"

Exporting to XML should be simple, too

repeat with n = 1 to the number of cds in this stack
   repeat for each line L in the customKeys of cd n of this stack
     addToYourXMLfile the customProperties[L] of cd n of this stack
   end repeat
end repeat

where addToYourXMLfile is whatever handler does the XML work.

Mark


On 20 Feb 2006, at 10:00, Sivakatirswami wrote:

> I'm keeping a set of songs, about 70 in a small data base, each one  
> has it's own card, and has several versions in r fields, Original  
> Tamil, English transliteration, literal translation, prose  
> translation, Lyrical Song version.
>
> Now, I'm wanting to keep some other versions as well, but it's  
> cumbersome to show these.. right now I have five fields  set up has  
> a horizontal series in a group with a horizontal scroll bar... Only  
> two fields can be viewed at at time.. and I have a "hoist" feature  
> which moves one field to the front position... it's all a bit  
> "wonky" (?) but it works.  These get exported to XML files and then  
> imported into Indesign for printing...I'm realizing that if I "take  
> the plunge" to storing data in custom properties that suddenly a  
> lot  of the display issues are simplified. just present the  
> different versions data in the custom props into "generic" the two  
> visible display fields. This allows for extensibility with adding  
> and programming for, more fields in the UI.
>
> But if one adds a set of  custom properties for the various  
> versions, it has to be done for each card. If you set a custom  
> property to a background field that holds different text on  
> different card, the custom property persists... i.e. it is a  
> "shared" custom property for that field for all the cards. if I  
> edit the  text of that  prop, it  is  also edited for the same  
> field on all the cards. edit the custom prop "uTestText" of fld  
> "English"  on card 1 and your edits appear in the "uTestText" of  
> fld "English" on cards 2 through 70...even though the fld content  
> of fld "English" is different on all the cards. This makes perfect  
> sense of course.
>
> So, the question is... is there some way to set up some kind of   
> custom prop set, such that when you do "create card"  the new card  
> will have  those custom props generated  automatically, but which  
> are empty and  unique to that card? I realize the work around would  
> be to write a script to adds the custom props to  all the existing  
> cards and then trap the create card handler in the future and cause  
> it to do a "clone card" instead and then clean out all the data in  
> the fields  and custom props of the newly cloned card... this would  
> emulate a kind of "background custom property set" that is  
> "unshared" but the same across all cards.
>
> but before I go ahead with this... I was just wondering if I missed  
> a feature on the vast ocean of Rev's syntax that might allow for  
> setting up such an "unshared" background custom property set whcih  
> becomes, like,  part of the placed background that is auto added to  
> new cards.??
>
> TIA
> Sivakatirswami
>
>
> _______________________________________________
> 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