quote:
Originally posted by XgD
The installer was a default script for NIS... I'll write my own soon. (Actually, I remember seeing a plugin installer on mess.be a while ago which I might look for soon)
It is also possible in NSIS to show this screen though.
I mean, it is shown already during the installation though, only the next (finish) screen is automatically shown when the installation finishes instead of waiting on the previous one until the user clicks "next". It should only be a matter of setting some option in the installer code.
quote:
Originally posted by XgD
quote:
Don't use external DLL's if you can avoid them.
This made things a lot easier. Is it so bad to have 240kb of DLL files? I would put them in the same folder as my DLL, but MsgPlus might have tried to read them as plugin DLLs, so I just put them in SYSTEM32. I'll change that in future though.
...
Well, it's a waste of 240kb if you only use 2 specific relative small functions of these DLL's. Functions which you easly could be implemented directly into your program.
Though, it is indeed easier. But the fact that a program depends on 2 external DLL's of which you use only 1 function each and that those DLL's must be placed in the user's system directory is a bit "useless" and waste of space, for the lack of a better words.
Note that there are many many other free (un)zip DLL's which can do the job, which are a lot smaller and where the zipping and unzipping are the only functions inside 1 DLL.
As for putting them in the same directory of the plugins: If they aren't real plugins, Plus! will not load them. Anyways, you could also place them in a subdirectory of the plugins folder and link to them inside your code using the subpath instead of using only the DLL name.
But the best and most elegant solution would be to integrate your own (un)zipping code though...
PS: there are many other compression methods you could use also. Methods which are a lot easier to implement directly into your code and which are even free to use and well documented, etc... But I'm sure there are free to use delphi sources for (un)zipping.
quote:
Originally posted by XgD
The inconsistencies are due to the debug code being outputed by different components. I tried to link them up as best as possible, and I'll try to see what I can do.
But you pass the strings to the log window in your own code, no? So you can pass whatever text you like, aka fix the text from those different components before you send them to the log window.
PS: this is indeed one of the big disadvantages if you depend on such 3rd party controls. But normally don't such controls output an error code also, which you can use to show your own error/debug texts?
quote:
Originally posted by XgD
I can't see any spelling mistakes. Do you mean grammar?
corrected spelling mistake: (un)successfull
And not really grammar though, but more the inconsistant and wrong use of comma's, periods, "...", spaces, cases, etc. It currently looks a bit messy IMHO.
quote:
Originally posted by XgD
quote:
1) Why three times that same message?
2) Why is the new name the same as the old name?
(1)It tries 3 times if the password is incorrect
(2)The filename is the same each time (email@address.reg/zip)
1) But why trying three times? If it has failed the first time, it will fail the second and third time too, no?...
2) I see, but then it doesn't make much sense to show
"old name=blah // new name=blah" if they will always be the same anyways.
quote:
Originally posted by XgD
quote:
Temporary files are not removed! (the reg and zip files)
They are (or should be) if the backup is successful
They should always be deleted IMHO or you will make people's root folder messy and full of redundant stuff (or any folder you put them in for that matter). The average Joe will even not know there were files left which he should delete.
Oh, since they are temporary files, maybe its better to create them in the temporary folder of windows. It is not always true that C:\ is writeable or even accessable.
Maybe also name the registry file in a unique way. An email address isn't really unique and as a matter of fact, your tool had overwritten one of my stored registry files which I also named as "me@mail.com.reg". Start by creating them in the temporary folder, this will almost avoid such things. Making the filename unique to your plugin (eg: "syncher me@mail.com.reg") would help a bit also.
In fact, the name can be random since the zip will always contain only 1 file anyways. And this filename, if you have a need for it, can be read out using your (un)zip DLL's.
As for the zipfile name itself, this can be really a true temporary random name as you can rename it during the FTP transfer. When you download it, you could rename it back to a true temporary random name to again avoid overwriting existing zips with the same name which the user created for its own use.
----
My personal approach to this, if I would create such a tool, would be to start by making my own compression algorithm. Or at least integrate it in my program code directly, so I have full control of what I write to what files. Thus I wouldn't have potential problems with overwriting existing stuff from the user, I wouldn't depend on 3rd party stuff, and I wouldn't have compatibily problems with different OS's:
Since the filename of the registry file isn't important at all (you get the email address of the zip file, not the reg file) this name doesn't matter and can be left out. What I mean is you can create your own compression format (or use an existing one) which doesn't care about what files are inside it, but only cares about the actual (compressed) data. You'll get the same effect when you strip a zipfile from its directory headers and stuff, and only leave the actual compressed data.
And as said before, this file is, when created, a temporary file. So it will have a true temporary filename (which you'll get by using the temporary file windows api's) and I would only rename it to the proper email address during the actual FTP transfer.
storing:
1) Create a handle to a new temorary file in the temporary windows folder, naming it as a true temorary file (which is always unique).
2) Read out the registry settings by using the windows api's (not reg.exe or regedit.exe)
3) Compress this data (which is still in memory, I don't use any files to store it) using your own compression routine and store the result in the temporary file created in step 1.
4) Transfer this temporary file to the ftp server and while doing this rename it to the proper "me@mail.com.dat" (I use dat extension here, since I created my own format)
5) Delete the temporary file (successfull transfer or not)
reading/setting
1) Transfer the proper filename, according to what the user has selected as his email address, from the FTP server to a true local temporary file in the temporary windows directory.
2) Read out the data of that file, and decompress it so you'll get the registry data again (again, all this is just done in memory, nothing is saved or stored in files)
3) Apply these settings to the registry
4) Delete the temporary file (successfull transfer or not)
But that's what I would do... just an idea...
quote:
Originally posted by XgD
quote:
Do not store the reg files as version 5.00 files, but as version 4 files!
I can change the first line to "REGEDIT4" if that would be better?
Depends... the structure (or better: the syntax) of the files themselfs are a bit different also.
In the new version 5.0 there are some types and entries which aren't known in a version 4.0 file and must be written differently.
Also, if you do use "reg" to create these regisrty files, then change that also. "reg" isn't an available command in all Windows OS's, only in Windows 2000 and higher.
If you still want to use a DOS command, use "regedit.exe" instead, which is available in more Windows versions. And use the paramater "/e" (export):
START /WAIT REGEDIT.EXE /E "c:\blah.reg" "HKEY_LOCAL_MACHINE\SOFTWARE\blah"
But the best thing you can do and most compatible way is to query the registry yourself using the regisrty windows api's and make your own (REGEDIT4 compatible) reg file.
If that isn't possible, than reread the created registry file and if it is a version 5.0 registry file, convert it yourself to a version 4.0 file prior to zipping it. This is indeed done by replacing the header and this usually works in most cases. But in some cases you also need to convert some entries which aren't supported in a version 4.0 to a binary entry.
quote:
Originally posted by XgD
quote:
if you show a message box or input box, show them in front (aka on top) of the windows. Currently they appear behind all the windows.
I think thats a bug with Delphi's stay-on-top code, but I'll look into it
Maybe, I don't know. But in any case, do not use "stay on top", use "show on top", there is a difference.
Settings Sync/Transferer/Backup
/ 
