Hi Thomas,
>Hi Peter,
>>
>>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 ;-)

Hey, an English word I don't know yet: flippant! My dictionary says 'ongepast spotziek', 'te weinig ernstig', 'oneerbiedig'. Well, I don't know for sure how you meant it, but I stick to my definition of arrays: groups of variables, that's all. Not flippant meant at all. :)

>>>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.

PRIVATE ALL can be found at not a single spot in any of my applications. As a matter of fact, my idea of HIDE TABLES has all the time been to be meant LOCAL, as I tried to make clear in the comment behind the syntax:
- HIDE TABLES ALL | EXCEPT (skeleton) | EXCEPT (list) && always only local