dmvn

Well, thank you, sms for the translation of ApexDC 1.0.1! I've made a translation of 1.1.0 based on it (see attachment). Russian ApexDC++ 1.1.0 (11.06.2008) PS. All fixes please PM me, will update file in attachment! Russian.1.1.0.xml

Damn twice! Thank you, Satan Simply don't know that this toolbar can be locked, never rightclicked on it :)

what about mailing them ? I really believed in speedmod death after no updates last 1/2 of a year... Glad to see that it's not truth, but SF must be updated too.

Sounds good! /me already downloaded sources... Thank YOU !!! PS. Damn! It's strange but in 1.1.0 the QuickSearch panel cannot dock and move!!! Please have a look here: This is Apex 1.1.0 And this is Apex 1.0.1: It's a bug? :)

Waiting with great patience! Please don't hurry, the Apex' stability must remain intact, hope no hotfixes like 1.0.0-->1.0.1 will need.

well, we'll try to implement 'proper' version... don't like to dig the non-mine code but it's our duty. af we were lucky, i'll provide the .patchfile for it.

Awaiting with patience, netcelli. You cannot grave your project now. Hope the summer holidays help you to complete the task.

Are there all devs on May Holidays still, eh? :laugh: Maybe some comments will follow ? :)

Thank you, BM; hope Apex devs will merge this fix... Annoying bug for ops, btw.... Btw, sometimes Apex crashed on usercommands when this usercommand lead to user ban (and some other actions...)... Hope this is fixed too.. I mean http://forums.apexdc.net/index.php?showtopic=2681 this...

Sure this must be moved to 'Bugs' section. Anyway.

That's not right, obviously. Let chat window shows lines from i till j while whole buffer contains lines from 0 to n-1. Let us add k lines in the bottom of chat, so entire buffer moves to [k, n-1+k]. This means we should decrement i and j by k (of course, if i < k then we'll lost some lines, and that's right -- in this case chat window line ranges must be set to [0,..windowsize-1]. Hope this is clear. The autscroll abscence MUST disable any scrolling, so all lines remain intact as long as it possible.

This is a *STRANGE* behaviour... Any comments why this was done in such way? I think we should have a feature/switch that disables scrolling/chat window updates at all, so user can read smth that was written some time ago... Esp, this is useful for operators.

Exactly ( http://strongdc.sourceforge.net/forum/view...f=14&t=5376 ) So now this topic can be moved to 'Confirmed' or even 'Closed'

The bug concerns nick copying/sending public messages. How to see: 1) rightclick any nick in Chat and do "Copy nick". 2) rightclick another user in the userlist and do "Send public message". You'll see that first nick (that was copied in the 1st step) was placed in msg window, but, of course, message should be addressed to the second one. PS. I've asked to test my friends this on StrongDC 2.12 -- they have the same result. Maybe this is a feature... but then it's a strange one ;)

Мауbe because it's a standard Window (MessageBoxW) that depends only on OS ?

We're all humans.... OK then, so we can close (or delete) *this topic.

What about forbidding to create new topics in http://forums.apexdc.net/index.php?showforum=47 for users? I think all topics in that forum MUST be moved there by moderators from root bugtracker forum. Quite easy, but useful...

1) You're mistaken with the subforum 2) The same crash reported here http://forums.apexdc.net/index.php?showtopic=2611

Well, now it's interesting to dig up where... Where is my debugger, btw? Hope i didn't drunk it yesterday... (lol) Call stack: > StrongDC.exe!stlp_std::priv::_String_base<char,stlp_std::allocator<char> >::_M_Finish() Line 89 + 0x26 bytes C++ StrongDC.exe!stlp_std::basic_string<char,stlp_std::char_traits<char>,stlp_std::allocator<char> >::size() Line 485 + 0x2b bytes C++ StrongDC.exe!stlp_std::basic_string<char,stlp_std::char_traits<char>,stlp_std::allocator<char> >::rfind(char __c='\', unsigned int __pos=4294967295) Line 561 + 0x8 bytes C++ StrongDC.exe!dcpp::Util::getFileName(const stlp_std::basic_string<char,stlp_std::char_traits<char>,stlp_std::allocator<char> > & path={...}) Line 177 + 0xc bytes C++ StrongDC.exe!QueueFrame::moveDir(_TREEITEM * ht=0x0013ffe8, const stlp_std::basic_string<char,stlp_std::char_traits<char>,stlp_std::allocator<char> > & target={...}) Line 672 + 0x15 bytes C++ StrongDC.exe!QueueFrame::moveSelectedDir() Line 655 + 0x47 bytes C++ StrongDC.exe!QueueFrame::onMove(unsigned short __formal=0, unsigned short __formal=0, unsigned short __formal=0, unsigned short __formal=0) Line 139 + 0x16 bytes C++ StrongDC.exe!QueueFrame::ProcessWindowMessage(HWND__ * hWnd=0x003105d6, unsigned int uMsg=273, unsigned int wParam=1098, long lParam=0, long & lResult=-858993460, unsigned long dwMsgMapID=0) Line 76 + 0x44 bytes C++ StrongDC.exe!ATL::CWindowImplBaseT<WTL::CMDIWindow,ATL::CWinTraits<1456406528,64> >::WindowProc(HWND__ * hWnd=0x01ab5550, unsigned int uMsg=273, unsigned int wParam=1098, long lParam=0) Line 3081 + 0x27 bytes C++ user32.dll!77d48709() [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll] user32.dll!77d487eb() user32.dll!77d70494() user32.dll!77d489e8() StrongDC.exe!WTL::CMessageLoop::Run() Line 989 + 0xf bytes C++ StrongDC.exe!Run(wchar_t * __formal=0x0002099c, int nCmdShow=1) Line 474 + 0x8 bytes C++ StrongDC.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * __formal=0x00000000, wchar_t * lpstrCmdLine=0x0002099c, int nCmdShow=1) Line 606 + 0xd bytes C++ StrongDC.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C StrongDC.exe!wWinMainCRTStartup() Line 182 C kernel32.dll!7c816d4f() kernel32.dll!7c8399f3() Crash occurs when calling getFileName() in line QueueManager::getInstance()->move(ii->getTarget(), target + Util::getFileName(ii->getTarget())); invoid QueueFrame::moveDir(HTREEITEM ht, const string& target) so ii->getTarget() returns bad string. So now it's need to track why ii->getTarget returns garbage.

No, this was a misunderstanding from my side. I thought that you moved folder (i.e. renamed it in your FS) that was put into DL Queue. But I didnt know (till this moment) that i can move smth in DL queue... Ok, now i (probably) understand you, so i will try... PS. FAR is a popular file manager (h**p:/farmanager.com), but now I see that it doesnt matter. ----------------------------------------------------------- 3 minutes later: Yes, yes, yes!!! It crashed! Rightclick, then select rename/move and ... gotcha :blushing: So it's a bug... :crying: ...confirmed one.

Hmm, interesting... I cannot reproduce this crash. I did the following: I've chosen a large folder with many files and started to download it (the folder name contained some russian chars). When some files were copied, i renamed the target folder. But no crash occured: Apex created the folder again and continued to download files to it. Renaming was done via FAR 1.7. Can you please describe your action sequence a little bit detailed? Of course if you did the same as I described? PS. I'm using Apex 1.0.1 built from the latest STLport taken from SVN. Will try it with canonical build placed on website....

BM, of course i understand it that it's not a complete solution. That's actually not a problem for LANs where each user has his own IP. PS. Anyway, the DC++ is a strange thing over the Internet when speeds are limited. It has no ratio (like torrent), so there are no mechanisms to force people to upload data and avoid leeching. Please don't throw me with stones, but it's my (and very stable) point of view!

the translation of buttons/standard forum phrases wont lead to translation of forum content... I guess people who use forums learned words like 'quote' and 'reply'.. And my suggesstion is only a try to provide more known words in most-visited areas, f.e. website :blushing:

Maybe it's not so hard to close all but one connections that have the same IP... Will dig it how to implement.... If any positive results, I'll post in this topic. 2) mod has no public webpage yet, i'm too lazy... :blushing: we have only LAN-based forum where dev is discussed....

The ADC-based future is like World Communism... The everything will be OK when it comes Thanx for your posting, your answer saved me lots of time, because i planned to implement this in my Apex mod. So now I wont ever try.