One of the users on my network is can't start WHOS-IN 2000 because it is unable to load SHDOCVW.DLL: 
Someone reported this problem, and then solved it themselves in a VERY strange manner... By accident, the user managed to fix it herself by installing MS Internet Explorer version 5.5 !!!   Why this worked we are not quite sure, as WHOS-IN 2000 itself has no direct reference to this DLL. Since the initial error report (and fix) a couple of other people have had the same error, and installing IE5 also fixed it for them.

How do I substitute the Hudson Software logo background  with my own company logo?
Simple... All you need to do is create or modify your own company logo image (in GIF format) and copy it into the server WI2000 folder as 'logo.gif' (overwriting the default Hudson Software logo.gif file). The logo you create should not use dark colors (blue or black for example) and should have a 'watermark' appearance (soft 'washed out' colors) much like the existing Hudson Software logo.

Can I have the user.exe reside on the workstation instead of the server ? I don't want the server performance lowered by having all the users use the server's user.exe file.
The short answer is yes, you can do it, but you shouldn't if you can avoid it. If you absolutely must copy the USER.EXE file to the users local C: drive, there are a couple of things you need to consider...

When the USER.EXE program is on the server, it looks in the current folder for the file WI2000.INI, and then attempts to read the UNC path to the database. If the path is BLANK, then it expects to find the database in the same folder as the exe files.

What this means is that if you copy the USER.EXE file to the users local C: drive, then you must also copy the WI2000.INI file, AND the INI file MUST contain the UNC path to the database. If you don't copy the INI file, or it contains an invalid UNC path (or no path) the program will not run - because it will be unable to locate the WI2000.MDB (database) file.

You will also need to manually EDIT the users Icons, both on the DeskTop, and possibly also in their StartUp folder to point to the LOCAL copy of USER.EXE.

Something else you may need to think about is program updates... If you copy the EXE file to each PC, you will need to update each & every one of them when an update is available (making more work for yourself).

Ideally, you should leave the EXE files on the server, not only for update reasons, but also because the USER.EXE file itself is only around 500KB. All the 'large' files like the Access database engine & associated DLL's have already been copied to the users local C: drive during the WSSETUP procedure (and are loaded from the C: drive when the program starts). The only network traffic is the initial 500K of the EXE file, plus the actual data read from the database (which is minimal in comparison to the Access DLL's).

So... If you still want to do it, here's what you need to do...

1. Run the Admin program and select the TOOLS / DATABASE PATH menu item.
2. Enter a valid UNC path to the database (if there is not one already there)
3. Go to the users workstation & copy USER.EXE and WI2000.INI from the server into a folder on their C: drive.
4. Right-Click the WHOS-IN Icon (with the users name) on the users desktop and select PROPERTIES.
5. Edit the TARGET and START IN lines to point to the local copy of the exe file e.g. C:\WI2000\USER.EXE Greg Hudson
6. Repeat steps 4 & 5 for the icon residing in the users StartUp Folder (if it exists)

Why are some of the dates in the 'Last Modified' field displayed as dd/mm/yy and others appear as mm/dd/yy ?
Some of the users have not defined the 'International' settings in 'Control Panel' to the correct country. If you are in Australia, and the dates are displayed as mm/dd/yy, then Windows is set for the USA. (This is the default for Windows.) Change your Country Settings in Windows (Control Panel / International section) to cure the problem.

NOTE: As of the 31 Oct 2000 version, all dates are stored in yyyy-mm-dd format to allow sorting by date in the Last Modified column (which in turn eliminates the above problem).

I'm trying to repair the database, but the Repair utility tells me there is someone connected even though all users have logged off. Why does this happen ?
This isn't actually a WHOS-IN 2000 problem, it's a server problem (and seems to happen more with Novell than NT). The server normally keeps track of which users are logged on, and which applications they have open. If someone crashes their machine (or simply switches it off) the server is supposed to remove the user from its internal list, however sometimes this does not happen, and the server thinks the user is still connected to one or more programs. To help the WHOS-IN 2000 Administrator, the ADMIN program now displays a RED DOT next to the users that appear to be logged IN (even though they may have crashed their PC). If you 'know' all users have logged OUT, and yet there is still someone with a red dot next to their name, they are most likely the person you will need to disconnect from the server (see below).

To fix this problem (NOVELL) you need to log in to the server as administrator. (Using  LOAD MONITOR for Novell in this example). LOAD MONITOR allows you to see which applications are open by which users. From there, you can disconnect them by highlighting the user and hitting the DEL key. NOTE: Doing so will disconnect the user from ALL open applications, not just WHOS-IN. you need to log in to the server as administrator. (Using  LOAD MONITOR for Novell in this example). LOAD MONITOR allows you to see which applications are open by which users. From there, you can disconnect them by highlighting the user and hitting the DEL key. NOTE: Doing so will disconnect the user from ALL open applications, not just WHOS-IN. you need to log in to the server as administrator. (Using  LOAD MONITOR for Novell in this example). LOAD MONITOR allows you to see which applications are open by which users. From there, you can disconnect them by highlighting the user and hitting the DEL key. NOTE: Doing so will disconnect the user from ALL open applications, not just WHOS-IN 2000.

To fix this problem (WINDOWS NT) you need to log in to the server as administrator. (Using SERVER MONITOR for NT), and find which user has the WI2000.MDB file open, then disconnect the user. We do not however have the exact steps required. If anyone can supply this information, please help to update this page by e-mailing the info to us. Thanks.

I have one user who gets ''disk or network error'' when she tries to open Who's-In? 2000.   It will work after five or six tries.   Any suggestions?
This error can occur if the user has a notebook and is not connected to the network when they boot up (WHOS-IN 2000 is trying to connect to a database which ''isn't there''. The solution is to move the WHOS-IN 2000 shortcut from their STARTUP folder to the desktop, and ask the user to only log in to WHOS-IN 2000 when they are actually connected.

I have selected approximately 50 people from a Group, and hit the Mail button to create an email message, but only the first 20 or so names appear in the 'To' field of the message. What's happening?
This problem has been tracked down to a WIN NT Workstation BUG. If the total number of characters in the 'To' field exceeds 260, the remaining names in the list are truncated. This only appears to affect Windows NT Workstation, and does not appear to exist in Win 95, 98, ME or 2000. Full details of the bug are available at the following page:
http://support.microsoft.com/support/kb/articles/q269/2/72.asp

Known issues (Bugs yet to be fixed)

Although not strictly a WHOS-IN 2000 bug as such, (the problem below is actually caused by bugs in the Microsoft ListView control) the end result is something that 'appears' to be a WHOS-IN 2000 bug. We can reproduce the problem at will, but have been unable to find a resolution.

The problem lies with the drawing or 'painting' of the ListView during program loading. WHOS-IN 2000 saves the screen position, size, and ListView column widths into the database when it shuts down, and reloads those values when it restarts. If a combination of the form width and column width leaves the bottom scroll bar almost touching the right-hand edge, multiple copies of the text and grid are drawn on-screen.

Screen shot of problem area

At present, the only solution we know of is to 'refresh' the screen (by hitting the refresh button on the toolbar, minimizing & restoring, or moving the mouse around on the toolbar so that the tooltips are displayed - there may be others as well).

To prevent the problem, try to ensure that when you exit WI2000, the bottom scroll bar is either not visible, or not close to the right hand edge.

This is not a situation we are happy with, and we will continue to try to resolve the issue by whatever means possible. Microsoft has been informed of the bug, and hopefully it will be fixed in Visual Basic version 7 (VB Net).

As we receive more questions they will be appended to this page.