On Sat, 2003-08-30 at 22:10, Greg Ford wrote:
> I think maybe SwishCtl should never return an error value to the ActiveX
> subsystem but rather just use the swish-e error function (getlasterror() ?).
> I would have done this in SwishCtl if I'd understood earlier the nature
> (severity) of ActiveX errors.
Yes, I think that's the only way to handle it. The control should never
error unless there's a problem with the control itself. SWISH-E should
return errors gracefully and the control should return some error flag.
The SWISH-E error could then be retrieved with getlasterror() (I think
that's right, BTW).
> Currently the setup program will overwrite an older SwishCtl.dll
> installation with a more recent one. So if you have 2 CDs containing SwishCtl
> databases with different versions you have to uninstall the new one before
> you can use the old one....
Could/should the UUID of the new control be changed if the index format
changes? Or would the DLL filenames conflict? That could be solved but
it would be annoying. And, nothing says they would have to use the
newest version. If someone needed compatibility instead of features
they could just maintain the older version on their own.
> I haven't checked whether the swish-e library has a way of checking the
> version of the index files - but SwishCtl should probably do this!
There's a magic number to tell SWISH-E the index is the wrong version.
Be warned that it doesn't always get changed when the index format
changes during development... It has been changed recently, though.
Strange things happen when the number isn't incremented. ;-)
> I don't think there's much of a problem for ASPs - what the current
> registry settings do is that they mean you have to have write access to
> the registry to be able to add a new index/database.
The current method does well to prevent it. But, modifying the HKLM
registry to add new indices would be inconvenient on a shared host. Of
course, changing the control to allow files to be specified by the
script could be dangerous. Splitting the privileges seems like the best
compromise. Let the user specify filenames (with well defined
restrictions) and let admins specify directories. One person could read
another's index, but, I think that should be an assumed risk on a shared
ICQ - 412039
Received on Sun Aug 31 08:46:42 2003