General ⇒ How to deal with multiple TeXnicCenter installations

[ego533]

Our organization has several labs and offices where a particular person may sit down to use TeX. A person's account follows them to any computer they use (roaming profiles, redirected folders, network mounts). All of the computers use Texnic Center, but do not use the same TeX package.

So, say a person uses their office computer with Miktex. They are automatically assigned output profiles to match Miktex (LaTeX - >PDF, LaTeX - >DVI, LaTeX - >PS). If they move to a lab with TeXLive, now those output profiles do not work. When they log in, their account is loaded which brings in the Texnic Center output profiles created on their office computer.

Is there a way to set machine-based output profiles that override users' output profiles or profiles that are added to their list in addition to their personal output profiles? There are other solutions like scripts, but I'm trying to avoid unnecessary customization to have to document..

[localghost]

You could create copies of the build profiles which work with MiKTeX and adapt them to TeX Live. This should be no major problem since only the paths to the required executables have to be adapted. The new profiles could be named like "LaTeX => PDF (TeX Live)". Afterwards you could save these profiles by exporting them to a file and so make them available for a later installation.


Best regards and welcome to the board
Thorsten¹

[ego533]

The profiles don't quite adapt. It seems that the only problem other than the file paths is the forward search for the DVI profile which has to be changed to [ -1 "%bm.dvi" "# %l/%s '%bm.tex'" ] for TeXLive.

I was hoping to have the solution require no work on the user's side. They would have to know to use the different profiles, but not to load a file or create new profiles.

Thanks for the reply!

[T3.]

The profiles don't quite adapt. It seems that the only problem other than the file paths is the forward search for the DVI profile which has to be changed to [ -1 "%bm.dvi" "# %l/%s '%bm.tex'" ] for TeXLive.

I was hoping to have the solution require no work on the user's side. They would have to know to use the different profiles, but not to load a file or create new profiles.

My quick poking around shows that TeXnicCenter stores profiles in the registry (yuck!) under:

Code: Select all

HKEY_CURRENT_USER\Software\ToolsCenter\TeXnicCenter\Profiles

Unfortunately, TeXnicCenter seems to check only HKCU hive for profile settings so putting those entries under HKLM has no effect (I've just checked that).

You would need to figure out some way to augment user settings in HKCU (without making those changes permanent) but I don't how to do it or even if it's possible at all.

Note also that the problem is not only in dvi previewer. If some users will customize their TeXnicCenter profiles for MiKTeX, they may fail under TeXLive, as binaries in those two distributions support different set of program switches, e.g. '-enable-write18' in MiKTeX and '-shell-escape' in TeXLive (MiKTeX supports it as well, although it's not documented).

Cheers,

Tomek

[BJ_FIVD]

Import the registry-settings in your logon-script, dependant on which PC you are using.

[ego533]

Aye, that is what I did to solve it initially (and for now). It is very dirty, however.

Our situation means that many computers cannot be controlled directly by active directory so the script is local and cannot be changed on all computers easily. Others have the script read from a universal read-only network share, but this has to be documented carefully since it is unintuitive.

To further complicate it, the registry entries that Texnic center uses are strings with 'invalid' characters. You'll notice that several of the entries (DDECmd) use a string delimiter of '0A'. This CANNOT be specified in an imported .reg file. It is simply an invalid character for a string. The solution was to specify the string by hex values. So, the line for the DDECmd string is,

Code: Select all

"DDECmd"=hex(2):0A,00,53,00,79,00,73,00,74,00,65,00,6D,00,0A,00,0A,00

Completely doable, but less than easy. If this ever changes again, I have to go back and re-hexify all of the delimited string entries.

Some users do customize their profiles, also, so I cannot just overwrite the build profiles every time a person logs in. To overcome this, I created a user environment variable called something like "userhastexlive2007", "userhasmiktek26", "userhasmiktek27" that the script adds once it creates the profiles for that TeX the first time. On subsequent logins, the script checks for this and will not import the registry entries if the variable exists.

[ego533]

   I have realized a different solution. It is still not perfect, but can be better than what I have described above for some people.

   In the build profiles, fill the 'executable path' with only the filename. For instance, "Path to (La)TeX compiler" will only be "latex.exe" and not "C:\Program Files (x86)\MikTeX\miktex\bin\latex.exe". Do this for ALL paths including the viewers and the postprocessors.
   Now, modify the system PATH environment variable to include the directory path where each of these executables are located. Restart the computer so the variable takes effect.

   The profiles are now machine-based, dependent upon the system's PATH variable. If the Adobe Reader, ghostscript, etc.. version changes, the directory will change. A user or administrator will just have to remember this. This also still doesn't account for switch changes in the command line for different TeX systems or for TeX systems that don't use standard executable names (latex.exe, dvips.exe, ...). It seems that most TeX systems use or recognize the same arguments. The profiles can still be customized in most ways without consequences.
   An added con in this solution is that the forward/backward searches may no longer work. If two computers have different viewers that require different search strings, the strings are not overwritten with the correct entry, as is done with the registry solution.

 

[ego533]

   There is another way to deal with the executable names and the different search strings. Windows batch files can be used as an intermediary.
   I believe this solves all problems except two. The profiles' command-line arguments can no longer be customized easily. A DOS window pops up for a fraction of a second when any command runs.

   The Texnic Center build profile may refer to batch files such as dviviewer.bat, latex.bat. The batch files on the particular machine will refer to the correct files on that machine. Arguments can be created and passed appropriately. The command line arguments are only the needed variables, not the actual arguments for any TeX system. The batch file structures the arguments correctly for TeX on that system.
   Some of the variables in the command arguments will have to be altered to provide an extension, such as "%bm.ps" instead of the default "%bm"

   For instance, for the DVI viewer:
   TeXLive uses DVIout.exe, Miktex uses yap.exe. The build profile specifies the path to the DVI viewer executable is "dviviewer.bat". The command line argument for forward search is < %l "%Wc" "%bm" %sWc %sbm "%bm.dvi" %s >. That's an L not a number 1. I threw in several variables that may be used in the future. The .bat file for Miktex contains < start C:\program~1\miktex\miktex\bin\yap.exe -1 -s %1%2 %3 >. Those are both number 1's. The .bat file for TeXLive is < start C:\progra~1\texlive\bin\win32\dviout.exe -1 %6 "# %1/%7 '%5.tex'" >. Both number 1's again. The bat files are placed in the TeX system's 'bin' folder.
   Now, the same build profile will open the dvi viewer regardless of whether the person is using TeXLive or Miktex.
   The %1 and so forth are variables that refer to command line arguments that a batch file is called with. In this example %1=%l %2=%sWc %3=%sbm %4=%s.
   The 'start' command in the batch file is a way to avoid the DOS window from staying up while the view runs. ONLY USE the 'start' command in batch files that run GUI programs. latex.exe, pdlatex.exe and so on should not be run with the start command. Their arguments are interfered with otherwise.

   Both this and the PATH solution above can also be used to solve "Program Files"/"Program Files (x86)" problems in Windows.