Total Updater 0.8.6.9 - Total Commander & plugin updater

[EricB]

@Bluestar

Indeed I see now that the new MhtUnpack version 1.8 is shown as an update again, so indeed no issue. Good to know about the PubDateDiffCorr setting.

Thanks for implementing autostart cl. One more suggestion would be TC location (or wincmd. ini location) for cl, comparable to /i parameter for TC itself.

I think I must agree with the WebID presence in the UserDB list, it is indeed useful for sorting.

Something that might be a nice addition is to use the Ctrl-Q Quickview box also for UserDB entries on the UserDB tab. This way much more information can be shown directly without having to open the actual entry, especially the author page and direct download links/buttons. I don't know if this is feasible? This way you could also make all popup forms more uniform. If the entry in Update tab is a UserDB entry, why not also show both links in the Quickview? The way I see it, Quickview, Internal DB and UserDB items are mostly using the same fields, so one form for all three might come in handy, optionally hiding the author page/direct download when not applicable (e.g. when an internal DB entry).

Regards, EricB

[Bluestar]

[face=tahoma]Total Updater v0.7.1 (Stable)

The first stable version has many stability improvements and fixes - support of some command line parameters & other new functions has been added too.
The date & version compare method has also been rewritten, and is now more stable than ever before.

Update is strongly recommended! (read the changelog for more info...)

Download | 19-03-2013 | MD5 (exe): 41af6a4acd400b8d68358ea12a2c7435

Changelog:

* New: Added new command line parameter "/autostart" - by running TU with this parameter, the searching of updates starts automatically
* New: Added new command line parameter "/i=c:\path\to\wincmd.ini" - from now on you can also set Total Commander's ini path manually
* New: You can simply press Right arrow key (->) to jump to the next updatable item in the list (if any exists)
* New: You can simply press Left arrow key (<-) to jump to the previous updatable item in the list (if any exists)
* New: Ability to use Information box (Ctrl + Q) when browsing items in UserDB
* New: You can manually set [GUI] JumpToFirstUpd=False if you'd like to disable the new feature which makes TU automatically jump to the first updatable item after search
* Change: added 74 new items to the Internal Plugin Database [and modified some existing with additional informations] (thanks to EricB & petermad)
* Change: added 4 new items to the checksum database
* Change: rewritten & much more stable version (local & online) compare function
* Change: rewritten date detection routine (works fine both with "dd.mm.yyyy." and "yyyy-mm-dd" etc formats)
* Change: enhanced intelligent version detection routine (added some extra files to check for, like *history*.en*, or *history*.ru*)
* Change: always try to match executables / dlls filetype with their online one to reduce the number of false detections (like the case with "PuTTY")
* Change: create a "%COMMANDER_PATH%" environment variable for the process if it doesn't exists (fixes problem with portable wincmd.ini files containing envvars)
* Change: jump to the first "Updatable!" item after searching for updates has finished operation (optional - see the [GUI] note above if you'd like to disable it)
* Change: disable the "Confirm updatable items as latest..." popup option in case there are no marked & updatable items in the list (no more auto-reselection)
* Change: added "Decription" editbox, "Author homepage" and "Visit online site" buttons to the Infobox
* Change: make the utility's window foreground after it finished the initialization process
* Change: from now on the "UserDB - New / Edit..." dialogs are resizable as well
* Change: links state (Author / Direct DL) can now be seen on the "UserDB" tab in a separate column
* Change: show "Total Commander" details inside the "Information" dialog (instead of opening it in browser) by double-clicking on it
* Change: download the latest "Total Commander" from totalcmd.net server (choose the correct package [x32/x64] based on the currently installed one)
* Change: reorganized the Internal Plugin Database window & added two extra fields (Direct download & Author homepage)
* Change: read the current item informations from UserDB if they exists & show them on Infobox
* Change: auto-resize the UserDB columns too on resizing the main form of the application
* Change: some additional code cleanups
* Fixed: date detection issue when online version is represented as a "yyyy.mm.dd" format date (e.g. the case with "DarkCrypt IV")
* Fixed: the utility wasn't able to correctly refresh (F2) plugins version which contained a date instead of a "real" version number
* Fixed: download problem with sourceforge links (e.g. it is now possible to download the "SynWrite" package)
* Fixed: delete incomplete file(s) from the disk after the download process has been cancelled (and closed)
* Fixed: do not allow to change download directory until the actual downloads are finished (or cancelled)
* Fixed: the number of marked items didn't get updated by pressing Space in the plugin list
* Fixed: a bug was making it available for the user to confirm items as latest which were in fact wasn't even showed as "Updatable!"
* Fixed: the "Visit online site" popup menu item kept being enabled in case the "Direct download" was filled for the entry
* Fixed: excluding a single directory / multiple directories wasn't working correctly
* Fixed: other minor bugs[/face]


_________________


@EricB: Ctrl-Q Quickview box for UserDB entries is now also available: hope this is the way you imagined it to work. =)

_________________


@Gerby: Actually TU should be able to detect "Downloads" folder, if it can be found in UserProfile directory (e.g. for me it can recognize "c:\Users\Bluestar\Downloads") - is your directory named "Downloads", or may it be the case that it can be found elsewhere... ?

_________________


@umbra: Now it should work even if you run TU from explorer.exe - %COMMANDER_PATH% is created for the process automatically this way. Currently I made some modifications regarding the Download dialog (e.g. modifying path is not permitted while downloading is in progress), though I'm going to change it to a more universal way for the future versions.

Regards,
Bluestar

[EricB]

@Bluestar

I had only time for a quick assessment, but awesome!

The Ctrl-Q for UserDB entries is indeed as I had in mind, also working seamlessly when switching from Update to UserDB tab. I noticed the Jump to File is not working there (yet, I guess). Also the Type of Item can not be changed. This latter would be handy when overruling an active entry to add some more information. The tooltip for the Direct download icon shows 'Visit online site', but the presence of both links is very handy.
Also I see that sometimes the WEBID of a UserDB entry replaced by the one above or below? This seems to happen after switching Update/UserDB tabs and then clicking on UserDB green entry in Ctrl-Q window.

I got rid of my previous UserDB and saw that now nearly all of my plugins have an active entry. I'll continue to improve upon content. Are you still planning to copy fields from Internal DB entry to userDB entry?

The autostart parameter is working well, only first time I thought it was doing nothing, because TU was still busy reading the file list items. This could be made more clear by also showing a status line, but I deem this not really necessary. Sometimes patience should last longer than one single second....

Keep up the good work!

Regards, EricB

[Gerby]

Yeah! Congratulations on the first stable release!

@Gerby: Actually TU should be able to detect "Downloads" folder, if it can be found in UserProfile directory (e.g. for me it can recognize "c:\Users\Bluestar\Downloads") - is your directory named "Downloads", or may it be the case that it can be found elsewhere... ?

Ups, I haven't mentioned this yet, sorry. The fact is that I've changed my user download path to E:\Downloads; so it's not the default path.

I'm not a programmer, but found the following on a little research: The user's current path to Downloads could be detected with the [face=courier]SHGetKnownFolderPath[/face] function using [face=courier]FOLDERID_Downloads[/face] as parameter (page on MSDN). Would this be applicable for you?

Greetings
Gerby

[Gerby]

Me again...

I've just stumbled over an issue with the UserDB. Initially I don't have any entry. After I've added a first entry and want to quit Total Updater, the program complains that it cannot save the current configuration/TotalUpdater.ini.

[umbra]

2Bluestar
Nice release.
TU now detects plugins even when it's started from Explorer. All my tools, that were incorrectly detected, are not recognized now (which is good, since they are not on totalcmd.net anyway). And I'm looking forward for the new download dialog.

[Bluestar]

Thanks to all of you for your kind words!

@EricB:
Glad to hear it works fine & just the way you thought it should operate; about the tooltip & "WEBID" remarks: thanks for reporting these bugs - just fixed them for the following version. I'm not sure if I can do anything about the "Jump to file" option regarding UserDB items though, as obviously no exact path is defined for them, and even if one does exists in the plugin list, we can't be sure that its the actual matching pair of a given UserDB entry...

Originally this "Infobox" (or Quickview) is intended to be a display-only dialog, and I don't really plan to change its basic behaviour in the future, sorry. Wouldn't be a hard job at all, but the logical way would be that in case its fields are editable in UserDB mode, they should be as well when browsing the items on the Update tab - and one really shouldn't edit these fields on-the-fly from this box imo, as they refer to the PE files VersionInfo content which is always accurate depending on the file's content (& UserDB fields, if its active).

I'm looking forward seeing more db entries from you - thank you very much for all of your work, I greatly appreciate it!

Regards,
Bluestar

@Gerby: Oh, I see, so you've changed the default DL path in Windows. I was focusing on searching for the most universal way to catch the downloaddir (the one which works on XP & below) [CSIDL], but somehow missed the fact that this method is obsolete from Vista above (though it worked well for me as well as for umbra, if I remember correctly - cause I assume we both have the default unchanged directory...).

The next version is now prepared to catch & resolve "FOLDERID_Downloads" as well, and falls back to the original method in case it returns an empty string.

Thanks for reporting the "OnClose" error, it is caused by the fact that TU always tries to save "userdb.ini" inside the directory from it is running, regardless of its writable or not. Changed a single line of code, so 0.7.2 is going to fix this issue (TU will save the file properly besides "TotalUpdater.ini" in the correct dir).

@umbra:
Thanks for the feedback & for confirming the fixes!

[EricB]

I'm not sure if I can do anything about the "Jump to file" option regarding UserDB items though, as obviously no exact path is defined for them, and even if one does exists in the plugin list, we can't be sure that its the actual matching pair of a given UserDB entry...

Originally this "Infobox" (or Quickview) is intended to be a display-only dialog, and I don't really plan to change its basic behaviour in the future, sorry. Wouldn't be a hard job at all, but the logical way would be that in case its fields are editable in UserDB mode, they should be as well when browsing the items on the Update tab - and one really shouldn't edit these fields on-the-fly from this box imo, as they refer to the PE files VersionInfo content which is always accurate depending on the file's content (& UserDB fields, if its active).

Fair enough. Indeed the items on Update tab should not be editable. Still it would be nice when turning an active entry into a userdb entry, that the Type of item is also copied.

Would you consider the following good additions?
- WEBID link/button in CTRL-Q for UserDB entry
- DL link/button in CTRL-Q for Update tab entry
- Tooltip text change to Visit Totalcmd.net page iso Visit online site

First two is handy for entries which have both WEBID and alternative download links (like Ghisler plugins). The CTRL-Q dialog will always have all possible links at hand (and can be disabled when link is not present)
Since totalcmd.net is key provider and not likely to be changed, you might as well mention this in the tooltip

Furthermore I found a problem with mediainfo.wdx; when clicking the active DB entry link in Quickview, data of some other plugin is shown. Also when double clicking the entry itself it shows: Sorry, unable to show, reason DB entry not found. This might be related to my previous bug report however. When searching on mediainfo.wdx in the internal database the entry is found and listed with all details.

Regards, EricB

[LonerD]

Suggestions:
- alphabetical sorting by names (and any columns - it's desirable);
- show installed and last versions in same format;
- it would be nice to be able to hide all of the plugins and programs marked Unknown;
- add directories from which the programs will be read, and from which not will be read (i have more than 700 programs in my TC pack and most of them are not in Total Updater DB).

Many errors in plugins names (incorrect big and small letters in names, some of them displayed very strangely, some has extra text in names, but most of them has abbreviated names.
Many errors in plugins detected versions and latest versions - displayed incorrect or old versions.

My plugins list in Total Updater
My REAL plugins list with correct names and versions

[Bluestar]

Still it would be nice when turning an active entry into a userdb entry, that the Type of item is also copied.

Actually the type of an item is always copied when saving an entry into the UserDB, because the only thing which determines a given item's type is the extension in the last part of its "ID" field (if it has been given). Basically - for most cases - theres no need to give the filetype at all, only for some of the executable tools / addons with a "common" name, to avoid the invalid online detection of the package.

Would you consider the following good additions?
- WEBID link/button in CTRL-Q for UserDB entry
- DL link/button in CTRL-Q for Update tab entry
- Tooltip text change to Visit Totalcmd.net page iso Visit online site

Sure, they will be included in the next version. I'm wondering about "Visit Totalcmd.net page" though if I really should change the current string to it, as for most of the items it is in fact the page which contains the additional informations, but in case the "WebID" contains a string like "#19994", the appropriate ghisler.ch forum topic is shown instead of the totalcmd.net site (like the case with sFTP plugin), so displaying "Visit online site" is just more universal.

The problem you found about "mediainfo.wdx" is related to the fact that it doesn't contains a WebID entry, since it can't be found on totalcmd.net. Actually the translation is not totally correct, it could say "Reason: WebID field not found" instead of "Database entry not found", 'cause the latter is not true in this case.

Regards,
Bluestar


@LonerD:
Thanks for your remarks & ideas. Alphabetical (ascending/descending) sorting & filtering / searching is in the todo-list, I plan to introduce this future later - some more code-cleanup & modification is needed to achieve this effect (it will then be able to hide plugins with "Unknown" state as well).

- show installed and last versions in same format;

Given the complexity of the compare algorithm its not really possible, and I don't see what would be its point.

One example: "dircpy" local version is "1.1.0.0" for me, online one is "1.10" - status: OK (they are actually really the same version, even though 1.10 should basically indicate a larger version, but TU can handle it & decide whether if they are the same or not) - should I really show "1.10" as installed version, even if its not what the PE file (wcx/wfx/etc) says... ? (Answer is no imho)

- add directories from which the programs will be read, and from which not will be read (i have more than 700 programs in my TC pack and most of them are not in Total Updater DB).

It is already possible: you can just right-click in the plugin list, and choose "Exclude from list" -> "File" / "Directory" / "Marked items". You can even select multiple items in the list using Shift / Ctrl and use the function above for them if you don't want to see those items in your list.
Regarding adding new directories to check for: adding one extra directory with which TU can work is already implemented, you can simply modify "TotalUpdater.ini" (be sure TU is closed before the action) and set the path to your additional tools directory using the "SecondaryPlgDir" key (also see the ForceSecondary option, which may be handy for you).

My plugins list in Total Updater
My REAL plugins list with correct names and versions

Wow, that must have been a hard work to check all these items one-by-one. Thanks for these reports, though the reality is that most of the "issues" or as you call "errors" you've detected are in fact absolutely correct & valid informations.

Let's see some of the cases - as I don't have the time to browse through & explain all of them: please check the files - marked with red in your list - PE VersionInfo section. For most of them, the author has simply forgot to update the version informations, and it is the cause of this "trouble", which in fact is not a real problem, as I do an extra datecheck (local PE compile / filedate vs date of the online last update), so these items are not detected as a false positive update.

- AviWCX: plugin's author has forgot to increment the version information (it is the most common problem). Latest version is correctly detected as "1.5", as it is really the latest one on totalcmd.net.
- CatalogMaker: latest version is 2.4 on totalcmd.net, I see no problem here. About the name: if a ProductName field can be found, this is used as the plugin's name (with cutting off unnecessary fields, like "plugin for Total Commander"), and if it doesn't exists, TU simply uses the filename without extension.
- Total Commander (CHMDir): now that is a real 'bug', as its ProductName is so cool like "Total Commander plugin for working with CHM files", so it is being cutted off improperly by TU, thats how it is going to show up as "Total Commander" in the list. Fixed in 0.7.2 - I am going to use the filename of such items instead of the content of their ProductName field.
- dircpy: You've underlined it, but I just can see what's wrong with its name. ProductName says its "dircpy for Total Commander", from which TU cuts off the "for Total Commander" part as its obvious. I could show the filename as well, but that is also simply "dircpy", so what's wrong with it?
- GifWcx: latest version is 1.1 on totalcmd.net, so it shows up correctly.
- WCX ICO: ProductName: "ProductName: WCX ICO" - I don't see any problem there either.
- TotalByClr: it is "TotalAndDroid" plugin, whose author decided to fill the ProductName field as "TotalByClr.Client" - it gets cutted at the "." part, so here comes the name "TotalByClr". Interesting though, I think he could easily change it to "TotalAndDroid", and InternalName and OriginalFN fields could still be the same...
- etc... most of the above applies for all of the plugins in your list (author forgot to update the verinfo; latest version on totalcmd is the one you can see in the list; ProductName is being read so sometimes they show up in the list with a "strange" name).

One question: Would you like a feature in "TotalUpdater.ini" like "[Plugins] ForceUseOfFN=True" (default: False), with which you could set TotalUpdater to always just read the filenames instead of dealing with ProductNames... ? (the way TC Plugins Manager works)
Edit: Nvm, implemented in 0.7.2.

Edit#2: Just added some of your "Unknown." items to the Internal Plugin Database as well, so the next version will be able to query their latest online version from totalcmd.net.

[LonerD]

Bluestar

Given the complexity of the compare algorithm its not really possible, and I don't see what would be its point.

Maybe it's way - add hash-sums of current (and old if possible) and next version of plugins into database, compare hashes of installed plugins and DB entries and show version from DB. If no information in DB - show versions as it now.

One example

Other example: VisualDirSize - installed version 1.1, but latest version in Total Updater column - 1.2 (in fact, even 1.3 beta6). Why it's shown OK? I deliberately use the old version (there are no errors), but 1.1 is more old then 1.2 (and 1.3) and both of them are not latests.

even if its not what the PE file (wcx/wfx/etc) says... ?

Imho - it need to show the version that installed (usually it written in the readme file or history or on author page).

adding one extra directory with which TU can work...

Thanks, I don't knew it.

For most of them, the author has simply forgot to update the version informations

If author forgot change version in w?x file - it possible to add correct plugin version (not plugin file PE version, but plugin version) into Total Updater DB and read information from DB.

...latest version is ... on totalcmd.net, I see no problem here...

latest version on totalcmd is the one you can see in the list

User want known and has latest version, his not interested - which version is published on which unofficial sites. Generally - author's site (!) must be main source of information, then - author's posts on forums with new versions, and only then - totalcmd.net, wincmd.net and other like not official sites.

WCX ICO: ProductName: "ProductName: WCX ICO" - I don't see any problem there either.

Plugin's name - ICO (in title of plugin's page).
It all not error or problem - we all understand what means, it correct from programmer point of view. But such misinterpret is improperly from end users point of view. The names and versions of plugins in Total Updater differ from the author's names. If we enter in google (for example) wfx_pcidetect - we can't find RedDetect plugin, if we enter Total Commander - we can't find CHMDir plugin. Etc...

but that is also simply "dircpy", so what's wrong with it?

In fact - this is DirCopy (second position in google), but not dircpy

Would you like a feature in "TotalUpdater.ini" like "[Plugins] ForceUseOfFN"

It's a solution, but defective. It is better to also add the ability to compare the hashes or name\version with the records in the database and show those names and versions those writen by plugin's author in readme file.

Sincerely,
LonerD

[Bluestar]

@LonerD:
Let's clarify something: theres only one accurate (and updated) online TC plugin database atm - which is totalcmd.net (I guess you agree with this basic fact).

The utility is aimed to work with its database, and I fully disagree with the conception you said, that "it should first check official pages of plugins".
What? Plugins, and official pages... ? For the most cases, such thing doesn't even exists. Or there were page for a given plugin back in time X years ago, but now can't be found (404, host doesn't exists, server is killed with fire etc). So what are we talking about? By the way even if it would be possible & every plugin would have an author page, how would you query & parse 100-200 pages (or more, depending on how many plugins you have installed on your PC), all of them with different page-structure (which can also change as time flies by), different version-numbering etc? And don't you think it would be a "bit" time & hardware-consuming to query & process all of these pages instead just one single page on totalcmd.net... ?

User want known and has latest version, his not interested - which version is published on which unofficial sites. Smile Generally - author's site (!) must be main source of information, then - author's posts on forums with new versions, and only then - totalcmd.net, wincmd.net and other like not official sites.

... and I'd like to have a Ferrari. Seriously, such thing as "wincmd.net" doesn't even exists. And even if totalcmd.net is called an "unofficial" site, its still the most reliable source of plugins. Should I browse every forum's every single topic's every single page on the whole internet to get the 'possible' actual version of a given plugin?
Anyway I was previously thinking on adding a new function for the application which could make it possible to parse given ghisler.ch forum topics / ghisler.com/plugins.htm page to catch latest verinfo of some special plugins, but thats the song of the future, and it wouldn't help in many cases (and even if its called "official page", the version informations on the "unofficial" totalcmd.net are still more reliable & gets refreshed more often...).

It is better to also add the ability to compare the hashes or name\version with the records in the database and show those names and versions

You must be kidding me. So you're basically suggesting that I should add the checksum hash of every single plugin that has ever been released before (and after) to the database, and choose their correct name based on it? Well, if you can provide me such a database, I'm not aware of the suggestion...

Some checksum-comparement (regarding versions) is already being done (thanks to EricB's loads of entries and some of mine), though there are dozens of plugins which should have be in the database to show the real local version information for them. And it would almost be totally pointless. I tell you why: the author would just release a new version of this problematic plugin, of course he'd forget to increment the version number just as he did before, so the checksum entry becomes obsolete -> that was it, we are back at the beginning, as if there were no crc32 value for the actual plugin. This way the utility would show the correct local version number _for a while_, but does it really worth it... ? Still, if you'd like to help by adding some crc32 checksum values to TU, you can simply do this task by using CRC32TU, which I publicated some pages before - accurate entries are always very welcomed.

I'm already trying to do my best to fix other plugin authors fault - like the lack of version number incrementing before a release (which is a serious 'issue' for normal softwares which needs to be fixed in the next release, so many times you can see a program with a changelog "Fixed: version number")... - and I'm not really interested in creating a database which would contain every single plugin's "correct name" (which is only correct for a given time - as every name can be changed anytime [e.g. see former "PciDetect" which now can be found under the name "RedDetect"]) and their version number. This latter information clearly needs to be obtained from the internet, not from my database - I don't have the time to maintain & always update the latest version number of hundreds of plugins all by myself, sorry.

Imho - it need to show the version that installed (usually it written in the readme file or history or on author page).

It is always showing the version number of the installed one. Readme.txt / history.txt just can't be a #01 trusted source of this information. In many cases an author doesn't even fills the readme with version information (more often it doesn't even exists), instead just writes "XY Plugin for Total Commander 6.50" - so should TU show "6.50" as version number for the actual plugin?
The intelligent version compare is intended to do this exact task (catch the verinfo from txt/htm/etc files), but it is strictly a secondary solution, if we can't find verinfo in the PE (w*x) file. If it exists in PE, we must treat it as accurate information. If it is not, it won't cause any troubles in most cases, cause of the local vs server-side datecheck I mentioned before ([Plugins] UpdateDateCheck).

We really should decide what is the main goal: to get a correct notification if a new version appears of any of our used plugins, or to read all the available readme/history/changelog etc files onload by processing every single file in every directory, and to compare these versions with the PE file's ones, and decide which is the correct one... ? And what if the author even forgot to update the version in the readme... ? Seriously. I don't plan to handle these cases, don't ask for it, its just not worth the time & absolutely pointless. I'll keep trying to make the intelligent version detection module as accurate & fast as possible, but the above conception would be just as 'unreliable' as the current one in this aspect.

If we enter in google (for example) wfx_pcidetect - we can't find RedDetect plugin, if we enter Total Commander - we can't find CHMDir plugin. Etc...

wfx_pcidetect & google: first page (second item), and that "Total Commander" item was just a bug cause of the special ProductName field of this item as I previously mentioned it in my post. And you really don't have to find these plugins in google, instead just double-click on them or right-click & choose "Visit online site..." or press Ctrl + Shift + Enter - problem solved.

In fact - this is DirCopy (second position in google), but not dircpy

You're wrong.

The folder it installs itself to: "dircpy"
Plugin's filename: "dircpy.wcx"
[PE] StringFileInfo/OriginalFilename: "dircpy.wcx"
[PE] StringFileInfo/InternalName: "dircpy"
[PE] StringFileInfo/ProductName: "dircpy for Total Commander"

So it is dircpy for me (even TC Plugins Manager calls it "dircpy"). I don't really care if its called "My Wonderful Directory Copy Extended Pro Plugin" on "http://somewhereontheinternet.co.org/softwares/etc/info/flash/html5.php", its local filename is what really matters, and its "dircpy". The author may even decide to rename it to "DirectoryCopier" / "DirCopyMaster" etc on totalcmd.net tomorrow, so should I show it instead of the local information inside the actual file... ?

About "VisualDirSize": could you please send the zipped file to me? Actually there may be two cases: either the PE compile date isn't valid & the last modification date is newer than the online one, or the PE compile date is also newer (which I doubt, so it should be cause of the last modification date, is it older than 24.03.2006?

Edit: I just checked and PE compile date is not valid for this item (set to "19/06/1992"), so definitely the lastmoddate is the one being compared with the online version)'s one. For me - by modifying the version number manually inside the file - it shows up as an Updatable item. [screenshot] (last modification date is 05.03.2006)

Regards,
Bluestar

[EricB]

Hi Bluestar,

Actually the type of an item is always copied when saving an entry into the UserDB, because the only thing which determines a given item's type is the extension in the last part of its "ID" field (if it has been given). Basically - for most cases - theres no need to give the filetype at all, only for some of the executable tools / addons with a "common" name, to avoid the invalid online detection of the package.

All of the UserDB entries I have now show type 'Other'. Is the type derived from the original filename (like bzip2dll.wcx)? I'm not always filling in all fields, since those 'override' entries are already existing in the internal database, but are just provided with some extra information.

I'm wondering about "Visit Totalcmd.net page" though if I really should change the current string to it, as for most of the items it is in fact the page which contains the additional informations, but in case the "WebID" contains a string like "#19994", the appropriate ghisler.ch forum topic is shown instead of the totalcmd.net site (like the case with sFTP plugin), so displaying "Visit online site" is just more universal.

Ah, I thought you said before that totalcmd.net would be the single source, so therefore my proposal. The addition of Ghisler.ch forum topics id is a very good idea, this way you can even add the related thread to the information, even when a proper totalcmd.net webid is present. So Visit online site is indeed more appropriate, knowing this.

The problem you found about "mediainfo.wdx" is related to the fact that it doesn't contains a WebID entry, since it can't be found on totalcmd.net. Actually the translation is not totally correct, it could say "Reason: WebID field not found" instead of "Database entry not found", 'cause the latter is not true in this case.

That's clear enough. I guess the translation will be updated at some time, NP.

Regards,

EricB

[bobya]

Thanks a lot for this great tool. I was looking for something like this for a long time. If I may suggest couple of things:
1. It would be great to update the plugins when downloading them, not only to select a folder where to download.
2. It was not visible where I should configure my proxy server
3. It would be great if I can configure the download directory before I hit the download button.

Once again, Thank you for your effort

[Bluestar]

Hi EricB,

All of the filetypes are derived from the actual UserDB item's ID(entifier) [if you are browsing the items on this tab], so if you save an item like this:

ID (filename): bzip2dll.wcx
WEB: bzip2

Then the type will show "WCX", based on the userDB item's ID. The fact that all of your entries shows "Other" as type simply means that they are all saved without extension (which is absolutely fine! - one really only needs to save an item with extension in case it has a common & frequent simple name like "avi", or "pdf", etc, so for such items it is preferred to save them as "avi.w#x", "pdf.w#x" etc for the utility to identify their online matching pair correctly), so there's nothing to worry about.
I could show the filetype inside Infobox while browsing items of UserDB tab based on the OriginalFN, but its unecessary, as it would just confuse the users - I think we need to show type of the saved entry (which TU will search the update for), and not its PE informations (which can be seen anyway in the fields of Infobox).

Regards,
Bluestar

_________________

Hello bobya, thank you - I'm really glad you like the utility & find it useful.

About the updating of plugins: it is a planned must-have feature (as I also described it in the topic's first page & on totalcmd.net), will be ready in future versions after everything is prepared for it to work & all of the most important issues of TU are fixed.

I agree, the proxy configuration could have really been easier, and as I didn't had the time to write a readme yet, one have to figure out these things for himself... I'm not sure when, but readme.txt is definitely going to arrive as soon as possible. Maybe I should even introduce a new "Additional settings" dialog in which such things could be easily set by the user directly from GUI.

Configuration of the download directory (when its the first time of download a plugin/addon) is going to arrive in 0.7.2 - also, from 0.7.2 the user can set the DL directory in the Configuration tab - stay tuned.