whats stored in words memory & ini files

Hi ya

I have an .ini file which stores information.
The location of ini file is stored on local C drive of users.
Word - VBA accesses this file.

what I've noticed is if
The Word application is open
Word access's data from this ini file.
If I then go to explorer & change the contents of the ini file.
Word application is still open &
calls this ini file again - the data does not reflect the latest changes.

Only if I close & reopen the word application do the ini file changes appear/display.

Which makes me think that the ini file is already stored/loaded in words memory - therefore multiple calls or references to this file is unnecessary.
(is this right? - can someone please explain to me how this works)

If this is the case I'm wondering if it will work to solve a problem I have.

The problem is:

when users dial into the office to work from home etc or are interstate & want to access the home office.
The users dial in & they log onto the server.
Therefore the ini file is stored on the C drive of the server, therefore all users access the one ini file.

Depending on the current user thats dialed in, I want to change data (key values) in the ini file.

For example
user 1 is from Melbourne dials in - in ini file has key value set to 'Melbourne'.
user 2 is from Sydeny dials into Melbourne office - change ini file key value to 'Sydney'.

Will this work?
What are the consequences regarding file locking etc?
Has anyone had experience with something similiar - & if so how have you resolved.
all input welcome!
TIA Diana

Re: whats stored in words memory & ini files

Hi Diana,

A few thoughts, not particularly in any order:

If all of your users are sharing the data from the same .ini file, then you want that file to be read-only and you surely don't want the data in that file to change depending on which user is accessing it.

You need to find a way to store the users' localization data separate from the shared ini file, and then have code that grabs specific data from the ini file, depending on the user's location.

The user localization information can be stored in the Registry or perhaps in an .ini file that is specific to each user.

(I'm afraid I can't offer details on how to implement this suggestion!)

Re: whats stored in words memory & ini files

Hi Andrew,

Just to qualify your statement slightly: on certain types of network setups, the registry info doesn't reside on the machine, but rather can travel with the user.

The firm where I work uses Windows Terminal Server - in a setup like that there really isn't any 'local machine' as everything is stored on the server (eg their 'home directory', Normal.dot, registry data etc.) . A user can log on from anywhere in the world and all their profile info including registry data is right there - a big selling point for WTS.

Deployment is a weak area for me so I'm unsure whether the above is achievable with something other than WTS....

Re: whats stored in words memory & ini files

I use INI files rather than the Registry. I find them to be a better solution for my needs. There was a wave of "Ya Gotta Use The registry" a few years ago (not here, though), which I ignored.

> The location of ini file is stored on local C drive of users.

If the INI file is on the user's local drive C:, then the INI file (for the application) is local to the user; that is, it belongs to the user, and each user must have their own INI file. Is that correct?

> If I then go to explorer & change the contents of the ini file.

That is correct. If I want to make behind-the-scene changes while the application is active, I have to open, change, save AND CLOSE the INI file in Notepad or whatever.

> Which makes me think that the ini file is already stored/loaded in

I think of it this way: Word/VBA asks for a file, Windows gives it the file and its data, Word reads the data into RAM memory and makes use of it. The next time Word wants data from the file, and providing Word is going to open/read the file, Windows should give it the latest data, much as you would want. However, if Notepad is still open with the file, then the contents of NotePad's RAM memory (with updated data) have not yet been written back to disk, so they are not available for Windows to pass on to Word.

> multiple calls or references to this file is unnecessary.

I do make repeated calls to the INI file, once for each key/value I want.

If I have three keys, "User", "Location", "Time", I will make three calls to my routines to load the data. The first call, for "user" will probably read the entire INI file into RAM memory and give me the little bit of data that I want. The second call will not have to go to the hard drive, since the data is already in RAM memory, so that second access will be FAST, as will the third.

However, if the file contents have changed (Notepad Open, Close) then Windows will have to give me the refreshed copy of the data.

I hope this is making some sense. I know I'm simplifying and I THINK I've got the essentials down.

> therefore all users access the one ini file.

This is not bad, and it is doable, I think, with Notepad. I say "I Think" because I do not have two machines on a network here. If you ever want to experiment with this, you can do it very simply with NotePad accessing a single text file. Have two users side-by-side in your office and ONE file available to both of you. User1 opens and changes the file and closes it. User two opens/changes/closes not a problem. But then have User1 Open, change but NOT close; have User2 Open, change, close. Then have User1 Close. User2's changes will be "lost" because User1's changes overwrote User2's.

> What are the consequences regarding file locking etc?
> Has anyone had experience with something similiar - & if so how have

My little INI file routines or anything like that make their accesses very snappy, three lines of code:

<pre> Open
Read
Close
</pre>

Access to the file is reduced to a very small time.

In practice my INI file routines use an API call. I don't understand these, but I do understand that they work!:
<pre>Call apiPutPrivateProfileString(strSect, strKey, strValue, str)
</pre>

The benfit (to me) of using the API call is that i can very easily switch from using the text INI file to the Regsitry if a client requests it. I don't have to make changes throughout my code.

I have posted the code for my two INI file routines right here in the VB/VBA forum. Look for "strGP" and "strPP".

When all the discussion has settled down, let me knowe if you'ld like a "kit" to play with. I can email to you a simple template with just the INI routines in them.

I hope this helps. You have a lot of information through which to wade.

Re: whats stored in words memory & ini files

Gary

Does that mean that your entire profile is held on the server and must be downloaded everytime you log on. My NT4 box says my profile is now 17Mb in size. I have no idea how it got that big but getting hold of that much data every time I log on via a phone line doesn't sound like my idea of fun.

I think Diana is actually trying to do something the network administrator should be logging anyway. Maybe she is the network administrator but I suspect the task is better suited to network administration type tools rather than roll-your own VBA.

Re: whats stored in words memory & ini files

Besides the WTS secenario, a LAN setup with what Windows refers to as "Roaming" User Profiles, the user's reg data is copied to the registry with every log on. (And changes are copied back on log off.) The filename for this data is user.dat (Win9x) and ntuser.dat (Winnt and 2000). That's the HKEY_CURRENT_USER hive. There are other things in there too. And not only that, but everything stored in the folder referenced by the User Manager setting "User Profile Path" gets copied to the lcoal C: drive under c:windowsprofilesusername (Win98) and c:documents and datausername (win2000). To go on would necessitate moving this post to another forum. Suffice it to say that a 17MB ntuser.dat file or even a 17MB user profile (which includes all files in the above referenced folder) is pretty big. Must slow down your log on somewhat. If you want to know how to fix that, let me know and I'll post to a Winxxxx forum.

But for Diana: (you were hoping I'd get back on topic, right?) If those users have Roaming user profiles enabled, the reg data is on the server. In fact, if the .ini file is in the user profile folder, it is copied back to the server when the user logs off. The question is how to easily get at it for whatever reporting needs to be done. Ha! Good luck if you want to get it out of the registry. If you can access user home folders (usually only Admins can do this), you can easily get the data from the .ini files.

Re: whats stored in words memory & ini files

To further elaborate, only system administrators or domain administrators who are logged on as such can even see other users' profiles and registry hives. Actually roaming profiles are stored on the server and on any machine where the user logs in, which is why stray profiles need to be cleaned out periodically.

Re: whats stored in words memory & ini files

Andrew

I'm a developer & the network admin guys bought to my attention a problem that is occuring when users from a different branch are dialling into another branch office & accessing the same templates(network).

We were brainstorming to come up with workable soultions.
The orginial solution I thought that might resolve isnt going to work - as its dangerous writing to a shareable file that all the users will access when dialling in & logging via Citrix server.

Kevin
The ini file is stored on all users C drive(each pc).
However when users dialling in via Citrix server, the users have their profiles, but are essentionally working on the 1 pc, the 'phantom C drive' on the citrix box.
Therefore are all accessing the files & templates(the properties being not read-only)
And therein lies the 1 of the problems.

Having given it futher thought,& it looks like the solution may be having to write code in the global templates.
I didnt want to write code as I wanted a solution/control from a network aspect, instead of each time there was a change code will have to be amended to reflect.

Kevin your've given me another idea by using users home dir to store the files.
However I will still have to amend code to point to the files in the correct locations.

also
you mentioned I needed 'Luck' to get info out of the registry. Whys that?
I thought it was easy to retrieve info from registry.
We are currently obtaining certain information from the registry.

However somebody in the company is really pushing to migrate & store data (data thats currently stored in the ini files) in the registry.
Which is fine by me - just some more work -

however Chris mentioned earlier that
"There was a wave of "Ya Gotta User the registry" a few years ago
& I cant help but think thats the mindset this persons on.

I'm inclined to leave in ini files because - hey it works.
And I dont really know the adv & disadvantages of storing & reading info from registry.
Does anyone know? - or is there some info you can point me to?

Re: whats stored in words memory & ini files

Andrew

I'm a developer & the network admin guys bought to my attention a problem that is occuring when users from a different branch are dialling into another branch office & accessing the same templates(network).

We were brainstorming to come up with workable soultions.
The orginial solution I thought that might resolve isnt going to work - as its dangerous writing to a shareable file that all the users will access when dialling in & logging via Citrix server.

Kevin
The ini file is stored on all users C drive(each pc).
However when users dialling in via Citrix server, the users have their profiles, but are essentionally working on the 1 pc, the 'phantom C drive' on the citrix box.
Therefore are all accessing the files & templates(the properties being not read-only)
And therein lies the 1 of the problems.

Having given it futher thought,& it looks like the solution may be having to write code in the global templates.
I didnt want to write code as I wanted a solution/control from a network aspect, instead of each time there was a change code will have to be amended to reflect.

Kevin your've given me another idea by using users home dir to store the files.
However I will still have to amend code to point to the files in the correct locations.

also
you mentioned I needed 'Luck' to get info out of the registry. Whys that?
I thought it was easy to retrieve info from registry.
We are currently obtaining certain information from the registry.

However somebody in the company is really pushing to migrate & store data (data thats currently stored in the ini files) in the registry.
Which is fine by me - just some more work -

however Chris mentioned earlier that
"There was a wave of "Ya Gotta User the registry" a few years ago
& I cant help but think thats the mindset this persons on.

I'm inclined to leave in ini files because - hey it works.
And I dont really know the adv & disadvantages of storing & reading info from registry.
Does anyone know? - or is there some info you can point me to?

To allow different INI files for different users on the same machine, use the command line to specify the specific INI file path and file name. Add a check to see if
the INI file exists, and if it doesn't, create it. A different icon specifying a different INI file on the command line can be set up for each user:
<pre> Sub Form_Click ()
Dim achIniFile As String
Dim Msg As String
If Command = "" Then ' If no command line.
achIniFile = App.Path & "DEFAULT.INI"
' There is currently no command-line string.
Msg = "The INI file used is: '" & Command$ & "'"
Else ' Put command line into message.
achIniFile = App.Path & "" & Command$
Msg = "The INI file used is: '" & Command$ & "'"
End If
MsgBox Msg ' Display message.
End Sub
</pre>

Re: whats stored in words memory & ini files

>However somebody in the company is really pushing to ... the registry.

> Chris mentioned "There was a wave of "Ya Gotta User the registry"
> I'm inclined to leave in ini files because - hey it works.

I feel that when the Registry first came out MSoft touted it, but it was really a neat place to hide stuff - it gets so big that noone is going to search for the key that tells you're shareware appliaction that time is up and you should send money.

I think MSoft also thought that if a file was on a computer and users didn't know how to edit it, that it wouldn't get damaged. Hah!

My leaning towards INI files is based on two main ideas.

1) Like you - I see that they WORK!

2) I distribute little applications in Word. I like to tell people that if they install them in a separate directory, de-installation is just a matter of deleting that directory.

Bonuses include the fact that most users *aren't* dolts, and can be asked to inspect the contents of an INI file by telephone, even use Notepad to edit it. Saves us all time and money.

And I write my apps so that they will re-create INI file if it disappears, rather like Word's Normal.dot.

In short (yeah, right!) I haven't found a good reason for me to move to the registry yet. That doesn't mean that there isn't a good reason. Just that I haven't found it.