>>>>>OK, I'm hitting a wall here, and I don't know how to get around it...even though it seems that everyone else knows how to scale it!!!
>>>>>
>>>>>HOW THE !@## DO YOU GET YOUR APP TO SAVE THE POSITION AND SIZE WHEN THE USER EXITS THE PROGRAM?!?!?!
>>>>>
>>>>>I've got RESOURCE ON in my prog that calls my forms and stuff, my foxuser.dbf is in the proper place...HOW DO I USE IT??? Am I totally missing something here? ARGH!
>>>>>
>>>>>So to recap from my rantings: I need to have my apps remember the state in which they were exited (window state, position, etc.)...for some reason I thought that this was implicite by setting RESOURCE ON, but I guess not. Any help would be appreciated:) (happy friday:))
>>>>
>>>>Nice idea - but no.
>>>>VFP won't save window positions automatically on exiting your application. You'll have to record this info somewhere (registry or .INI file) when your application terminates, then on startup, recover the info and re-set the postions.
>>>
>>>What the?!?!? really? damn, I thought that was the reason for using the stupid foxuser.??? files...argh...well can you explain the best way about using a .ini file like you suggest?
>>>
>>>Thanks for the reply:)
>>
>>There is another option. Use a DBF to hold all the data and write routines to store, retrieve and apply it to the forms. This is the method I personally prefer, but others prefer the Registry method. I would think that fewer would use INI files today since they are out of vogue. I have used then and still do for some small purposes. Interestingly I have a COM server on a web server that I'm using XML to store the init data, mostly as a chance to learn something about XML, but it works ok.
>>
>
>The choice of where to store the data isn't terrifically important - DBF, INI, Registry, all work. it's a matter of what is being saved, and who it's being saved for.
>
>There are at least two sets of 'things' that have settings that a VFP app needs to pay attention to. these things are (1) the user, and (2) the workstation. the two may vary independently of each other.
>
>The following is opinion, and probably is stomping on someone else's toes, but I'll give it a shot IAC.
>
>DBFs, especially shared central DBFs, offer the best platform-independent mechanism for saving user preferences. My arguments for this are:
>
>(1) Unless you're using something like NT Server that can maintain roaming hives, the Registry is a local resource. Even if multiple users have accoutns on a given machine (and user profiles are enabled), and you take a positive step to save the information in a registry key subordinate to HKEY_CURRENT_USER (or in a .INI file, have a section per userid), the registry/ini file is local to the workstation - IOW, if John logs on on station 1 and saves his preferences to the registry there, unless you've got roaming hives that follow the user at logon, he can't see the chagnes to the registry on Station 2 when he logs on there later in the day.)
>
>(2) The settings for a user are generally active after the app has been brought to the screen; the user has logged on, and so the shared resource point should already be pointed to by the application.
>
>Worksation-specific stuff can and should probably be in the registry or a local configuration file, for a couple of reasons:
>
>(1) To at least some extent, it doesn't matter who is logged into the app. What drive the temp files should be on, the normal screen resolution, and default printer (this one isn't hard and fast) should be pretty much the same no matter who is on the system. The physical resources of the machine are pretty constant.
>
>(2) Some system-specific settings need to be local to the application prior to the app being started; in my case, where I use a launcher application that's fairly generic, I don't know where the shared files are going to be before some basic startup has occurred. A registry key built beneath HKEY_LOCAL_MACHINE something that I know how to look for, that is file-system independent, and works without the app knowing where to find stuff on the network, and that if I don't find it, is a clear indication that my common setup hasn't been run here (at least not since the last time the registry got blown up and the operating system had to be reinstalled!)
>
>< Ducking for cover behind a nearby rock >

No problem with me Ed. :-) There's ( as usual ) more than one way to accomplish this kind of task. Certainly some methods can be better than others, but a particular method must be evaluated for the given scenario as you more or less implied above. I have used several methods to store data of this type depending on the scenario including INI's, Registry, DBF's and XML files. I have a tendency to be a "black and white" thinking type so I am trying to learn to consider the options and not just say "this is the way to do it every time". :-)