A problem with clearing fields on marked cards

[Kay C Lan]

Craig,

Agreed, which is why I pointed out that some methods were not foolproof. My
main aim was to point out that there were alternative ways to skin the cat.
Depending on your needs one will probably be better than another.

I guess clean is in the eye of the beholder. And as for onerous, I've
generally discovered that taking the easy option at the beginning ALWAYS
comes and bites me down the road; typically in speed.

Personally, going to the trouble of layering all input fields together at
the beginning so I can do:

repeat with x = 1 to 100
 put empty into field x
end repeat

appears cleaner to me than:

repeat with x = 1 to the number of fields
  if the cIsLabel of field x = false then
     put empty into field x
  end if
end repeat

Also, logical it must take longer to execute as there will be at least twice
as many iterations of the repeat cycle, but lets not use logic, lets check
the numbers:-)

The below results are from a card with 100 normal fields (to be cleared,
cIsLabel = false, lockText = false), + 10 normal fields whose lockText is
true (not to be cleared, cIsLabel = true, lockText = true) and 100 label
fields (not to be cleared, cIsLabel = true, lockText = true).

The result are for 1000 repeats of clearing the 100 normal fields only:

Layer: Min = 1ms, Max = 2ms, Avg = 1ms for 100 iterations.

cLabel: Min = 5ms,  Max = 6ms, Avg = 5ms for 210 iterations.

lockText: Min = 2ms,  Max = 4ms, Avg = 3ms for 210 iterations.

Content: Min = 3ms, Max = 4ms, Avg = 3ms for 210 iterations.


Note the results are significantly slower if you don't 'lock screen'!


Most of this Richard has told us before;


Fastest - layer the objects so you can use repeat with the exact number of
objects.

Fast - if you must step through every object, if possible use an inbuilt
property to perform the validity test.

Slow - custom properties are slower than in built properties.

Slowest - We all know accessing the content of a field is slow, but I'm
surprised at how quick it can be, but I also discovered the results can be
hugely effected by the size of the content and the type of test performed to
determine if it needs to be cleared or not - I used what appeared to be the
fasted, not much content and a simple = test.


HTH

On Tue, Jun 8, 2010 at 9:38 PM, <DunbarX at aol.com> wrote:

> The properties mentioned are not intrinsic to label fields, they are just
> defaults at creation, and may be common to other fields. Certainly
> sharedText
> and lockText could be. All the other suggestions are valid as far as they
> go, naming, numbering, layering, etc., but these may not be convenient, or
> constant, and may be tedious to manage down the road. In other words, they
> may
> not go very far.
>
> Naming them with a unique beginning string is pretty robust, I guess; I've
> done that. But I still think that creating a custom property is the
> cleanest
> way. It isn't so onerous, after all.
>
> Craig Newman
> _______________________________________________
> 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
>