|| Frequently (and some infrequently) Asked
|| What does tech support cost?
| Tech support is free. Just call us at 1-919-481-0149. Or send an email to
Support@BurtonSys.com. (Don't be afraid to pester
us if you don't get a quick answer; we get a LOT of email, and try to assist customers
according to urgency.)
|| When I tried to run the 32-bit GUI version of TLIB, WTLIB32.EXE, I got
"Runtime error 50003, unexpected error." What caused this, and how can I fix it?
| This happens to some people when they try to run WTLIB32.EXE without first
running SETUP.EXE or NETSETUP.EXE. The solution is to run NETSETUP.EXE. (This will also create your
start menu shortcuts.) The error is due to having out-of-date or mismatched versions of Microsoft's
OCX and/or DLL files. TLIB 5.51a and later give a more informative error message. Run
NETSETUP.EXE, and the problem will go away.
|| Configuring TLIB's IF-ENDIF blocks to tell TLIB which files are Binary and
which are Text is a pain. Can't you make this automatic?
| TLIB 5.51a and later support configuring FILETYPE AUTOmatic.
|| Where's the TLIB Add-In for Visual Basic 6.0?
| In TLIB 5.51a (released 12-Aug-1999), and later.
|| I wish TLIB's compiler-native project file support worked with my
| Give us a call. If we can figure out how to parse your tool's project files, we
can probably add this support to TLIB. You'll have to help us out by providing us with a few sample
project files, and by testing it for us.
|| I'm running TLIB 5.04d, and I get a "Bad dot command" error for one of the
| If you're running TLIB 5.03/beta, or TLIB 5.04 prior to 5.04f, then there is a
situation in which a bug in TLIB can cause a bogus "Bad dot command" error to be reported. The bug
is fixed in 5.04f. The situation occurs when TLIB 5.03..5.04e is processing a text-format library
file created by an earlier version of TLIB, and in which some lines were terminated by LF alone
instead of CR+LF. The library is actually undamaged and works fine with TLIB 5.04f or
|| I just installed my upgrade to TLIB for Windows, and something has me
stumped. How can I change the current project level? When working in DOS, we had a DOS environment
variable referenced in the TLIB.CFG file, to set the named project level. However, in Windows you
can't change the environment variables after Windows starts, because every program gets a fresh
copy of the environment.
| The easiest solution, which is closest to what you are used to doing, is to just
to change a file instead of an environment variable. E.g., Instead of doing:
you could do:
ECHO SET PROJNAME=whatever >C:\FAKEENV.XYZ
Then, in TLIB.CFG, somewhere above your "PROJLEV %PROJNAME%" line, you would have a line like this:
More likely, you'll just make a .BAT file to build the C:\FAKEENV.XYZ file or to copy pre-built
files to C:\FAKEENV.XYZ, perhaps like this:
@REM - SETLEV.BAT
@rem (Assumes that your TLIB.CFG has an "include c:\fakeenv.xyz" line)
if '%1'=='' goto givehelp
if not exist \\theserver\sys\levls\%1\tlibwork.trk goto badlevl
echo SET PROJLEV=%1 >C:\FAKEENV.XYZ
echo Okay, your TLIB project level is now %1
echo Warning: \\theserver\sys\levls\%1\tlibwork.trk doesn't exist.
choice The reason may be that %1 is a bad project level name. Continue?
if errorlevel 3 goto badlevel
if errorlevel 2 goto xit
if errorlevel 1 goto doit
echo SETLEV levelname
Note, too, that TLIB 5.04 and 5.5x support extensive new configuration capabilities, which allow
you to evaluate string and arithmetic expressions, test for file existance or size, expand and
parse file and directory names, etc.. So, for example, you can easily use a directory naming
convention to set your project level.
Most users have just a single TLIB.CFG file in the TLIB install directory (the directory in which
TLIB*.EXE and TLIB*.DLL reside). The TLIB.CFG file can have special-case configuration stuff for a
particular project level or a particular user or whatever, as needed. See release.html
(or \tlib\doc\release.txt or \tlib\doc\release.wri) and \tlib\doc\config.txt (or \tlib\doc\config.wri).
|| What is the status column in the file picklist in TLIB for Windows?
| The status column in the file picklist displays the equivalent of a DOS
errorlevel returned after a TLIB operation, for each source file. In command-line versions of TLIB,
it is only possible to return one errorlevel, so command-line versions of TLIB return the highest
(most severe) errorlevel seen for any of the files processed. However, Windows GUI versions of TLIB
display the errorlevels for each file.
In general, an errorlevel status of 0 means that the operation succeeded, and an errorlevel status
of 1 or higher indicates that an error occurred. (Click "View Log" or "Run" to see the history.)
In 16-bit TLIB for Windows, you can wave your mouse cursor over the word "Status" and TLIB will
describe it in the "help bar" at the bottom of the main screen.
|| We have TLIB for Windows installed on a network drive and now all of us are
sharing the same TLIB.INI file. How can we set up individual TLIB.INI files?
| Older versions of TLIB for Windows, by default, used to store the TLIB.INI in
the TLIB installation directory. In multi-user TLIB installations it was necessary to set the
TLIBINI environment variable to tell TLIB where to store the TLIB.INI files (normally on each
user's private hard disk drive).
Starting with TLIB 5.50t (circa 19-Jan-98), the default location for TLIB.INI is now the root of
the C: drive, which is fine for most users.
TLIB for Windows recognizes the environment variable name TLIBINI to point to the directory where
the TLIB.INI file is located. TLIB for Windows will create and use a TLIB.INI file in the directory
In order to make this work under Win 3.1x or Win9x, you must set TLIBINI equal to a directory name
in your AUTOEXEC.BAT file. In NT 4.0 you can set or change environment variables via Start ->
Settings -> Control Panel -> System -> Environment. Win2000 is similar to NT 4.0, set the
environment variables via Start -> Settings -> Control Panel -> System -> Advanced
-> Environment Variables...
For example, the following line in a Win95 AUTOEXEC.BAT:
...would cause TLIB for Windows to create its TLIB.INI file in C:\MYSTUFF\.
If you already have preferences in your TLIB.INI file that you want to keep, you can copy it to the
directory you specify in your TLIBINI environment variable. You will need to set TLIBINI on each
machine that will be running TLIB for Windows from the network drive.
Note: The 16-bit and 32-bit versions of TLIB for Windows use the same TLIB.INI file, so you can use
them interchangably without losing your most-recently-used lists, etc..
|| I just used a co-worker's TLIB for Windows and it gave me their user ID. Why
didn't it get my ID from the network?
|There is an option under the File menu in TLIB for Windows called Change User ID.
If you select this option, you will get a pop-up window with a field for entering a user name, and
three different radio-button options with choices for how TLIB should determine the user ID. These
choices determine whether TLIB should override the user ID set by the ID parameter in your TLIB.CFG
file with the user ID you enter in the pop-up window's User Name field. The choices are
Never-override, Always-override, and Ask:
Never - With Never selected, TLIB will always use the user ID specified by the ID parameter in
TLIB.CFG. This choice will ignore the User Name field on the screen. If you have ID configured to
get a network login name (e.g., "ID *NOVELL*") then you will probably want to check Never.
Always - With Always selected, TLIB will always use the user ID specified in the User Name field in
the pop-up window. This behavior will ignore the ID parameter in your TLIB.CFG. It also saves the
value from the User Name field in your TLIB.INI file, and will continue to use it until you change
it again. Note that starting with TLIB 5.50t (circa 19-Jan-98), command- line (console mode)
versions of TLIB also check the TLIB.INI file for an "always" user ID override, so that the
"Always" choice will override your user ID for all versions of TLIB.
Ask - With Ask selected, TLIB for Windows will get the user ID from the ID configuration parameter
and compare it to the ID set in the User Name field. If they are different it will ask you which ID
you wish to use.
In TLIB 5.04h and later, the default setting is Ask. However, if TLIB seems to be ignoring your
configured ID parameter, it may be because Always-override has been selected in TLIB for Windows.
Note: if you want to disable this feature altogether, you may remove the "CW" command from the
COMMANDS list in TLIB.CFG.
|| Why won't the 32-bit versions of TLIB correctly look up my TLIB user ID from
my Novell Netware login name?
|This capability is in TLIB 5.51a (released 12-Aug-1999). Note: please also see
the previous Q&A, above.
|| I got an "Out of memory" error running TLIB.EXE. What can I do about
|You are probably running a DOS real-mode only version of TLIB. Try running
one of the protected mode TLIBs, such as TLIB32C.EXE (under Win9x/ME/NT/2K/XP),
TLIBX.EXE (under DOS), or TLIB2.EXE (under OS/2), or either the 32-bit or 16-bit GUI Windows TLIB.
Note: TLIB.EXE is just a copy of TLIB32C.EXE, TLIBDOS.EXE,
TLIB2.EXE, or TLIBX.EXE. Which one depends on the choices you made
when installing TLIB. So you might need to copy TLIB32C.EXE to
TLIB.EXE in the TLIB installation directory so that TLIB.EXE will
be the Win32 version.
|| Long file names work okay for me in the GUI version
of TLIB, but not when I run command-line TLIB. What's wrong?
|You are probably running a DOS real-mode only version of TLIB.
See the previous FAQ entry ("Out of memory").
|| How will TLIB Version Control help me meet the requirements of FDA regulation
21 CFR Part 11?
|| I tried to run Configuration Wizard or the 16-bit GUI TLIB, and got a GPF in
USER.EXE at 0001:6797. Why did it happen, and what can I do about it?
|This is apparently related to Novell Netware. It happens only with 16-bit Visual
Basic programs (like the 16-bit versions of TLIB for Windows), and only on Windows machines which
use Novell Netware. We've only seen this under Windows 2000, and do not know whether or not it can
happen under other versions of Windows.
We don't know the cause. However, most people can avoid or work
around the problem in any of three ways:
1) Run the 32-bit version of TLIB for Windows, instead of the 16-bit
version (of course, that won't help you for the Configuration
Wizard, which is only 16-bit); or,
2) Set the "run in separate memory space" option for the shortcuts
used to run 16-bit VB programs, including 16-bit TLIB and the TLIB
Configuration Wizard; or,
3) Shutdown and restart your computer (a temporary fix).
But for one person running version 4.80.20000717 of the Netware
Client, that wasn't sufficient. He had to:
4) Reboot and start the computer in "Workstation Only" mode
(selected at the Novell login screen). Typically, you would
do this just to run the TLIB Configuration Wizard. Then, after
you exit the Configuration Wizard, you can restart your computer
again and let the Novell Netware client load as usual.
|| We keep our TLIB library files on a network
drive, but different users have different drive letter mappings.
How can we make a "portable" tlib.cfg file, that doesn't depend
on the drive letter?
|Use UNC ("Universal Naming Convention") network paths in your TLIB.CFG file.
For example, instead of configuring:
level n=dev d=x:\tlibstuf\lvls\dev\ s=q a=y f=y
you can configure TLIB like this:
level n=dev d=\\ourserver\sys\tlibstuf\lvls\dev\ s=q a=y
The use of UNC paths in the TLIB.CFG file is a good idea if there
is a chance that all users might not use the same drive letter
There are some things for which TLIB requires a drive letter, but
they don't affect the TLIB.CFG file:
1) It is necessary to use a drive letter for the TLIB installation
directory, where TLIB's .EXE and .DLL files reside. But it needn't
be the same drive letter for every user, even if you install to a
network directory. When the additional users run NETSETUP to
create their shortcuts, etc., they can just path to it via whatever
drive letter they have mapped to that network drive on that machine.
2) The other place you need drive letter access is when you set the
"current directory" in TLIB's GUI. That is your "work directory"
and it would be somewhat odd to have a work directory that didn't
have a drive letter mapped for it. The reason TLIB requires a
drive letter for the current directory is that it actually does
a "chdir" (change directory) to make that the current directory,
and Windows requires that the current directory have a drive letter.
If, for some reason, you really, really don't want to use UNC paths,
it is still possible (though cumbersome) to make a portable TLIB.CFG
file using drive letters, by using TLIB's iff/endif and file test
operators, as in this example.
|| I cannot use *.* with my current TLIB
configuration. *.c or *.h works, but my list of extensions is growing
and this is becoming a problem. How can I fix this?
|The solution that would require minimum change/
work for you is to configure the "EXTENSION" parameter, perhaps to
something like this:
The problem is that TLIB needs a way to deduce the source file
extensions from the extensions of the library files. You have
TLIB configured "the old way" which is to substitute a "$" character
for the 2nd character of the source file extension to create the
extension for the corresponding library file. E.g., myfile.c
would have a TLIB library file called myfile.c$, and myfile.asm
would have a TLIB library file called myfile.a$m. The pattern
is determined by this portion of your TLIB.CFG file:
So, when TLIB uses its "L" (library files) wild-card expansion
("search mode") what it finds are files called myfile.c$ and
myfile.a$m. Then it needs to deduce the corresponding source file
names. If you specified a wildcard spec like *.c,*.asm then it
just uses the ".c" and the ".asm" from the wildcard spec. But if
you specified *.* then it can't deduce the 2nd character of the
source file's extension. So it consults the "EXTENSION" configuration
parameter, to see if there's an extension in the list that "makes
sense" as the corresponding source file extension.
But if you have TLIB configured without an EXTENSION parameter,
that also fails.
Another solution is to switch from "the old way" of naming library
files to "the new way." That's a very easy change to make in the
TLIB configuration file:
But then you'll need to rename all your TLIB library files,
something like this:
attrib -r *.?$*
ren *.c$ *.c_____$
ren *.h$ *.h_____$
ren *.a$m *.asm___$
ren *._$ *.______$
Also, if you have any lock files (because someone is working
on a file and has it checked-out and locked), then they should
also be renamed from *.?$* to something with "^" in the 7th
character of the extension rather than the 2nd character.
This change will render the EXTENSION parameter completely
unnecesssary unless you have source files with extensions that
are more than 5 characters long. So this solution is preferable
if your list if extensions is growing.
Note, though, that you should probably also add this to the end of
your configuration file:
This will ensure that TLIB's snapshots and special files don't get
tracked or locked if you store them in TLIB libraries.
|| For extra safety, I'd like TLIB to store a
plain text copy of each of my source files into a backup directory.
|If you are using TLIB's Named Project Levels (via
the PROJLEV and LEVEL configuration parameters), then this is very
easy. Just add "r=y" to each of your LEVEL configuration parameters,
and TLIB will store "reference copies" of your source files
in the project level reference directories whenever you do
If you are not using TLIB's Named Project Levels, you can
get this behavior by adding the following parameters to the end of
your TLIB.CFG file:
REM Create back-up copies on HDD of the last-updated versions of each file:
level n=bkuponly d=C:\TLIB_bak\ u=* e=* a=y r=y
REM Track even the snapshot files (so they'll get backed up in C:\TLIB_bak\)
REM but never track tlibwork.trk files that are stored into TLIB libraries:
|| I got an "ERR: rd4" message (perhaps when TLIB
for Windows was starting up). What does that mean?
|It means that TLIB was unable to read part of a text file
(perhaps tlib.cfg) which it had successfully opened and done an 'lseek'
on. The cause might be a malfunctioning
Encrypted Magic Folders program.
|| When I drag or resize the TLIB main window or Visual
Compare window, the movement is jumpy or sluggish or flashes.
|You need to disable "Show window contents while dragging."
In Windows Control Panel, double-click "Display." On the "Effects" tab,
uncheck "Show window contents while dragging." Click "OK."