>I'm also always telling people that arbitrarily grouping different things in a vcx is wrong. The point of programming is to make encapsulated little pieces which operate at runtime as separate entities. So why then aggregate them at design time? Instead of counter in utils.vcx, it would be better for a development team to have counter in counter.vcx. Then one developer could work on counter while another works on some other class. This aggregating of things, whether classes or udfs is really completely unnecessary and actually slows down development - because you must use source control or have developers waiting on each other.

And when grouped, you can't really remember the logic why was this class put into this lib, because over time the attitudes changed and now that class should belong to a different lib... which is the reason I use GoFish about 20 times more than I use the, say, PEM editor.

Historically, I think the reason for the grouping was the speed of directory searches. Fox is much older than NTFS, so it needed to be lighter on the use of file handles and directory searches (even folder searches, which came later and were the same... don't you love new names for old things?). Nowadays, it's the speed of remembering the class name - and with GoFish being as fast as it is, I don't really care how many rows are there in .pjx - 100 or 800. I only need to take care to name things so I'll find them by name next year. The reason for grouping is, IMO, gone.

Actually, there's one more good reason to avoid grouping: source control. Not only the wait until the other guy checks the lib in, but the table bloat, because with every change in one class, source control creates a copy of the unchanged 88 others. And if it does incremental saves - then it wastes time and cycles rebuilding the current version from history.