At 09:07 06/06/2002 -0500, you wrote: >Agreed. Largely my fault I'm afraid.
Well, you've added a new class, but I've added several methods to the existing ones, so I reckon we're about equal here.... >Have you had success with this? My experience has been a maintenance >nightmare. Not to say it isn't the correct thing to do. Everything to do with versioning is a nightmare! The situation in which we'd get an advantage (only if we switched to version-dependant prog-ids in the script) is where the DQSD DLL changed name (so that there was not problem with an overwrite), and the GUIDs/prog-IDs all changed as well. That way the new script would pick up the new DLL, and the old one would get unloaded at the next boot. I've just been investigating forcing Explorer.exe to unload the DQSD tools. I've been as far as forcing CoFreeUnusedLibraries to run within Explorer.exe, but it's still not enough to unload us. That's a disappointment. Stopping and restarting Explorer.exe is a possibility, but you can risk losing recent config, etc it you're not careful. >Don't know. It should do something in the case of locked files. I assumed >NSIS did something with the runonce registry entry in the case of locked >files, but I've never looked into it. It probably is doing it - most people's problems seem to be fixed by a reboot - it just doesn't seem to report that a reboot is needed to the user. Probably decent diagnostics and messaging in the script is all that's really needed. Cheers, Will _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dqsd-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dqsd-users http://sourceforge.net/mailarchive/forum.php?forum_id=8601
