Hi Peter,

>>Nowadays I interpret array's mostly as something between objects and cursors:
>>Perhaps the data you want to be hidden might better be put into an array ?
>>Moving from and to cursors is still ***very*** fast.
>
>I interpret an array simply as a group of variables.
If you work on large frameworks, I find it helpful to pick the construction with the least "payload" measured in internal resources. The vfp cursor is a wonderful thing, but sometimes is used where not really necessary. Consider cbo's and listboxes: always creating a cursor as a rowsource is rather wasteful. Doesn't matter in an app with 3 pageframes an perhaps 5 to 10 cursorbound controls. But in an app having potentially 50 to 60 rowsource based controls to be handled in each business case in its own data session ?

Or the framework approach of replacing screen texts through a table or getting info at runtime out of the dbc: vfp makes such techniques possible, because it is so darned fast. But to be honest, such things should perhaps be table based for later changes, but either precompiled into the app or generated into objects for faster loading times.

Using the different possibilities of each structure is one necessary not to build apps overusing their resources: something that really can cripple the fox. As fast as the fox can be, mistreat him, and then the result (performance hit) is ***worse*** than in other languages.

But I guess you were just a bit flippant up there and know this already ;-)

>>My "bad feeling" is stronger if you want to hide tables in a private-like
>>manner - ie:.
>>>- HIDE TABLES ALL | EXCEPT (skeleton) | EXCEPT (list) && always only local
>>>- PARAMETERS( TABLE LocalAlias, VARIABLE LocalVar ) && deleted the "L" from parameters!!!
>>
>>Making a table visible "local" through the current proc
>>should be harmless. But hiding from that point on "upward" in the stack
>>might introduce problems in library functions, and also in asynchrone
>>callbacks.
>
>Hiding upward in the stack might indeed introduce problems, but that is/was also true for local variables. Whenever the developer decides ( in vfp10 :) to make table such-and-so local, he'll also have to check what the consequences of the change are with respect to other routines. BTW, I think that library routines should be robust on this aspect too.
>
I don't have a problem with local.
It is the "privatizing" (especially with ***ALL***) I am against.
Here the library function disrupts the possibility of callbacks
and sometimes calling of "normal functions.

my 0.02 EUR

thomas