>
This actually gets me worried. I start sounding like a professor again :).>
>< g >Probably not a bad thing.
I'm actually getting a Pavlov's reflex here (named after the guy who had so good reflexes... you know, the dog rings a bell and his knee-jerk reflex is to feed the dog) - whenever I start sounding like this, our youngest daughter starts making faces and rapidly cuts her attention span, so I'm always on guard trying to catch myself in time :)
>When I started working in FoxBASE+, I had a awful time because I followed what examples I had. More and more I became convinced that what I had been told was correct. Then, I had a realization. What I had been taught was correct. What I had been taught was designed to work in the
real world. It had just been improperly implemented.
>
>Once that sunk in, I became more productive. More often than not, people designed to the exceptions rather than the rules. In doing so, they got things backwards, because design has to be to the rules, and the exceptions have to be handled.
>
>Such it is here. Taking advantage of an undocumented feature goes against the rules. You don't know when or if the feature will change.
Regarding indexes, I remember the reindex
causing bloat in 1.02 and maybe 2.0, but can't really be sure about 2.0 because I already wrote a generator for indexs.prg by that time, which actually killed off the cdx files and created them from scratch, just in case, and not primarily to remove the bloat, but rather to make sure a screwed-up tag header won't stop the routine from opening the table.
I do agree with this attitude regarding workarounds. More ofen than we dare confess we develop a pattern the main purpose of which is to circumvent some shortcoming of the current technology. When the time comes to move to a new technology, it's time to rethink the thing: do we really have a problem implementing this old technique in the new version, or is it a problem that we don't really need the technique anymore?
One example was the print into text files I used in DOS days, because machines were slow and some reports took quite a time to run, so their results stayed on disk and could be viewed, printed as many times you want, and even partially printed (yup, I was analysing the textfile, counting formfeeds etc).
Can't do that with reports which go to a laser or a spitter (pet name for inkjets). How did I solve this? I didn't - today's machines are fast enough, you get to view the report properly from within Fox, and the whole thing is unnecessary. Goodbye to printing to txt files.