>Hey Dragan,
>
>>Speed is a minor issue here - alen() is only a few milliseconds slower than retrieving a value of a variable,
>>so calling it again doesn't cost much at all. Still, it's an old habit of mine - if it's a function, don't
>>call it twice if you don't have to.
>
>With the vast majority of the tasks in VFP being I/O bound in nature, I don't think
>that all of us should be that worried about calling a routine that "takes a bit of time."
>Specifically, I think we should all be concentrating on maximizing the efficiency of our
>queries, caching records in cursors and arrays, and wondering how our apps are going
>to respond when multiple users are accessing the same data. That would be time well
>spent, IMHO.
>
>Anywho, Dragan, keep doing things the way you're doing them, and I'd only worry about
>time considerations when warranted. That's the way I view all of this, anywho.(Shrug.)

Exactly - that's why I said it was a minor issue.

In my first year of professional coding, I came to my boss with an idea to speed something up. First thing he asked me was "where is it used"? The meaning was actually "how often does it run". His rule of thumb was - if it's stalling user input, do it right away and take whatever time it takes to do. If it's in a daily job, do it if they complain, if it's visibly slow, or if you can see how one hour of your work can save two hours of runtime over a month. If it's in a monthly job, do it if you really have nothing else to do.