WHOS-IN Pro Support

This is the presence sensing feature (pictured above) in action. If a users screensaver is triggered, the Icon on the main display area will change from the standard colored button to a small 'screen' icon. If a users PC is 'locked' a lock icon will appear.
NOTE: The Icons changing do NOT change a users Status. When the user returns and moves the mouse / keyboard, the Icon (only) will revert back to its previous (colored) state.

Screen 'redraw' / blurry screen problem:
Applies to: WHOS-IN Pro, 2003, 2002, & 2000.
This problem below is caused by bugs in the Microsoft ListView control. 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 control. WHOS-IN saves the screen position, size, and ListView column widths into the database when it shuts down (or when you hit the Refresh Button), 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 can be drawn on-screen (although this does not seem to happen 'every' time)...

Screen shot of problem area in WHOS-IN 2000, however the same problem can appear in WHOS-IN 2002, 2003 & WHOS-IN Pro because Microsoft have ignored reports of the bug in the control.

At present, the only solutions we know of are to resize a column, then '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 WHOS-IN, the bottom scroll bar is either not visible, or not close to the right hand edge.

After checking the Microsoft site for this error, we found the following info:
''You may receive this error message may when you attempt to use Microsoft Visual Basic code to access the Data Base Engine version.''   CAUSE   This issue can occur when DAO dynamic-link library (DLL) files are mismatched or when there are incorrect registry entries.

Assuming you are using XP on your PC's, you should be able to correct this
problem by copying the DAO360.DLL file from:
http://www.hudsoft.com/products/whosin/support-files.html
to your server WHOS-IN folder.   You MAY need to manually register the DLL. If so, follow the instructions on the above page.

Network Script Problem:
Some sites have reported that their login script 'hangs' when the WHOS-IN user.exe file executes. This problem has now been solved by a user... If you experience this problem, please modify the WHOS-IN entry in your login script from:
\\YourServer\YourShare\YourPathToWhosIn\USER.EXE -UID:%USERNAME%
to:
START \\YourServer\YourShare\YourPathToWhosIn\USER.EXE -UID:%USERNAME%

(Ensure there is a SPACE between START and the double backslash)

NOTE: You may need to modify the above script example to suit your particular server installation.

The 'start' command calls the program outside of the batch script, therefore allowing the script to continue to the next line.

MSFLXGRD.OCX problem:

The Microsoft Flex Grid has been added to WHOS-IN 2003 & higher, and in some cases MAY need to be manually 'registered' if it has not been used previously. If so, please perform the following:
From the users PC, Select the START / RUN command, and enter:
REGSVR32 \\yourserver\yourshare\yourpath\MSFLXGRD.OCX where \\yourserver\yourshare\yourpath is the path to the WHOS-IN folder on the server. (Use REGSVR if REGSVR32 does not exist on the users PC)

Some sites have reported that one or more users may receive the following error when attempting to run WHOS-IN.
''Failed to load control 'CommonDialog' from COMDLG32.OCX. Your version of COMDLG32.OCX may be outdated. Make sure you are using the version of the control that was supplied with your application.''

This problem appears to be 'permission' related (the OCX is included with WHOS-IN as one of the 'core' files, and should always reside in the server WHOS-IN folder). To fix the problem, you need to log on to the PC in question as an ADMINISTRATOR, then run WHOS-IN. This will 'self-register' the OCX so that the 'normal' access user can use it. Log back on as the normal access user, and the problem should be solved. If not, please try the following:
From the users PC, Select the START / RUN command, and enter:
REGSVR32 \\yourserver\yourshare\yourpath\COMDLG32.OCX where \\yourserver\yourshare\yourpath\ is the path to the WHOS-IN folder on the server.

XP Service Pack 1 causes error &H8007007E:

The above error was discovered by a user, who performed the following tests...

1. If you have a machine with XP, then you install Service Pack 1, then you install WHOS-IN - Everything works OK.
2. If you have a machine with XP, then you install WHOS-IN, then you install the Service pack - you get the error. If you Uninstall the SP1, Delete all mention of WHOS-IN from the Registry, then re-apply the SP1, then rerun WHOS-IN user.exe - it works OK.
3. If you have a machine with XP, then you install WHOS-IN, then you install the Service pack - you get the error. If you delete all mention of WHOS-IN from the registry then rerun WHOS-IN user.exe - it works OK.

Another user further narrowed down the problem to XP Service Pack 1 altering the registry entry for ZTRAY.OCX. When the registry entry for ZTRAY was edited to point to the correct WHOS-IN server location, then the error was fixed.

NOTE: ZTRAY.OCX is no longer used (as of WHOS-IN version 2005-1A), so this problem should no longer appear.

Windows95 Workstation Installations:

Windows 95 is not officially supported with WHOS-IN however some sites have reported that it does work correctly *IF* the MSVBVM50.DLL file resides in the server WHOS-IN folder (this file is now installed by default).

Windows98 ActiveX problem:

Windows 98 is no longer officially supported with WHOS-IN (as of 1 July 2006) due to potential problems with a 'fresh' install of Win98. We have discovered that ActiveX errors are the result of some missing components that are added during the install/uninstall of Office/Access 2000. The only known cure for the above error is to install/uninstall MS Access 2000, OR to install the MS Access Jet 4 Service Pack (even though Access may not actually 'be' on the workstation).