Crise

It isn't forgotten, but not fixed, at least not yet and don't know if it will be... not exactly critical bug.

inline static uint32_t make_ip(unsigned int a, unsigned int b, unsigned int c, unsigned int d) { return ((a << 24) | (b << 16) | (c << 8) | d); }

Well pending is far better than rejected.... isn't it?

I don't do time frames or deadlines, because I have noticed that I have much difficulty keeping them :crying: Also sorry for the delay, kinda have to learn java now so my concentration and time has been divided.

Yeah, probably, I need to do something about that soon though :crying:

Fine by me, as long as the one doing the plugin won't be me :crying:

What you see there is called politeness , no need to get angry over it. Many others got a mail exactly like yours, the acceptance rate for applications this time around was approximately 20% (so really not that many got accepted in the end, as you can see). Just for the record the percentage count is just an estimate I threw from my head didn't count it in any way.

No we do not choose them randomly...

This is really quite pointless vote, for I decided long ago that no new text commands will be added, besides those that are part of another bigger feat. In short now new "shortcuts" will be added as a text command.

The script that is behind the connection checker detects the ip independent of Apex (it didn't used to be like that, but for security reasons this has changed). So it isn't ApexDC++ binding to wrong address at all :stuart:.

Regarding release dates, if I can choose I'll never set a deadline for myself... so all I can tell is that we are aiming fir this Christmas, but that is not a definite time, it might be sooner or it might just as well be later. Everything depends on how much free time I have at my hands and how much of it I am motivated to spend on Apex. I can already make an unofficial statement, that most likely I'll be taking a longer break after 1.2 is out of the way.... there are many reasons for this and one of them is that for a long time now I have been missing a "bigger picture" regarding future additions and features. In order to rebuild this picture a break is necessary in my opinion.

Here would be another one for those that are interested, since I doubt this one has got that many readers yet http://developer.berlios.de/devlog/adrian0...4/new-detector/ :stuart:

Just heads up... after reading some of the first applications for a tester position I must say some of you didn't quite grasp what kind of persons are we looking for. For starters an application containing only two lines of flattery is certain to get a rejection and some even wrote only the "Can I have the beta?" even if I deliberately gave it as a bad example. Some were wondering why we gave you such vague instructions on what kind of application to send. Here is my answer to this, I wanted to see what people think a tester is and what they think are important qualities, skills or experience for one. This because usually those that have potential can bring up the right things about themselves without further instructions.

To those who are interested in applying for tester position, here are few hints: Email that has been thought out, and time been used to write it, gives far better impression that a hasty mail written in less than a minute. Simple request won't do, ie. all emails with simply "Can I have the beta?" etc. in them will get deleted without a second thought (software testing is a game of give and take, you know. Meaning that we are looking testers, not people that simply want to use the latest developement version). Write in understandable English (unfortunately, we can't have testers, that can't communicate in English). And last but not least, the subject of the mail should be: "Beta Application - [forum username]". Those who are wondering, the last point is there for two reasons, to see if you actually bothered to read this message and to ensure that you have a forum account here. (Any emails not following the specified subject pattern will likely be ignored).

Define "complete release"? No, I am not stupid and I know what you mean by it, but my point is... there is no such thing as "release" defined anywhere in any standard... and no program can say if anything that has unknown number of definitions is complete or incomplete. This is a fact. Thus, what you asked is impossible and as you said yourself there is no such program (even a DC client such as fulDC is not such a program). What we can do is check finished file's integrity against an .sfv file but that in no way guarantees what you ask. Sure you can say that every scene release contains an .sfv file, but what you fail to see is this: DC is not the original distribution method for these releases, so it is perfectly possible that the .sfv is incorrect or has gotten corrupted during the transfer from scene ftp to DC users share in a hub (which is quite often through more than one people's computer). Or alternatively, I could create a "scene release" of my own out of the dvd made from the film footage taken on my last family holiday in Egypt, and share it on DC, and no program could tell the difference between this fraud tailored by me. (with this I intend to point out, that creating .nfo files split-file archives and an .sfv, is not a secret zen art known only to those that release stuff to scene ftps). Besides you seem to get the function of the .sfv file wrong, even though I am no specialist, I can be fairly certain when I say that its original purpose is to check the files for possible corruption during the transfer from ftp to users computer (DC clients have TTH to check for corruption during transfers), and hardly to check for missing files. (I can be fairly certain of this because, if scene release is incomplete, non working or corrupted it gets nuked). However, as a final note, to check release completeness with the .sfv is fools doing, for in order to do that you could have to download many files that would turn out to be useless if the release proves to be incomplete (just use the .nfo file, your eyes and and your common sense to see if it is obviously incomplete or not, when queuing stuff). Btw. If people request a feature for checking scene release integrity we can't implement such a feature because if we did it might be seen as encouraging our users into using our program for illegal activities, which we do not do or sign in any way.

Well I don't have that version anywhere anymore, unfortunately, but it was pretty much simply replacing std::string with char* in the function declarations (adding const, where not present) and then using .c_str() to get the const char* pointer when calling them... and again if there was need to pass a "result string" from dll back to exe ie. a modified string we would make the function return another const char* and then on exe side make const std::string out of that one (of course here we assume the plugin dll would make these returned chars anew with the PluginAPI::AllocFunc(...), since modifying the passed params would be, not impossible, but foolish). If you need to look at PluginManager code it might be wise of me to share the new code with you, so you can see the up to date stuff in its entirety (and in full context) rather than just bits and pieces. PS: Check you PM's :P

Well we use cdecl calling convention, and afaik Delphi supports stdcall and cdecl... so no problems there, I think. As for using plain char pointers, when I did that the strings got mangled when passing from exe to dll... or vice versa, even though I was careful to make sure that the contents of those pointers can't be directly edited (ie. const pointer to const object... in this case char), because allowing that would naturally be risky and cause myriad of issues. Even though I answered the question about naming, here is a compiled dll attached anyhow, if it's of any help...

There is quite a lot of changes... and I really don't know if you will be able to pull it off with these changes, but I hope so... for I too like the simplicity of Delphi as opposed to C++. (meaning I can create more complex plugins faster with delphi )- These two are probably the biggest changes structure wise, though there a bunch of others as well... I think it's good to mention here that I would have preferred to use plain char pointers had it only worked well... (this is about the first listed change, which might be by far the most problematic). In any case I have attached some stuff regarding the new way the plugins are done... including the updated sample plugin. If you can spot any incompatibilities with delphi give a shout and I'll see if there is something to be done about it. Unfortunately my knowledge regarding the finer points of delphi is inferior to my C++ skills, if it were otherwise I would have made sure to preserve compatibility... PS: Also if you or others are wondering the big changes... this is because only after these changes can I consider the plugin api usable and truly useful to some. after next version there probably won't be any big changes in regards to plugins.

Maybe it is more correct to say, that only they can get/use it @burek: Regarding betas in general... I have no desire in going through dozens of dupe reports for beta issues, when I can only have a handful instead. That is if you put it simply but of course this approach does have disadvantages too but imo. the pros outweigh the cons because many users seem to have hard time providing constructive (or rather complete) feedback. So I'd rather have handful which I know to be able to manage that than 23,000 of which maybe 25% can do that, to be blunt.

They are in the exe, so they can't be edited, unless you recompile...

You can't turn that off...

Not really as most of the time there is no fool proof way to make difference between chat room and normal user (in NMDC).

afaik the source for this is vista, you can solve this by disabling "Show shell menu in finished transfers"

Yep, shouldn't be long now... but I can't be more specific than that.

When I can be bothered making some :(