Nep Moderator Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору FAR Manager : http://www.farmanager.com (старый адрес http://www.rarlab.com)       Как правильно установить последнюю версию? 1. Скачайте FAR Manager 1.70 (1.75) и установите. 2. Скачайте последнее обновление после версии 1.70 (1.75) и перепишите файлы из архива в каталог с установленным FAR Manager 1.70 (1.75). 3. Скачайте последнюю сборку FAR Manager 1.71 и перепишите файлы из архива в каталог с установленным Far Manager. Там же скачайте последнее обновление стандартных плагинов и распакуйте его в подкаталог Plugins. Примечание: версия 1.75 RC0 является более стабильной и функциональной, чем релиз 1.70.   Где искать дополнительные плагины от сторонних разработчиков? 1. Плагринг. Долгое время не обновлялся, но все старые плагины лежат там. 2. Анонсы плагинов на официальном форуме. Теперь все новые плагины и обновления старых плагинов выкладываются на официальном форуме проекта.   Как самому собрать Far 2 x64? Far x64 - ночные сборки Инструкция   Те, кому лень собирать самим, могут скачать отсюда: Far Manager v2.0 alpha build <..> x86/x64   "Ночные" сборки линейки 2.0 (прим.: версия 2.0 находится в стадии разработки и не рекомендуется для повседневного использования) Информация о плагинах для версии 2.0   Пользовательские сборки FAR Manager   » PlugRinG viewer - плагин к Far - онлайн-браузер по базе плагринга   » FAR plugins manager - внешний менеджер плагинов » FAR Exception + ExcDump library + HaronDemangle - дополнительные dll для записи в лог отладочной информации при схлопывании far на фатальной ошибке.   Устаревшие ссылки   Примечания С 13 декабря 2008 г. произошло переименование веток: ANSI-ветка 1.71 превратилась в 1.75, а Unicode-ветка получила номер версии 2.0 вместо 1.80. Т.е. теперь версии 1.хх это ANSI ("старый" FAR), а версии 2.хх - Unicode ("новый" FAR). Эти ветки сильно различаются по способу взаимодействия с плагинами и системой! При обновлении ANSI-ветки 1.хх более старые версии плагинов могут работать в более новом FAR, но более новые плагины в большинстве случаев требуют обновления FAR (см. документацию).   Unicode-плагины в ANSI-версии FAR не работают - у них иной способ взаимодействия (API) с Far.exe, поэтому даже не пытайтесь их использовать в FAR версии ниже 1.80. При обновлении Unicode-версии FAR 1.80/2.0 обращайте внимание на номер сборки: следует обязательно обновить все плагины для сборок 677/680/684, иначе они не будут работать. ANSI-плагины (кроме тех, которые работают в Редакторе) можно применять в Unicode-версии FAR, в меню плагинов (вызываемом по F11) они будут помечены значком [A] справа от их имени. Unicode-плагины в FAR 1.80/2.x никаким значком после имени не помечаются. Unicode-версия FAR 1.80/2.x требует как минимум Windows 2000, т.е. она работает только в Windows 2000/XP/2003/Vista/2008. Всего записей: 41940 | Зарегистр. 24-06-2001 | Отправлено: 11:02 10-04-2006 | Исправлено: Maz, 22:36 01-03-2017

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Ajaja   Насчёт забагованности не согласен, пользуюсь именно 2.0. По функциональности лично меня она устраивает. А вот что мне не по душе, так это ошибка в плугине FarHints - только что пробовал новый вариант. На шаблонах OOo 3.0.1 из-за него Far.exe по прежнему завершается аварийно. Обидно. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 15:11 21-02-2009

Benchmark Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Ajaja Цитата: Тот же viewer в v2 до сих пор не знает что у файлов в кодировке UTF-8 может быть BOM и карячит первые символы Да, может. Но тут надо сказать, что BOM в случае UTF-8 никак не влияет на порядок байт, потому часто и не добавляется. Но обрабатывать этот случай, конечно, необходимо.   А так да, пока что вьювер и редактор имеют кучу проблем с юникодом вдобавок к косметическим глюкам.  Например редактор открывает файл из одной строчки: language=arc.english.txt в виде строки китайских иероглифов Что интересно, вьювер отрабатывает нормально.   Плюс при просмотре юникодных текстовых файлов "сбивается" кодировка и вместо "нестандартных" букв получаем квадратики (F3 -> стрелка курсора "вправо" -> видим баг).   При редактировании кодировка сбивается на квадратики при удалении первого же юникодного символа.     Плюс неверно определяется длина юникодной строки для кодировок, где символ может занимать более одного знакоместа. Причем это не только в редакторе, но и в самом файл-менеджере (например при переименовании файла с юникодным именем).   В общем, там еще править и править. Всего записей: 6923 | Зарегистр. 01-10-2002 | Отправлено: 15:41 21-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Баг с плугином FarHints требует вмешательства разработчика плугина - его исходники закрыты, и кроме автора ошибку никто не исправит, даже с учётом обновления FarHints для FAR2 756+ и последних ConEmu (новая FarHints.dll V2 выложенная 21.02.2009) - всё равно, при попытке получить хинт документов OpenOffice на секунду видна иконка OOo, и далее процесс Far.exe завершается аварийно, даже отладчик не успевает среагировать, хотя причина сбоя в том, что именно плугин FarHints записывает в одной из своих процедур адрес перехода 0x00000000 и осуществляет по нему переход с возвратом в процесс Far.exe по тому же адресу 0x0000000. Данный неверный переход формирует код FarHins.dll. Ещё раз напоминаю ему об этом явлении. Готов помочь в его проверке.   P.S.   Данный баг уже достал, а автор на него ноль внимания. Автора его "аналога" по степени глючности для Total Commader просто забыли, идею плугина реализовали десятки других людей, а он сам сейчас всех просит попробовать его новые разработки и напоминает о своих заслугах.   DrKnS Цитата: drkns 21.02.2009 14:56:50 +0200 - build 779   1. Автоопределение кодовой страницы во вьювере, аналогичное редакторному.   2. В PrepareDiskPath криво обрабатывались отностительные пути вида c: или d:dir   3. параметр Layout\PassiveFolder удалён, т.к. есть Panel\<Left|Right>\<Folder|Focus> СПАСИБО! Ещё бы Максим свои ошибки исправил. - было бы прекрасно. Всегда рад тебе помочь чем могу. Сейчас буду проверять что у тебя получилось, но зная тебя уверен что всё будет работать отлично. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 17:06 21-02-2009 | Исправлено: Victor_VG, 17:24 21-02-2009

Benchmark Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: 1. Автоопределение кодовой страницы во вьювере, аналогичное редакторному   Учитывае написанное мной чуть выше: Цитата: Например редактор открывает файл из одной строчки: language=arc.english.txt в виде строки китайских иероглифов Что интересно, вьювер отрабатывает нормально   не уверен, радоваться или пока подождать. Всего записей: 6923 | Зарегистр. 01-10-2002 | Отправлено: 18:01 21-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Benchmark   А мы с тобой посмотрим тот 2.0.779.2590.1 что скомпилировал сейчас. Выложил отдельно gcc вариант, используем его как тестовый. Надо бы заодно и FarHinst на нём лишний раз проверить. Не нравятся мне эти ошибки с переходом по адресу 0х00000000. Как будто где-то ошибка не в плугине, а в библиотеках самого компилятора которые он линкует. Тут серьёзно надо копаться. Чувствую один Максим эту задачу вряд ли вытянет, помочь надо парню всем вместе. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 18:12 21-02-2009 | Исправлено: Victor_VG, 19:16 21-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Ajaja   А ты в чём собираешь, коли не секрет? Просто у меня и VC++ 9 и gcc есть. Да и голове идея крутится - попробовать собрать в gcc с заданием опций формирования многопроцессорного кода, хотя и прекрасно понимаю что с одно процессорным алгоритмом этот опыт - пустая трата времени и сил. Заодно и новый ConMan 2.34.2 глянул - как при попытке сравнения собранный в gcc плугин Advanced Compare "ронял" Far из-за ошибки ConMan в блоке управления памятью дочернего процесса, так и на Far 2.0.779.2590 + ConMan 2.34.2 ничего не изменилось. А жаль, похоже Макс увлечён только собственной новой "игрушкой", а исправлять ошибки которые уже найдены даже не собирается. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 22:04 21-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Ajaja   Понял. А я комбинацией - всё кроме EMenu в gcc-4.3.2-tdm2, а его в студии 9 про, вернее от неё у меня один с++ стоит - остальное я в BSD делаю - привычнее. Для сборки одного плугина "огрызка" хватает.   Могу порадовать - вроде ребята смогли сделать нечто интересное: Цитата: drkns 22.02.2009 02:41:43 +0200 - build 782   1. Дополним vc-проект и починим мейки.   warp 22.02.2009 02:11:00 +0300 - build 781   1. Бонус-тайм. Если повезет может определяться все, что умеет определять автодетектор кодировок от      Mozilla. Побочные эффекты в наличии.        До починки make-ов собрать можно будет только проектом!   2. Ну и диалог сохранения файла поправим в размерах.   drkns 21.02.2009 22:13:13 +0200 - build 780   1. UTF8 может определяться и без наличия сигнатуры (если повезёт   2. В диалог сохранения добавлена опция, определяющая, надо ли писать в файл сигнатуру.   3. Mantis#0000706: opening very short file gives messed up encoding    Ужесточён алгоритм определения UTF16 LE/BE. Пусть уж лучше будет ложный ascii, чем ложный уникод.   Сейчас EMenu соберу и буду пробовать. А Максим - увлёкся игрушкой и на всё плевать. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 04:32 22-02-2009 | Исправлено: Victor_VG, 04:34 22-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Ajaja   Этот алгоритм - он и в Gecko - ядре Mozilla если кодировка "скинута", т.е. тэг <meta http-equiv="Content-Type" content="text/html; charset= ... "> отсутствует иногда в такой ситуации не точно сработает. Остальное и я поглядел - работает, вот теперь можно сказать что общий труд увенчался успехом. А как я и сказал, Maximus5 увлёкся новой игрушкой в виде ConEmu, а к сбойному FarHints охладел. А ведь кроме него его исправить больше некому. Да похоже ему это и не нужно - написал и забросил.   О... уже 2.0.784.2603 Цитата: t-rex 22.02.2009 12:12:26 +0200 - build 784   1. Добавил в nsUniversalDetectorEx.h конвертацию имён в nCodePage для всех поддерживаемых фаром таблиц которые может вернуть мозиловский детектор.   2. Удалил prmem.c из корня ибо он есть и в UCD. Надо проект обновить.   drkns 22.02.2009 11:39:41 +0200 - build 783   1. Криво работала вставка вертикальных блоков из буфера обмена. Компилим. Во всяком случае заодно уже и NSIS обновил до 2.44 - ночью письмо пришло с sf.net.   А в одном месте баг-то имеется, и любопытный - в структуре VERSION_INFO имена полей выводятся "кракозябрами" если интерфейс Far переключён на русский язык: Данная ошибка появилась после 2.0.778. Видимо надо копать в связке "враппер-мозиловский детектор" - там неверно передаётся кодировка, во всяком случае у меня на подозрении /unicode_far/wrap.cpp - предполагаю, что ошибка в нём. Во всяком случае, при переключении на английский язык интерфейса Far данное явление исчезает. Проявление ошибки не зависит от языка справочной системы Far - на её проявление влияет исключительно только язык интерфейса (панелей). ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 12:55 22-02-2009 | Исправлено: Victor_VG, 14:36 22-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору AlVlS   Ты прав. но точное место где возникает ошибка я нашёл - это не враппер как я считал, а плугин verinfo.dll, а если ещё точнее, то его русский языковый файл VerInfoRus.lng, конкретно вот этот блок: Цитата: .Language=Russian,Russian (Русский) "Язык             :" "Название продукта:" "Версия продукта  :" "Описание файла   :" "Версия файла     :" "Оригинальное имя :" "Внутреннее имя   :" "Компания         :" "Копирайт         :" "Торговая марка   :" "Комментарий      :" Замена его значений на английские мгновенно снимает проблему. А это уже повод для подробного исследования причины её возникновения. Сброс кэша плугинов у меня делается автоматически при установке - я этот фокус знаю, и в скрипте стоит команда удаления кэша: Код: Section -Post   DeleteRegKey HKCU "Software\Far2\PluginsCache" ...   Этот блок кода отрабатывается всегда. Я его поставил в скрипт ещё тогда когда его писал.   А вот новинка: Цитата: drkns 22.02.2009 12:52:54 +0200 - build 785   1. Мелкие глюки при сохранении файла в редакторе и c определением кодировки во вьювере.   2. Используем IsSlash() вместо '\\' везде, где надо.   3. Обновил проект. Сейчас соберу. No problem.   2.0.785.2605 собрал, ошибок не заметно, заодно и баг с версией пришиб - ну не заметил я его, мимо проходил. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 16:47 22-02-2009 | Исправлено: Victor_VG, 18:25 22-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Far 2.0 alpha build 785/786 x86   Баг в функции IsSlash() - пошёл сразу после билда 784 - в 785 и 786. Проявляется при копировании или пересылке файлов в подкаталог USB Flash/IEEE-1394 носителя с файловой системой FAT/FAT32. На жёсткие диски с файловой системой NTFS  ошибка не воздействует, хотя лишний слэш в конце имени каталога назначения всё равно добавляет в формате <каталог_приёмник>\<имя_файла_источника>. Жирным выделен именно этот лишний слэш. Скриншот снимался на "чистой" машине, всё ключи настроек Far там предварительно были удалены. Лишний вставленный слэш виден в пути - N:\Far\Bin\\far-2.0.786-gcc.rar и вызывает ошибку копирования начиная с билда 785. В 786 она видна на снимке. До 784.2603 включительно ошибки нет, и введение новой функции позволяет однозначно локализовать точку ошибки в её вызове. Проявление ошибки не зависит от способа сборки бинарных модулей SVN ревизий 2605/2608 она проявляется и в сборке с офсайта, и в gcc сборке и в тестовых MS VC++ 9 сборках, следовательно это ошибка алгоритма копирования, а не компиляции или настроек.       Более того, ошибка находится в файле copy.cpp, скорее всего в строках 2087 - 2088: Код: if (IsSlash(strDestPath.At(Length-1)) && strDestPath.At(Length-1)!=L':')         strDestPath += L"\\";. Как я понимаю, тут нужна проверка вида: если имя приёмника указывает на каталог, и в конце его не стоит \, тогда добавляем его, иначе не добавляем.   В багрепорте на оффоруме этот вопрос поднял Александр Кряжев http://forum.farmanager.com/viewtopic.php?f=9&p=40932#p40932, но он не смог уточнить свои предположения о месте нахождения ошибки, хотя обнаружил её сразу в билде 2.0.785.2605. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 04:58 23-02-2009 | Исправлено: Victor_VG, 05:46 23-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору 2.0.787.2610   DrKnS СПАСИБО! С праздником тебя, дружище! Опечатку видел, где и говорили. Досадно, но бывает. Главное, собрал тестовый Far.exe - работает без замечаний. Ещё раз с Праздником!     И ещё, ребята переслали в качестве подарка:   В итоге, давно я так не смеялся: Цитата: Mantis#0000752: hex view on utf8 files shows each byte as 0x00 Description:     When viewing an utf8 file, and switching to hex view (F4), all data shows as 00. Is this the best way to handle this sort of situation?   Example: 0000000000: 00 00 00 00 00 00 │ ?áéíóú   When using shift+F8 to change codepage to ANSI, it displays corectly. When using F8 to switch between ANSI/OEM, it switches to ascii display and works too. Steps To Reproduce:       Additional Information:     To reproduce: 1. create new file with encoding set to UTF-8 2. write something and save 3. view the new file in hex mode (F3, then F4) Файл-то пустой, чего ещё от него ждать кроме 00 00 00 00 00 00? Короче, бред сивой кобылы этот баг репорт. Может создадим музей пользовательских ошибок? Это точно туда кандидат в раздел - САМАЯ БОЛЬШАЯ ГЛУПОСТЬ. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 12:20 23-02-2009 | Исправлено: Victor_VG, 16:25 23-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Снова "здорово!" одно чиним, остальное ломаем. Цитата: ------ Build started: Project: EMenu, Configuration: Release Unicode Win32 ------ Compiling... auto_sz.cpp Plugin.cpp .\Plugin.cpp(800) : error C2065: 'FCTL_FREEPANELITEM' : undeclared identifier .\Plugin.cpp(835) : error C2065: 'FCTL_FREEPANELITEM' : undeclared identifier .\Plugin.cpp(869) : error C2065: 'FCTL_FREEPANELITEM' : undeclared identifier Pidl.cpp OleThread.cpp MenuDlg.cpp FarMenu.cpp EMenu.cpp Generating Code... Build log was saved at "file://j:\Temp\17\fardev\emenu\obj\BuildLog.htm" EMenu - 3 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== И где сегодня собака порылась? В gcc не собирается, в MS VC++ 9.0 так же. Последний нормально собравшийся билд 2613, хотя с привычной уже руганью. Цитата: svs 24.02.2009 11:49:33 +0300 - build 791   1. Macro: N=atoi(S[,radix])    radix=0 ==> autodetect   yjh 24.02.2009 08:56:09 +0300 - build 790   1. Предупреждения кастингов в 64-бит   zg 23.02.2009 23:08:36 +0200 - build 789   1. FCTL_FREEPANELITEM больше нет. FCTL_GET[SELECTED|CURRENT]PANELITEM возвращают необходимый размер буфера.    все плагины, использовавшие FCTL_* - сломались. Теперь может помочь только правка исходников авторами. Ребята, поправьте пожалуйста быстрее...   В 793 SVN 2627 ситуация на данный момент та же. Ждём изменений и ASCII SVN-2531 от 24.02.2009 - список изменений уже видел, понял, без Вас лезть не считаю возможным дабы дров не наломать. Попытался grep поискать FCTL_FREEPANELITEM - не нашла, как понимаю надо эту структуру где-то явно объявить? ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 15:03 24-02-2009 | Исправлено: Victor_VG, 16:13 24-02-2009

Benchmark Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Еще одна ошибка, связанная с просмотром UTF-8.   Берем любой текстовый файл в UTF-8, жмем просмотр F3, а затем жмем F4 (hex view). Вместо 16-ричного вида файла видим полный бред.   С другими форматами такой ошибки не возникает. Всего записей: 6923 | Зарегистр. 01-10-2002 | Отправлено: 16:10 24-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Benchmark   Похоже на Mantis#0000752? Но, тогда там парень методику проверки описал не верно. Если создать пустой в UTF-8, то при сохранении 2.0.788 сохраняет 3 байта с кодом 0х000000 (это он показывает), т.е. в заголовок пустой заготовки записывает неверный BOM, а просмотр в любом HEX редакторе выводит иной код первых трёх байт 0хEFBBBF. И т.к. это наблюдается в в любом из тестированных Hex-редакторов и на Win и на BSD, то я считаю, что вьер Far.exe неверно интерпретирует Hex-значения, по крайней мере в первых байтах блока. Думаю, что дальше смотреть не стоит, а надо проверить алгоритм в Hex-просмотре. Где-то он ошибается. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 16:29 24-02-2009

Victor_VG Tracker Mod Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору sabio   Ну, тут ты наверное прав. Пошли в ПМ - подумаем. Не против?   Всё, проблема с EMenu решена в SVN 2632. DrKnS - СПАСИБО!   На данный момент не работают в новом (Far 2.0.796 SVN 2634): FarHints (UNICODE) 1.1.2 - хотя не вышибает Far, но ничего не выводит кроме общих данных о каталогах, да и у тех по нему размер и количество файлов в них равны нулю. qPleayEx, 7-Zip Alternative, Opera Cach - ждите, скоро будут переписаны, говорил с CrOm-ом, не дёргайте парня, как сделает - выложит.     WM Explorer и NTFS File Info - оба обновлены. DVDPanel, FontMan - требуют обновления. Font Manager хинт выводит, но если попытаться посмотреть свойства шрифта сразу Far.exe вышибает. Старые (ANSII) плугины вроде в большинстве своём работают. Пока бегло проверил - DriveInfo, Recycle Bin - эти работают, а Registry Brouser может и сбойнуть иной раз. Причины пока не понял. YAC похоже работает, но я им не пользуюсь, потому особо не проверял. ---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti Всего записей: 34387 | Зарегистр. 31-07-2002 | Отправлено: 18:36 24-02-2009 | Исправлено: Victor_VG, 02:06 25-02-2009

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117

Компьютерный форум Ru.Board » Компьютеры » Программы » FAR Manager (часть 2)

Widok (12-10-2009 17:34): Лимит страниц. Продолжаем здесь.

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование