poy

i don't think adding a listview to the settings dialog and reading / writing the corresponding settings is so hard and would need them to look at an existing source code... but whatever, fulDC is here: www.fuldc.net

you can solve this by using Trem's method in his fulDC mod: store the positions of links in a vector, and check in respond to the WM_MOUSEMOVE message if the mouse is over one of these links; then show a hand cursor in such a case. this way, you can apply any formatting you wish to the links; they won't have the default Windows theme color i'd leave it in the About box, though; it's always easier to see the mem usage there than to do a Ctrl+Alt+Del. i don't think only one call would cause a crash... :)

and i prefer it on by default... this would need some voting or something, but i think most people keep it enabled.

there is one thing you have forgotten, and that is to my mind the most important: telling the user to stay in active mode, and giving him instructions on how to forward ports manually. because, in many cases, when both direct connection and UPnP fail, i think a Socks5 proxy isn't really a good solution, and it would be better to have the user manually forward the right ports.

i might be dumb, but i don't understand the request... i mean, on Windows systems, you already have a button to minimize the window, so why do you want another one to do what the former already does? :D

there could be one easy thing of this kind: bind texts to Ctrl + 0, 1, ..., 9 (from the keypad) so that when you press one of these combinations, it either adds the binded text to the message edit box or sends it. this way, people could bind /f, or some ascii pictures, etc...

from my point of view, it's your solution (which is based on chat messages) that seems more like a workaround... dunno what he meant, maybe flooding. just activate such a thing in DC++ (show joins/parts) and you will see the **** it produces when someone has connection problems, and parts/joins every minute...

i've not tried it, but i believe you could try Ctrl + F or F3 in the hub view ;)

it's a very good idea; i would choose the $Supports method.

for several hubs, there can be some kind of manager like the one that manages the user commands, etc. anyway, this sounds really weird to me and i believe such stuff should be done hub-side, but shouldn't be integrated in a client.

yes, in such a case you can. but all hubs don't send such messages... it would be hub-specific.

i don't get it, why do you want to use PHP? LUA can do fine for a webserver, or working on files, etc. ok, not as great as PHP...

i've not looked at the details of the protocol eMule uses, but there is already a way to establish SSL connections on an ADC hub. wait and see... :D

i use 2 ways to see the system log: - i move my mouse over the status bar, and it gives me the last system log entries; - if i want further details, i simply open the system log file. so i don't think this system log view would be useful to me...

of course, some people would answer no to this question, but actually, i know of a hub where i was which did allow searchers of this kind to connect, because of a simple reason: if the searcher finds the file he's looking for on your hub, he'll come on your hub to download, and he might like it and stay on it since it's the hub that had the file he's been searching for so long... i've heard of 2 tools that can to this: MoGLO (tried it) and DCGUI. MoGLO gave me very good results, but this was some years ago, and i think MoGLO is usually banned now. however, if you find a hub like the one i've described before, it will still work. never tried DCGUI, and i'm not sure this one's integrated multi-hub search can be banned.

ok, ok, i hadn't read (*and understood*) all the details... :blushing: actually, i got the link from here: http://dcpp.net/bugzilla/show_bug.cgi?id=50#c3 edit: i've re-read (*and understood*) it a bit more, and i think the whole thing is about not having to open an UDP port by yourself:

only per IP, then, it's cool too ;)

you're right. maybe they will add such a column in the OP edition. they probably didn't put it here because you usually don't see anything else but IPs, unless the "searcher" (dunno the word) is in passive mode.

you're right on the fact that users with the same nicks can cause some trouble. but look for aSource->getUser() in ConnectionManager.cpp, you'll see this is used for the Pk, Lock, etc. so if this is used and considered good enough in all these places, it can also be used to identify the requester of a file, even if, i agree, it's not always correct when you have the same nick in different hubs. about "the same user with different nicks in multiple hubs", this isn't much of a problem, he just has to choose the right hub where to ask for your list, and he might get the best one! one could say there could be trouble on his side, getting "file not available" if his DC++ connects to you via the wrong hub. but this already happens if you use 2 clients with 2 different share on 2 different hubs, but with the same nick on each. and in your links, i read about some "technical problems" for DC++ to handle different shares. this can be bypassed with the use of vectors/maps/lists/etc. so your first point is still correct, but i would say "not that important" when you see there is a "hub" column in the transfer view, or in other views too; this "hub" column is usually filled with ClientManager's getUser(), which indeed does some guessing, but it's so widespread that i don't think using it one more time is really a problem.

you're right, there are other progs too, i used to use BWMeter for such things. however, it's more convenient to limit a user based on his nick, so that it still limits him if he disconnects / reconnects and his IP changes, isn't it?

actually, i already did this and i never had to open multiple ports or anything. i've changed nothing to the connection part, it's all in ShareManager'translateFileName. there, DC++ chooses which file to send as the file list; you have to give translateFileName the correct parameters so that it just has to pick the list corresponding to the parameter. in UploadManager::prepareFile, i added the correct parameter to translateFileName this way: ShareManager::getInstance()->translateFileName(aFile, aSource->getUser()->getTheShareToUseForThisUser()); there is no user guessing, because aSource->getUser() already identifies the correct user, with his hub, etc. (btw, it's in a DC++ 0.401 based, so it might change a bit in ApexDC++, but something like this should still be possible )

this is how some versions of DC++ worked when TTH was first implemented, and it indeed was very cool. however, with the new versions which are very "TTH-focused", i'm not sure this can work, there are TTHs everywhere in every procol command. and with the new ADC protocol, it's even more. however, if it was still possible do to so, i completely agree with your ideas ;)

it's so true, i didn't think about it... well... good idea, then! here is how it could be done: - the new .exe is hosted on a webserver - ApexDC++ downloads an XML file, where it compares its own version with the .exe's version, which is given in the XML file. timestamps could also be used instead of versions. this new .exe can go to an "Apex.update" file - ApexDC++ also downloads a small "update.exe" - every time ApexDC++ starts, it checks whether there is in its directory an "update.exe"; if this file exists: * if the file "Apex.update" is here, execute update.exe and exit; * if "Apex.update" doesn't exist, delete "update.exe" and continue loading - the update.exe file can be a simple command-line prog which tries like 10 times to move Apex.update to the old Apex.exe, if Apex.exe can't be accessed because it hasn't closed yet, pause during 1sec between each try. once update.exe has finished (either the renaming worked, or it didn't, this doesn't matter), it loads "Apex.exe" and exits. this is a scheme i use, so i know it works. there might be better, but it's the best i could find to fit to DC++.

i don't understand your point about the need of active and passive and stuff... don't you just have to create different file lists, and choose which one to use for each hub you connect to? then of course, handle uploads and answers to searches correctly so that you don't answer to one hub's user you have a file while it's not in the list you have choosen for this hub...

are you talking about your bandwith or the [website / server where the update file will be hosted] bandwith? (both might be the same, dunno...) because IMHO, a whole new .exe at least will need to be hosted somewhere, and transfering it to every ApexDC++ user would take a lot of bandwith.