Which CSIDL to use?

[NewsArchive]

Currently I use CSIDL_COMMON_DOCUMENTS for my data and ini files. I chose
that because of networking issues as I understand that is always available
across a network. That is now not relevant.

I am thinking of using APPDATA but not quite sure if I should use the
personal (user specific) one or not.

You see sometimes my clients share the machine with their wife say and their
wife might login under their user account. The client then comes along and
would not find their data. So I am inclined towards installing the data
independent of the user so presumably comon_appdata.

Would that make sense?

John

[NewsArchive]

John,

APPDATA is only for application specific data. For example, window
positions, user-specific configuration settings (e.g. INI files), license
data, etc. If you have a database to share (all users have access to the
same set of records) then you should use CSIDL_COMMON_DOCUMENTS.

True mixed-mode applications store per-user application (configuration) data
in the APPDATA folder, per-machine application data under the COMMON_APPDATA
folder and machine-wide databases under CSIDL_COMMON_DOCUMENTS.

Friedrich

[NewsArchive]

Thanks Friedrich. I knew I was doing it right <g>

Just out of interest - why is appdata split? Is that something I should
consider doing?

Currently I store ini settings in CSIDL_docs - just makes backing up and
support easier.

Thanks

John

[NewsArchive]

Hi John,

> Thanks Friedrich. I knew I was doing it right <g>

<g> :-)

> Just out of interest - why is appdata split? Is that something I should
> consider doing?

They "split" APPDATA because the non-local folder "travels" with the roaming
profile. Roaming data is copied to and from a server share location when a
user logs on/off if Roaming Profiles are enabled. A large roaming profile
can cause login speed issues so you should only store "small" configuration
files here (not large multi-megabyte databases).

Friedrich

[NewsArchive]

Thanks Friedrich - then I shall just continue as I was <g>

John

[NewsArchive]

Hello Friedrich,

>True mixed-mode applications store per-user application (configuration) data
>in the APPDATA folder,

The alternative is to store user-settings in (TPS-)table together with the data.


> per-machine application data under the COMMON_APPDATA
>folder and machine-wide databases under CSIDL_COMMON_DOCUMENTS.

SYSTEM{PROP:DataPath} with either a mapped drive like X: or an UNC-Path work
well, where ever those data then sit.

However, I have encountered that such UNC-path better does not contain a dot. A
dot is valid, but for what reason ever it does not work here.

Wolfgang

[NewsArchive]

The other settings to consider are for hardware connected to a
particular machine. I actually using the LOCAL_MACHINE tree in the
registry for this.

Mike Hanson
www.boxsoft.net

[NewsArchive]

Hi Wolfgang,

>>True mixed-mode applications store per-user application (configuration)
>>data in the APPDATA folder,
>
> The alternative is to store user-settings in (TPS-)table together with
> the data.

Yes, absolutely. You can store the account username along with all
preferences in a (global) TPS database to handle it. But it's not the
recommended method (because you have to keep track of new, changed, or
removed user accounts).

Real-life example: software company with 5 developers. On one computer with
SetupBuilder installed, all 5 developers have to compile the setups. The
projects and files are stored in a global repository. "JoeUser" logs in and
because SetupBuilder is a true mixed-mode application, all configuration
settings automatically belong to him (preferences, last opened projects,
etc.) when he starts SetupBuilder. After that, "MarrySmith" logs in to her
user account and she has completely different preferences and projects
(JoeUser is responsible for customers in the USA, MarrySmith handles
Spanish-speaking clients).

All per-user configuration settings are stored in a TPS file located under
the CSIDL_APPDATA tree.

Friedrich

[NewsArchive]

> Currently I use CSIDL_COMMON_DOCUMENTS for my data and ini files. I chose
> that because of networking issues as I understand that is always available
> across a network. That is now not relevant.
>
> I am thinking of using APPDATA but not quite sure if I should use the
> personal (user specific) one or not.
>
> You see sometimes my clients share the machine with their wife say and their
> wife might login under their user account. The client then comes along and
> would not find their data. So I am inclined towards installing the data
> independent of the user so presumably comon_appdata.

Hi John,

Even though your new tool will give you the option of client/server for
larger installs (so shared data files are not a concern there), the rules
for where to put data and INI files still apply.

Our ProPath help has a good section on what you options are, where they are
on the various OS's and what the implications of using each is:

http://www.clarionproseries.com/propathhelp/index.html?selectingacsidl.htm

For shared data and files I'd stay with COMMON_DOCUMENTS. For something
like an INI file that is machine specific I'd probably use one of the
APPDATA variants.


Good luck on your projects!

Charles



--
-------------------------------------------------------------------------------------------------------
Charles Edmonds
www.clarionproseries.com - ProScan, ProImage, ProPath and other Clarion
developer tools!
www.ezchangelog.com - "Free ChangeLog software to manage your projects!"
www.setupcast.com - "A revolutionary new publishing system for software
developers - enhanced for SetupBuilder users!"
www.pagesnip.com - "Print and Save the Web, just the way you want it!"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms - Now with PNG support!
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------