суббота, 30 мая 2009 г.

FlylinkDC++ r386 beta1

SetupFlylinkDC-r386-beta1.exe
народ ру:
SetupFlylinkDC-r386-beta1.exe

------------------------------------------------------------------------
r1918 | bripper60 | 2009-05-30 03:50:56 +0400 (Сб, 30 май 2009) | 4 lines

* Добавлен динамический прогресс-бар, появляющийся в строке статуса при хэшировании.
* При нажатии на прогресс-бар появляется диалог прогресса хэширования.

p.s.
Cобрано в VC++ 2010 beta1

18 комментариев:

dr.rivan комментирует...

а х64? 0_о

Pavel Pimenov комментирует...

x64 под VC++ 2010 глючит

Анонимный комментирует...

круто ты зделал:можна чтоб ты зделал,когда в трей закрываеш чтоб показывал сколька про хешировал ну на подобе закачки а то так не поймеш какие файлы про хешированы.спс зарание.

Анонимный комментирует...

а можно ли из долгого ящика под названием TODO достать всё, касающееся разделения локальных и остальных юзеров и ограничения скорости для нелокальных ?
уже несколько раз просили тут в блоге вас об этом
понятно, что времени не хватает и руки не доходят пока - я просто пытаюсь напомнить лишний раз, чтобы не забывали вообще об этом :)
спасибо за понимание сейчас и за реализацию полезной фичи в будущем :)

Анонимный комментирует...

нужно не ограничение скорости для нелокальных, а просто разделение на своих и дальних

просто когда бывает присосутся несколько нелокальных с небольшой скоростью и качают файл немалый по размеру - локальные, кто может скачать всё за секунды - вынуждены ждать
можно конечно поставить слотов побольше, но тогда когда все локальные разом качают - комп в ступор впадает тормозит

Анонимный комментирует...

вопрос такой : если у меня в настройках стоит, чтобы скачанные файлы сразу в шару не добавлялись - то тогда у них хэш тоже в NTFS-поток пишется на случай, если потом в шару добавлю или нет ?
другими словами - если скачанное, но не добавленное в шару сразу потом добавляю - берётся хэш из потока или хешируется с нуля ?

brain-ripper комментирует...

круто ты зделал:можна чтоб ты зделал,когда в трей закрываеш чтоб показывал сколька про хешировал ну на подобе закачки а то так не поймеш какие файлы про хешированы.спс зарание.Можно подумать, чтоб что-нибудь в этом роде реализовать. Только надо хорошенько подумать, а то будет с ходу не понятно - что это за прогоресс в трее такой: хэширование, скачка, загрузка... И как трактовать отсутствие прогресса - нет хэширования, или оно только началось и пока на нуле

9POCJIAB комментирует...

есть ли смысл ждать 64 с таким же функционалом??

Анонимный комментирует...

"the procedure entry point EncodePointer could not be located in the dynamic link library KERNEL32.dll" - эта дрянь есть только в SP2 или выше, а если SP2 нельзя поставить по уважительной причине, то что делать? вешаться? :(

Анонимный комментирует...

когда в чат пишешь то, что слушаешь в винампе или другом поддерживаемом плеере по команде /w - можно ли сразу вставлять магнет-ссылку на файл, который проигрывается ?

Slippery Jim комментирует...

Ощущение, что битрейт mp3-шек в чужой шаре не показывается вне зависимости от того, Флай или не флай на той стороне - это у меня личное или как?

Анонимный комментирует...

Почему когда тебе дают бан по шаре, изменив шару на нужное число, бан спадает,
Но если тебе ставят бан за слоты, тебе приходится после этого ждать еще минут 15 (даже если ты перезапускаешь хаб или перезапускаешь программу)

Анонимный комментирует...

опа
первый крэш со времен 815 сборки ((
2 файла дампа (150 метров и 75 кило)
куда кидать?
и скорее всего тот что поменьше ))

Анонимный комментирует...

в связи с крэшем, пригодилось бы окошечко: "Отправить дамп авторам? Да Нет"
Оперативность знаете ли.

Анонимный комментирует...

Кстати вот хотелось узнать.
Такая сильно полезная функция, как отключение медленных источников, когда-нибудь заработает? Или уже можно не ждать?
Там ведь причем можно было бы придумать разные интересные алгоритмы. Например, отслеживать среднюю скорость скачивания по данному файлу с подключавшихся источников.
Например, качаешь файл с трех разных человек: с двух со скоростью 500кб/с, с третьего - со скоростью 100кб/с. Допустим, остался последний блок, и он скачивается с самого медленного источника из этих трех. Вроде бы он сам по себе не очень медленный (100кб/с все же не самая плохая скорость), но на фоне двух других (которые в этот момент простаивают) - это в 5 раз медленнее. Соответственно в подобных ситуациях надо нафиг сбрасывать третье подключение и переключаться на одного из первых двух.
Это было бы жутко полезно. В отличие от прогрессбаров хеширования, которые, безусловно, тоже нужны, но реальной пользы от коих намного меньше.

Анонимный комментирует...

на самом деле всякие рюшечки и завитушечки в виде дополнительных прогресс-баров тоже нужны - этим можно не один десяток новых пользователей проги привлечь

только вот многие думающие люди за это время разбегутся и разработчикам останется только блондинок радовать своими нововведениями

извините, наболело ...
в целом я более чем доволен прогой - только вот на самом деле есть вещи гораздо более важные, чем прогресс-бары и битрейты, которые нахрен никому не нужны

Анонимный комментирует...

на самом деле есть вещи гораздо более важные, чем прогресс-бары и битрейты, которые нахрен никому не нужныВот именно, функционал и так приличный. Я бы на месте автора делал голосование, нужен ли кому-то прогресс-бар в строке состояния или нет, и т. д.

Tramp комментирует...

VC++ 2010 beta1

Зачем?