Mikey wrote:
> VERY funny. Did you poke a hole in your cheek with your tongue?
Yep, and damn, now every time I take a drink the water spills out of the
side of my face like a dribble glass. That'll teach me... :)
> I have a substack - "Preferences" that has settings for various
> things, along with numerous cards of HTML templates and CSS, so I can
> update the look and feel of my output without having to screw around
> with the code.
>
> So, I want to get all the HTML and CSS out for use in the reports I'm
> building.
>
> The other thread I started today (indirect addressing) was to try to
> avoid using the
> put field x of card y of stack "preferences" into somearray[a][b],
> because it quickly becomes wider than I want, since, as you can
> imagine, "x", "y" and the somearray[a][b] are longer than what is
> implied here.
...
> So, barring the ability to indirectly address the cards and the stack,
> I was going to try the old HC method of lock messages, lock screen,
> and iterating through the cards I want, which makes the code longer,
> but narrower.
>
> Richard? Wake up Richard.
Sorry, I was testing so I'd stepped out of the room.
Unlike SC and HC, Rev is much more forgiving with object references
comprised of combinations of variables and literals.
For example, in SC you could say:
put the long id of btn 1 of cd 2 of stack "MyPrefs" into tBtn
...and that would work, but you couldn't do this:
put the long id of cd 2 of stack "MyPrefs" into tCd
put the long id of btn 1 of tCd into tBtn
...but in Rev you can. :)
I'm not sure why the compiler is so much friendlier to these sorts of
mix-n-match operations, but I rarely come across any combination that
doesn't work.
So in your case you could do something like this:
put specialFoldePath("preferences") &"/MyPrefs.dat" into tStack
if there is not a stack tStack then
-- create one
else
-- do your thing:
put the long id of cd 1 of stack tStack into tCd
--
put the uMyProp of tCd into tMyStuffA[a][b]
put the uMyProp2 of tCd into tMyStuff[a][c]
-- and so on...
end if
If performance is absolutely critical, moving the stuff from props into
an array will buy you a few millisecs over the long haul. But accessing
props directly is fast enough that you might find it even more
convenient to just make accessors for your preference settings:
SetPref "TemplateCSS", "some CSS stuff"
put GetPref("TemplateCSS") into fld 1
--
-- SetPref
-- Generic handler for setting a preference value
--
on SetPref pLabel, pValue
put PrefsStack() into tStack
set the pLabel of stack tStack to pValue
save stack tStack
end SetPref
--
-- GetPref
-- Generic handler for obtaining a preference value
--
function GetPref pLabel
return the pLabel of stack PrefsStack()
end GetPref
--
-- PrefsStack
-- Returns the full path to the prefs stack, creating
-- one if it doesn't already exist so the path is always good.
--
function PrefsStack
put specialFoldePath("preferences") &"/MyPrefs.dat" \
into tStack
if there is not a stack tStack then
-- create if it doesn't already exist:
create invisible stack
set the filename of it to tStack
save stack tStack
end if
--
return tStack
end PrefsStack
If you had attended my session at RevCon in May we covered this sort of
thing in detail. :)
More generalized variants of these handlers are being added to StdLib at
the RevInterop site:
<http://tech.groups.yahoo.com/group/revInterop/>
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
