Sharing a custom spelling dictionary between applications

[superticker]

Is it even possible to share a custom.adu spelling dictionary between applications without creating write conflicts? For example, can Clipboard Help+Spell and The Forms Letter Machine share the same custom.adu dictionary?

On Windows 7, I've tried defining the file
  C:\Users\%USERNAME%\AppData\Roaming\custom.adu
for several different programs, but there seems to be some conflicts. Understand, some of these apps (e.g. Clipboard Help+Spell) remain open all the time, although I'm not sure its dictionary files remain "write open" all the time.

On a separate note, can a read-only language dictionary like american.adm be shared okay?  If so, where should the single copy be saved on Windows 7?

[superticker]

On Windows 7, I've tried defining the file
  C:\Users\%USERNAME%\AppData\Roaming\custom.adu

-superticker (August 09, 2013, 01:09 AM)

Well,... attempting to locate my custom dictionary, custom.adu, into my roaming profile (i.e. %APPDATA%\DonationCoder directory) fails altogether.  So are all custom dictionary files "hard coded" to be in the %ProgramFiles%\Clipboard Help+Spell\Dictionaries directory no matter what?

The main problem with this latter approach is that the "Standard User" doesn't have write access to files in that program directory on Windows 7 (or Vista) for security reasons.  Of course, the administrator can copy a user's custom dictionary into that directory, then give him full control (which is what I did).  Kind of weird though.  Why not just use the normal way and put the user data in the roaming profile (%APPDATA%) as expected?

Another problem is that one's custom dictionary won't roam between computers as expected.

The other problem is I don't backup the %ProgramFiles% directory (Why would I since the programs have to be reinstalled on recovery anyway?) so my custom dictionary won't be backuped by default.

Is there an advantage in using the %ProgramFiles% directory for user data that I don't know about?  Perhaps that approach might be more compatible with older (and less secure) OSes.  But even older programs often use %APPDATA% for their user data.

[mouser]

Sorry for the delayed reply!

Ok good questions.. You've basically found a problem with CHS spelling dictionary storage.  I'm going to try to fix it now so that they are stored in the same directory as the configuration settings are.  Stay tuned for beta version.

As for sharing custom dictionaries.. i don't know what potential problems it might cause, so let me do this in two steps, first having them at least read from the proper directory.

[mouser]

Mark, can you try:
https://www.donation...AndSpellPortable.zip
or https://www.donation...elpAndSpellSetup.exe

[superticker]

https://www.donation...AndSpellPortable.zip
or https://www.donation...elpAndSpellSetup.exe

-mouser (August 22, 2013, 03:27 PM)

I tried the second one, and it stores custom.adu in
%HOMEDRIVE%%HOMEPATH%\DonationCoder\Clipboard Help+Spell\Dictionaries\custom.adu

and that location appears to be hard coded. 

I was expecting to find it in the roaming data profile:
%APPDATA%\DonationCoder\Clipboard Help+Spell\custom.adu

but because it's hard coded into the %HOMEPATH%, I can't put it there.  But at least it's not in %ProgramFiles% anymore. That directory isn't part of my regular backup set, so I lost my original custom.adu file after a disk failure.

-----

On a totally separate note, someone suggested that desktop installs place data in the roaming data profile, %APPDATA%; whereas, portable app installs place it in the local data profile, %LOCALAPPDATA%.  Is this really true, and if so, why is this distinction made?  Why not place everything in say %LOCALAPPDATA%?

Is there a simple way to sync %APPDATA% (roaming) and %LOCALAPPDATA% (thumb drive) on Windows 7?  (Which forum should I be using for this question?)

[mouser]

for all of my programs, if you edit a file called ConfigDir.ini in the application directory, you can override the default configuration directory of any of my programs.  So if you want them somewhere else, just copy the sample ConfigDir and make a ConfigDir.ini with the config directory you want.

[superticker]

For all of my programs, if you edit a file called ConfigDir.ini in the application directory, you can override the default configuration directory of any of my programs.

-mouser (August 22, 2013, 04:56 PM)

I edited ConfigDir.ini so
  CONFIGDIR = %MYDOCUMENTS%

but I may change it to
  CONFIGDIR = %APPDATA%
later so my setting roam between different computers in my domain. At any rate, everything is working as it should. Thanks a bunch.

Let me know if it becomes possible to share the same custom.adu dictionary across applications. If it's not (say due to constant write locking), then has anyone setup file mirroring between several custom.adu files (say with synctoy.exe) so they automatically synchronize upon logging off?

[mouser]

If you want to experiment (and i emphasize "experiment") because i'm not sure this will work, try adding a line to your ConfigDir.ini that says:
DICTIONARYDIR = put_full_path_to_another_app_directory_containing_your_other_custom.adu

and then see if it shows up in your chs spell configuration list of dictionaries available.

[superticker]

If you want to "experiment" because I'm not sure this will work, try adding a line to your ConfigDir.ini that says:
DICTIONARYDIR = put_full_path_to_another_app_directory_containing_your_other_custom.adu

and then see if it shows up in your chs spell configuration list of dictionaries available.

-mouser (August 23, 2013, 01:17 AM)

I'm assuming DICTIONARYDIR is providing read-only access to third-party custom.adu files, correct? After all, if it write locks them, that will hang any third-party applications when they try to update their private copy of custom.adu. Of course, if a program only briefly write locked custom.adu, that may circumvent this problem.  After all, end-users wouldn't be updating several custom.adu spell dictionaries at once.

Can I specify several directories in DICTIONARYDIR separated by semicolons?

What we really need is a Windows dictionary service that provide "write arbitration" for dictionary resources across the OS, but writing a monitor for doing that is another problem. 

[mouser]

I just don't know enough about using multiple dictionary files to talk intelligently about them.
I use the Addict Spell Check library to manage all of the spelling stuff.  You can read more about it's use of multiple dictionaries here:
http://www.addictive.../ed-dictionaries.htm

So the DICTIONARYDIR variable i just added to the ConfigDir.ini tells the spell checker to look in this directory for additional dictionaries.  I think that means it should show them in the Spelling Options as "Additional Dictionaries" that are now available.

Now it may only make those available for read-access as additional dictionaries, and insist that the actually modifications be done in an exclusive dictionary file -- or it may let you then choose a dictionary in that directory to use as the one to add to, i'm just not sure.  And I also don't know if it locks it during changes -- but I would not be surprised if it does not lock it, and if it will let you share it and modify it and only lock it during short periods of changes.  But I don't know for sure.

I also don't know what other programs you might have that also use this dictionary format (while this library can READ the Microsoft Office dictionary, it will not modify it).

I will add support for specifying multiple ; separated directories with DICTIONARYDIR.  But you will still have to go to spell options in CHS to enable the dictionaries you want to use i believe.

[superticker]

I use the Addict Spell Check library to manage all of the spelling stuff.... more about it ... here:
http://www.addictive.../ed-dictionaries.htm

... it may only make those available for read-access as additional dictionaries, and insist that the actually modifications be done in an exclusive dictionary file -- or it may let you then choose a dictionary in that directory to use as the one to add to, I'm just not sure.

-mouser (August 23, 2013, 02:05 AM)

This is an issue of write-locking granularity. The file system only write locks with file-level granularity (all or nothing); whereas, the monitor system (like in a database) locks with record-level granularity. In this case, each word would be in a different database record.

If you don't write lock at some level (file level or record level), then one writer (which doesn't know about an earlier update by another writer) may replace the primary copy with its stale copy of the dictionary. So a writer must first close the file (or record) for read access, then open it again for write lock access (just before making a change) so it gets a fresh copy of the dictionary just before it writes. Now if it's doing this with file-level granularity, it should release that write lock immediately so it plays well with other apps that may want to write.

Databases and operating systems use the monitor approach (write locking at the resource [or record] level) so several independent processes can write lock (or allocate) resources (under monitor arbitration) at the same time.

I'm thinking the monitor approach is an overkill here because several apps (or process threads) wouldn't be wanting to write to custom.adu simultaneously on a personal computer. But if an apps doesn't play well and continually write locks custom.adu, then we have a problem.

I'm hoping apps would (1) close the read open custom.adu, (2) re-open custom.adu with a write lock thereby getting a fresh master copy of custom.adu from disk, (3) write the new word into it, (4) close the file to flush the new word (disk cluster) out to disk, (5) then re-open custom.adu again for reading.  But this is only a "hope". I really don't know how it works.

... this [dictionary program] can READ the Microsoft Office dictionary, [but] it will not modify it.

-mouser (August 23, 2013, 02:05 AM)

That's because Microsoft Office is using a dictionary monitor that addictivesoftware.com's dictionary program doesn't know about. They kind of have to do that because not all Windows users have MS Office installed. What would be nice is (1) for Microsoft to publish hooks into its dictionary monitor so third-party apps could write to it, and (2) addictivesoftware.com employed those hooks for write updating.

What would really be nice is if Microsoft simply included the dictionary monitor as part of a Windows service included in the OS so everyone had it (not just Office users). But I guess that would be reaching.