quote:
Originally posted by mickael9
quote:
In the Settings.Set prototype I would suggest to add a third parameter which defines the type of registry key you're going to write. As it is now, you only write strings, but CheckInterval and Enable are better to be written as DWORDs.
I think I will detect the type of the variable instead ^^
Be very carefull in that. Before you know it you write a string instead of a dword or vice versa, etc because you made an error somewhere in your code or whatever. And before you know it you end up with settings which can't be read properly anymore by users who don't have the latest version or by users which has bad settings already in the registry. Then you need to compensate for that in another version, etc... big mess...
The reason to add a third parameter is so you can explicitly set a type, even if you screwed up somewhere in the script or Jscript's registry read function read the wrong type of variable (upon its return you expect it to be a certain type, but you can't be sure. And if you don't check upon it it is very well possible people will encounter errors in the script, etc...)
Types of variables in JScript can switch and change as you go, the benefit of adding a third parameter to this function is exactly to overcome this and write the boolean true or the string "true" as a DWORD... 0x1 for example.
If you're going to auto-detect it, you're better of not changing anything to what it was as auto-detecting will cause more potential errors to happen.
All this is also related to the use of operators like === instead of ==, etc...
quote:
Originally posted by mickael9
quote:
Instead of using == and != here and there, use === and !==.
See JScript 5.6 documentation or one of my forum posts why.
Hum ... but String.replace returns a string, so I don't need === no ?
You miss the point here. See JScript 5.6 documentation or one of my forum posts why.
quote:
Originally posted by mickael9
quote:
code:
function OnEvent_Initialize(blnMessengerStart)
{
LoadStrings();
if (SettingsOK())
StartTimerAndCheck();
else
ShowConfigDialog();
}
Do not use OnEvent_Initialize to load the settings. Use OnEvent_SignIn or even better OnEvent_SigninReady which makes your script user specific (also store your settings user specific!!!), which is very very very mandatory for something like this!!! (And don't forget to cancel the timer when the user signs out of course).
I will allow the user to leave the fields blank when the "Enable" checkbox is disabled. Maybe change the label to "Enable for the current account".
All that has got nothing to do with the fact that you don't store, read and handle settings user-specific.
quote:
Originally posted by mickael9
quote:
Same goes for the event OnEvent_MenuClicked.
In the next version, there is a new menu : "Check now" 
In that case I'll sush
PS: but if that was why you needed the translation, I would translate it like "Controleren op nieuwe prive berichten" (but this is of course very long).
Otherwise the user might mistaken it for checking on an update of the script.
The same goes for the English version, Don't just say "Check Now", but "Check on new private messages"
So you see, placing things in exact and detailed context and where it is going to be used exactly is extremely important in translating, just as what the translation means (eg: "check on new pms") and what is shown (eg: "Check now") can be/mean a huge difference.
/ 
