Crise

with just that much info it is hard to say anything definite, f.ex. tell us do you use segmented downloading or not (in other words more info about your soecific setup would be nice).

/w is still there... or what do you mean.

I don't quite understand what are you referring to here...

you need to add that to the bottom of startup.lua as well

With 1.0.0 Final we introduced a new feature which allows users to extend ApexDC functionality through plugins. Now as wonderful as this sounds there is a slight but... you see no plugins exists as of yet. This is where you and your creative minds kick in, we provide you with the basic information about how to create plugin and in exchange you make plugins (sounds great, doesn't it?). I. What you can and can't do? Those of you who know how ApexDC source code is laid out know that it has two basic parts core and gui and out of these two plugins work mostly in the core part... so no you can't create that sidebar you always wanted in apex as a plugin. However, you can do a lot on the core side as well. Here are some simple ideas that could be created as a plugin: More of those lovely client side chat commands, such as /winamp or /define (even to the extent of user editable list) Answering machine (for PM's) Chat/PM filtering Primitive hub link Cross hub announcer (useful for hub networks) II. How does it work? Plugins should be created as C++ dll files which implement a class derived from PluginStructure and export the following functions: double __cdecl getVer(); // Must return API version, which is defined as API_VER in the PluginStructure.h char* __cdecl getGuid(); // Must return unique GUID/UUID for plugin (project specific, use guidgen.exe or guidgen.com) PluginStructure* __cdecl getObject(); // Creates plugin interface void __cdecl freeObject(); // Frees the instance created by getObject() There exists a sample plugin project in the ApexDC source distribution which shows how this is done in practice and we suggest anyone creating their first plugin use that as base and work from it to get all of the base code right (don't forget to change GUID). III. PluginStructure.h what, where, how? PluginStructure.h (located in client folder of the source distribution) is the file which defines all of the classes that are passed back and forth plugins and ApexDC... or to be more specific their interfaces, which are like skeletons that usually consists purely virtual function declarations. To put it short and simple, you do not edit this file at all even though it is the one file which makes your dll file ApexDC plugin. Although this file is strictly read-only for plugin developers they should read it through to get a good picture about what tools the have to interact with ApexDC and what functions ApexDC calls and when. The file is well commented so it should be relatively easy to understand what everything does. Here is a quick overview of the classes defined in this file, and their purpose: PluginCallBackInterface: Functions that plugins can call to interact with ApexDC++, see PluginStructure::getCallBack() UserInterface: Provides functions to get information and interact with a user. ClientInterface: Provides functions to get information and interact with a hub. ConnectionInterface: Provides functions to get information and interact with a client<->client connection PluginStructure: Plugin base class, provides functions which are called by ApexDC when certain event occurs. IV. Important Notes Build environment Setup used to compile plugin has same requirements as compiling ApexDC++ itself. Plugin licensing Plugins are automatically licensed under GNU General Public License (or GPL). Why? Because to successfully create a plugin you need a file which is part of ApexDC, and which thus is under GNU GPL and as long as your project uses GPL'ed code it is automatically required to be licensed under GPL or you have violated the licensing terms which apply to the part of code which is under GPL license.

Upload the filelist that causes this crash somewhere and then I can take a look... because I have no intention of going through possibly 100 of filelists before I encounter this crash.

Tunneling through third user, no way that is going to happen... since then that third user might not always know what his or her connection is being used for. Besides it would most certainly have negative effect on download speeds as well (because what might work on paper does not necessarily work in practice). As for the rest, for a derivative like us (ie. not the mainstream client) it's no use thinking about these kind of things. Also as long as DC stands for Direct Connect it would be bit odd way of doing things anyways.

When you have your ports set up correctly, you should encounter no problems, besides you can always disable TLS yourself if you have issues. I personally have TLS enabled and have yet to encounter any problems with it.

Toast old software does not mean that there is nothing to miss in not being on a hub. Though TGO being always full is indeed a bit of a problem, that I admit. But unfortunately there is little I can do about it.

Well I just tested few of the hublists with my version, and they seem to work just fine... 1.2.0B still has IPGuard, if that has been configured incorrectly it is possible that you have locked yourself out of the hublists.

Unfortunately we really can't help you with that, but there is a topic listing some public hubs in the guides section which you can look at but we cannot be held responsible for any of the material provided on the hubs listed (nor for the correctness of any information provided for that matter).

Heads up, GUI manipulation has been enabled in plugins for the next version... (or kind of it has been all along, just fixed few crashes with it, CBT hook FTW ). Any other ideas will be greatly appreciated though, so keep them coming.

Unless your script messes with ctm's (ConnectToMe), which it certainly shouldn't do, that message can't be triggered by it... it just might be that you are in a hub that is being used for CTM ddos...

hmm, has anyone else seen this... In any case is it just that hub or for every hub? (f.ex. try some random public hub) According to MSDN there are few possible causes for this runtime error... and I just want to know which is the most probable cause.

It will not be used, not at least for now... everything really depends on whether or not I can be bothered learning the new GUI Library. Also for the time being I still think that the old WTL GUI looked somehow slightly more polished, even though I do like some of the things that have been done with the new GUI (and depending on time and motivation might try bringing few of them over to the WTL one).

I don't know if you'll read this, but going to post anyways, for starters you seem to have a very interesting concept about what is and isn't a dead project. You say StrongDC is dead since long time ago, but you don't seem to be quite up to date with the situation, StrongDC is far from dead you see. Last I checked BM released a brand new version not so long ago (about three weeks actually), with a lot of nice fixes and changes in it too. You also say ApexDC is dead, which is also incorrect, last release was made on 24th of December last year and that's not so long ago considering that I am not getting any more free time out of anywhere. Now about the rest of your, lovely, feedback. You say that "ApexDC is nothing more than a StrongDC clone", that's your first and only correct remark. Since in the end without (S)DC++ ApexDC would nor could ever even have existed to begin with. It might be but a mod of a mod but it's our mod and no-one else's. You also said that when asked what is different between StrongDC and Apex the answer given is ridiculous, or features stated are of the sort that make you think that children are behind this project. True the differences might not seem significant to you but to me most of the represent a learning experience or a challenge I have had to face in the past. Now little something regarding that child remark of yours, because you are actually not that far off, had you made that same comment few years back the answer would have been yes. Because when ApexDC began in early 2006 I had just barely turned 16 (having had my first touch with real programming little over a year earlier when all this craziness originally began). Also, just for the record. I read almost every single post that gets posted on these forums, not so constructive feedback and feature requests alike, and will continue to do so in the future. But if I were to reply to every single one of them the content of those replies would be not only unacceptably low in quality but also most likely rude towards the original poster. It's also a matter of preservation of motivation in some cases, because there is limit to everything and f.ex. I have made a decision not to handle that many support requests personally anymore (dunno if some have noticed) because dealing with them can get very repetitive over time. Also just to clear things up, I respect BM as a senior developer and also because his skill and knowledge of (A)DC protocol and the DC++ code base still certainly surpass my own. But BM does not run things here, as you are implying above, although we do share a common view in some matters (like the matter originally discussed in this topic, for instance).

then there is something wrong elsewhere, because here it definitely does close down just fine...

it does but it does the closing in a such a way that it results in the delay. (ie. it doesn't just suddenly leave the connections hanging and just exit, but correctly disconnects them first and then exits).

it waits until all open connections have been closed before the process completely exits

You don't need to give people ideas like that...

If someone wants to do this Sergeo's way is certainly the right way to go, because as far as the webserver built into Apex goes it's a bit nasty and very limited altogether.

It's not far now, but since there hasn't been any test builds for testing since 1.2.0 beta was released so it is going to take its own time. Because we want to get a final out next.

Can someone rephrase this... having slight difficulty in understanding especially n.3 ...

The problem with that is security, since if there is any trusting in my memory RSS feeds don't do any permission checks...

I thought I'd bump this since with next version a Delphi compatibility might be possible to accomplish thus opening new doors for this feature.