Xniff? ai...
It has troubles with Vista and it contains a big bug where it will internally crash Plus!/Messenger on exit. See notes:
CookieRevised's reply to [Release] Xniff (ActiveX Packet Sniffer) - Examples inside
And it does crash Messenger/Plus! internally when you try to update Plus!.
Also, when people have other scripts with Xniff, they can even get in trouble when they simply uninstall some of those scripts (since you can only register one file at the time. All other scripts will start using that file in the new location. Removing that file means that all other scripts will stop working and will produce errors).
And, what about:
CookieRevised's reply to Protocol (Using Xniff)?
anyways, background reading material for people having problems:
Packet sniffer that supports all wirelless connections.
-----------------
As for the script (not considering the problems with Xniff itself).
The method for starting up is a faulty. So even if the rest of the script works 100% already, it wouldn't even start properly...
The error checks you do in OnEvent_Initialize aren't done in OnEvent_SignInReady. However, the checks in OnEvent_Initialize are not executed when the user starts Messenger (since he didn't signed in yet). For example DoInit is never called (unless the user installs or actually restarts the script while he is signed in), which is the most crucial function for this script.
Maybe you better put everything (all the error checking and initializing and calling DoInit) in OnEvent_SignInReady and simply direct OnEvent_Initialize to OnEvent_SignInReady (or don't even use OnEvent_Initialize since it makes no sense to use this script while you're signed out anyways).
thus:
quote:
Originally posted by Dempsey
quote:
Originally posted by vikke
mynetx: Register the Xniff.dll using regsvr32.
It doesn't need registering, the script tries that itself if it has an error loading xniff.
It was intended to do that, but unfortunatly it doesn't.
-----------------
PS: though, I very much like it that you don't force the file to be registered (eg: by using ScriptInfo.xml) and first try to initialize the ActiveX in case it is already present somewhere and already registered in another location
. Everybody should do this in their scripts since it will partially prevent some problems talked about above
PS: the hardlink creation is a nice touch, although I would personally rather see this as an option.
It can create difficulties/confusions when the user decides to remove a file and later decides to place it back, or move a file or something, expecting the link to be intact, which it wouldn't.
Or device a scheme where the hardlink is only there as long as the conversation window is open or something. In that way the user doesn't loose the ability to open the file from the conversation window, and his recieved folder doesn't get cluttered with filenames (wasn't that one of the goals of this script in the first place? To releave the folder of cluttered files)... or something.
And I dunno how 3rd party programs like some file schredders for example react on removing a file which is hard linked; maybe some will actually overwrite the file contents even if the reference count is not 0, leaving the other copy link useless, while the user thinks he has still a perfect copy of the file. Such 3rd party programs are not the problem of this script, but something to consider when your program makes use of hard links and such stuff...
And IIRC hard links can only be created on the same volume. So if the user decides to have directories on another volume (to save space?) than Messenger's recieved files folder, the link can't be created
(plus it is not supported on fat32 of course).
EDIT: Oh, and the Windows API for creating a hardlink is CreateHardlink(). It works as easy (if not easier) than using a DOS Shell to FSutils.
/ 
