This has been an on-going and intermittant problem with Medisoft and Office Hours for a few years (and a few versions) in our office. There are usually one or two computers on the network that are unable to run office hours. It got so annoying I wrote a small program that is basically a stripped-down clone of Office Hours. The clone program can flawlessly retrieve information from the database under all circumstances... on any machine, at any time, without fail. This always indicated to me that, on misbehaving machines, it is not a network or database issue, but likely either a local machine-specific settings issue that conflicts with Office Hours, or an Office Hours/Medisoft coding problem. If Office Hours is incompatible with certain Windows XP settings, I might again lean towards this actually being a Medisoft coding issue. Sometimes a full uninstall and reinstall will get things working for a while, but the \"gremlined\" machines will usually revert to being disfunctional sometime down the road.
Through a little investigation, I've found a way to get the programs to operate correctly (until the next time they decide to go south). Maybe this would be of some value to the Medisoft development team...
If you start the Office Hours application, it will successfully get beyond the splash screen, then open the main (full-screen) window. The main window will partially paint and then freeze. The usual result is an Office Hours window that displays the window title and the remainder of the window is white. Sometimes the top menu bar, or some of the tan background shading will paint before the application locks up.
Watching the events above as they occur via Windows Task Manager reveals some additional information. Initialy, one \"Office Hours\" task in created and it is hooked to a single \"OHP.exe\" process. Just before Office Hours hangs, a second \"Office Hours\" task starts, this one is linked to the main \"explorer.exe\" process (your desktop!).
I believe, in Task Manager, the mechanism that allows you to \"End task\" from the Applications tab, and the method used to \"End Process\" from the Processes tab, work in a much different manner. \"End Task\" being a fairly civilized shutdown of an application, and \"End Process\" being a crude blow-it-out-of-the-water process kill.
There are two tasks and two processes you could potentially terminate.
If you end either Office Hours task, the one hooked to the OHP.exe process, or the one hooked to the explorer.exe process, Office Hours will eventually terminate, and generate a \"hungapp\" error via Windows Error Reporting. If you kill the OHP.exe process, the same result manifests. So, three of the four possibilities for zapping the hung program behave the same, and all LEAVE OFFICE HOURS INOPERATIVE ON THE PC.
I believe the \"civilized\" nature of \"End Task\", checking dependencies, etc, prevents you from actually killing your desktop when you select to end the task attached to explorer.exe, and instead it kills the actual OHP.exe process and doing that releases the link to explorer.exe.
Here is the interesting part...
If you instead do the fourth option, the odd choice of killing the explorer.exe process (your desktop) while the OHP.exe task is hooked to it and hung up, the following occurs:
Your desktop goes bye-bye, no more icons, no taskbars, no start menu. Your PC is not very useful at this stage, and your only recourse is to do a \"restart\" via the still open Task Manager. Strangely, after the reboot, OFFICE HOURS IS FIXED. It will start normally, repeatedly, and appears to work perfectly. Something is being unregistered, or cleared from the registry, or something reset when forcing the desktop to close while OHP is hooked to it and hung up. Maybe I'll do a before and after comparison of the hives while performing this \"fix\" on one of our bad machines, or see if any cfg or ini files change, or...
Anyway, at this point I do have a crude fix to employ when Office Hours (or Medisoft) decides to stop running on one of our machines.
What do you think???