quote:
Originally posted by SpunkyLoveMuff
I've got a feeling the error has somehting to do with the dll file not being registered properly either due to a regsvr32 error or the file not being moved to the System32 folder.
regsvr32 doesn't have bugs and DLLs don't need to be placed in the system32 folder (I even recommend not to place them there to reduce the left-over files when scripts are removed, or Plus! uninstalled).
I see you go about this in your script in the wrong way....
Simply include the DLL in the script packet (and ScriptInfo.xml) and let Plus! install and register the DLL. Do not do what you do in your current script, as that is most likely exactly what produces the error.
As for the DLL itself, you don't need it at all actually. There are Windows APIs which can do the same thing. Of course, it would make things a lot more complicated for the programmer 
quote:
Originally posted by SpunkyLoveMuff
/dpyou wouldn't work as slashes denote a command and so don't get sent and also trigger plus's error message about being an incorrect command unless it's added to the OnGetScriptCommands function and you add return ""; to the ChatWndSendMessage event.
OnGetScriptCommands has got nothing todo with that "isn't a command" error. OnGetScriptCommands is only responsible for what you see in the command window when you just pressed "/", that's all...
All you need to do to let Plus! reconize your command as a command is telling Plus! that you've handled the command (or whatever) so Plus! wont show the error. This is done by simply returning an empty string (or something else for that matter) in the ChatWndSendMessage event.
quote:
Originally posted by SpunkyLoveMuff
Generally, slashes are for your own commands, exclamation marks are for "remote" commands
There are no 'rules' or guidelines at all in this. All I could recommend is using slashes for everything as that is also what Plus! uses and thus what the user is used to.
--------------------
Also the error catching you do when reading/writing to the registry in the initialize event is a wrong way of doing it.
You only do error catching in the initialize event, while you should do it for every registry read/write (in the Read and WriteRegistry functions).
What you do now can lead to other errors. eg: what if the reading of the registry fails because the user don't have access to it or because of some other reason than the settings not being there yet? Then you try again to write stuff to the registry, but since accessing the registry produced an error, this too will fail...
So, this has also consequences in the way you read and set the settings of your script. What you do now is a bit inlogic. I don't see any global settings variable either.
Reading and writing settings should go like this:
1) When the script initializes you should try to read the current settings. If this fails, you must not write to the registry, but simply take the hard coded default values in memory in your global settings variables.
2) When the user opens a preferences window, the window should reflect the current settings in memory. Again, nothing is read or written to the registry yet. Also, the current settings are copied to temporary settings.
3) When the user changes settings in the preferences window, again nothing is written to the registry!, instead the temporary settings is the only thing which changes.
4) When the user presses 'cancel', nothing is again written or read from the registry. In fact, nothing at all is done and the temporary settings are just discarded.
5) When the user presses 'ok' or 'apply' the temporary settings are written to the registry and copied to the current global settings in memory.
All this also reduces the constant reading and writing to the registry which is what is happening now in the current script.
/ 
