Then palette the stack (click in the very topLeft of the altClean stack
window) and you can see for yourself.
For those of you wondering, Rev does strip these properties when building a
standalone with your stack. But, if you use stacks which aren't in
standalones (like data stacks, or plugins), you should always altClean them.
If you use the Geometry Manager to manage resizing of stacks, then you don't
want to delete the cREVGeometry prop set. It is only set if/when you are
using Geometry Manager. Sometimes, you may have tried GM and decided not to
use it, but the GM prop sets are still there. In those cases it is good to
delete the prop set.
Since I never used cREVtable, I didn't check for it. But it is a different
prop set and should be deleted. Like GM, cREVtable isn't set unless the
Table Object in the field properties settings is checked. So, just created
tabstops and hGrid,vGrid does not put it on. Frankly, I wasn't aware on how
large those props may have been.
All that said, I imagine your client was using it in a fairly unconventional
way to see those kinds of file savings. Was cREVtable caching old data?
Though many of these prop sets contain either redundant or useless data for
your deployed application, none of them actually hurt anything. So, leaving
them alone is okay, too.
use-revolution mailing list
[hidden email] Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> All that said, I imagine your client was using it in a fairly unconventional
> way to see those kinds of file savings.
Nothing more unconventional that displaying a list of records from a
In plain tab-delimited form, the list itself is much smaller than the
copy stored in the custom prop. Apparently the redundant copy of the
data is being stored in the uniquely bloated htmlText format rather than
the simple tab-delimited format the field itself uses.
I don't know why the redundant copy is in htmlText, but then again I
don't know why it's there at all....
I just gained 600Ks back from my xos stack - 60%!!!
Worse, I found that all my fields had a crevTable prop (which I NEVER
used!)... I must have accidentally clicked on the table button once...
Since then all the fields have the prop (it seems). However there's side
effect that when you select a field, choose "Table" from the menu of the
prop palette, the prop palette will go in a seemingly infinite loop... Which
is an indicator that your stack was "polutted" with the unwanted revtable
what you need to add to revAltCleanStack's card script is ...
on cleanRevTableSets pObj
get the customPropertySets of pObj
set the wholeMatches to true
delete line lineOffset("cREVTable",it) of it
set the customPropertySets of pObj to it
You also need to call it within the controls' loops in that same card
> -----Original Message-----
> From: [hidden email] > [mailto:[hidden email]] On Behalf Of
> Richard Gaskin
> Sent: Monday, 06 November, 2006 05:18
> To: How to use Revolution
> Subject: Re: cRevTable properties
> Chipp Walters wrote:
> > All that said, I imagine your client was using it in a fairly
> > unconventional way to see those kinds of file savings.
> Nothing more unconventional that displaying a list of records
> from a database.
> In plain tab-delimited form, the list itself is much smaller
> than the copy stored in the custom prop. Apparently the
> redundant copy of the data is being stored in the uniquely
> bloated htmlText format rather than the simple tab-delimited
> format the field itself uses.
> I don't know why the redundant copy is in htmlText, but then
> again I don't know why it's there at all....
> Richard Gaskin
> Fourth World Media Corporation
> [hidden email]http://www.FourthWorld.com > _______________________________________________
> use-revolution mailing list
> [hidden email] > Please visit this url to subscribe, unsubscribe and manage
> your subscription preferences: