Total Commander

AkulaBig писал(а):Как все-таки правильно запись делать?

Если имеется в виду текст с COMMANDER_PATH, находящийся в переменной ini_Buttonbar (например, %COMMANDER_PATH%\buttonbar.bar), то нужно раскрыть его с помощью Set:

Код: Выделить всё

# применение Set в ФЗ - раскрытие переменных вида %var% в переданном тексте 
ini_Buttonbar = Set(ini_Buttonbar)

Можно и прямо в функциях, конечно:

Код: Выделить всё

Local Buttonbar = IniRead("~/R", Set(ini_Buttonbar), "Buttonbar", "Buttonbar", "")

# в КЗ используем вычисляемую строку
IniRead /R Buttonbar %"Set(ini_Buttonbar)" "Buttonbar" "Buttonbar" ""

Loopback
Спасибо. То, что нужно. Единственное, что саму ini_Buttonbar я раскрыл:

Код: Выделить всё

Local ini_Buttonbar = IniGetSectionLocation(COMMANDER_INI, "Buttonbar")

А надо было раскрыть Buttonbar. Все получилось:

Код: Выделить всё

		Local Buttonbar = IniRead(ini_Buttonbar, "Buttonbar", "Buttonbar", "")
		SwitchIniSect(Set(Buttonbar), sect_Buttonbar, lng)

Orion9
Наконец-то я закончил переделку сборки на многоязычную. 2202 строки кода на Autorun. За время работы по переделки 2 новых плагина для ТС написал. Переделал две чужие программы для работы в плагинах ТС. Перекомпилировал все свои плагины для работы в ХР. Переделал файл настройки плагина TCMediaInfo. Смену языка все-же сделал без перезагрузки, хитрым образом сделав список пользовательских колонок. Все остальное перезагрузки не требует.
В общем огромный объем работы провел.

Loopback
Вопрос возник. Сегодня тестил свою сборку под ХР на виртуалке. Autorun вроде-бы работает на ХР. Судя по тому, что один из плагинов к Autorun. Есть такой плагин NagScreen. На ТС64 он сработал, на ТС32 выдал ошибку. ХР 64 СП2.
А вот весь остальной код, написанный мной, не работает вообще. Ни одной функции.
Можете объяснить в чем дело?

AkulaBig писал(а):Есть такой плагин NagScreen. На ТС64 он сработал, на ТС32 выдал ошибку.

Про плагин этот ничего не скажу, я его не писал.

AkulaBig писал(а):А вот весь остальной код, написанный мной, не работает вообще. Ни одной функции.
Можете объяснить в чем дело?

Нет, не могу. Я на XP регулярно запускаю, правда на 32-битной. До сих пор проблем не замечал. Вот сейчас запустил тестовую версию, навскидку всё нормально: переменные, вывод в заголовок, горячие клавиши, регистрация команд - всё работает, из последних тестов пример Orion9 с прогрессом тоже работает. MediaInfo ожидаемо не грузится, для XP нужны спецверсии dll.

Так что не очень понятно, что значит "весь". Не работать могут функции, для которых заявлена минимальная версия ОС > XP, но таких мало. Может что-то ещё не учёл, конечно, и оно не работает, но не всё же. Попробуйте потестировать, что-то отключить и начать с простейших функций.

Loopback писал(а):MediaInfo ожидаемо не грузится, для XP нужны спецверсии dll.

Может быть она и ломает весь код?

Loopback писал(а):Попробуйте потестировать, что-то отключить и начать с простейших функций.

Для этого мне и надо было ваше разъяснение. Теперь мне понятно, что плагин ХР поддерживает.

AkulaBig писал(а):Может быть она и ломает весь код?

Не похоже, её просто не может загрузить LoadLibrary.

AkulaBig писал(а):Теперь мне понятно, что плагин ХР поддерживает.

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

Loopback писал(а):Не похоже, её просто не может загрузить LoadLibrary.

Разобрался. Именно в MI была проблема. Как только установил версию под ХР, все заработало.
Извиняюсь за офтоп. Первая часть вопроса для темы TCMediaInfo, но чтобы не разрывать смысл поста. Вы-же с MI много ковырялись. Есть-ли очень серьезные изменения между 21.03 с поддержкой ХР и последней? Насколько я помню, даже поддерживаемые расширения изменились?
Хочется оставить версию под ХР. Но похоже проще MI для ХР рядом в папочку положить и проверять версию Винды в Autorun?

AkulaBig писал(а):Есть-ли очень серьезные изменения между 21.03 с поддержкой ХР и последней? Насколько я помню, даже поддерживаемые расширения изменились?

Проще всего посмотреть историю изменений. А уж важны ли эти изменения - каждый решает сам. Всё необходимое было и в более ранних версияx, но после была куча доработок и багфиксов. Каждый по отдельности вроде незначителен, но в совокупности очень немало.

Как бы ни было жаль, но XP мёртвая система. Я поддерживаю совместимость с ней, но это пока не было серьезной необходимости в новых функциях и не требует существенных трудозатрат.

AkulaBig писал(а):Но похоже проще MI для ХР рядом в папочку положить и проверять версию Винды в Autorun?

Я бы сделал именно так. Понятно, что лишний размер, но раз нужна XP - что поделать.

Ну или для XP просто не загружать библиотеку и поставить заглушку "не поддерживается", если её поддержка не очень критична.

Loopback писал(а):если её поддержка не очень критична

Мне она нафиг не нужна, но тут пришлось все мои плагины перекомпилить под ХР по просьбе. Есть еще потребность.
Ну и мне тут мысль пришла. Раз Гислер даже Вин 98 поддерживает, плагинописателям тоже-бы надо следовать пути гуру. Хотя-бы ХР поддерживать.

Loopback писал(а):Я бы сделал именно так

Я решил все-же не тратить место просто так и при установке сделать вариант выбора компонентов. Так как не только MI требует других версий для ХР. Плюс еще есть компоненты, которые можно будет выбирать при установке. Сборка от этого распухнет, но это не так страшно.

Как всегда не получается составить строку для использования DllCall:

Код: Выделить всё

Local TitleTabTC
DllCall("GetWindowTextW", "hwnd", AUTORUN_TCHANDLE, "wstr:768", @TitleTabTC, "int", 768, "int")

Заголовок ТС вывести удалось. Вот правильный код:

Код: Выделить всё

Static buf = Buffer(768)
DllCall("GetWindowText", "hwnd", AUTORUN_TCHANDLE, "ptr", buf.Ptr, "int", 768)
OutputDebugString(AUTORUN_TCHANDLE & " " & buf.GetStr())

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

Код: Выделить всё

Local hTabLeft = SendMessage(AUTORUN_TCHANDLE, 1074, 5, 0)

hTabLeft содержит число. Как я думаю это хэндл окна. Но

Код: Выделить всё

Static buf = Buffer(768)
DllCall("GetWindowText", "hwnd", AUTORUN_TCHANDLE, "ptr", buf.Ptr, "int", 768)
OutputDebugString(hTabLeft & " " & buf.GetStr())

возвращает пустое значение.
Проверил в mvs, все стало ясно. У табов нет общего заголовка. В связи с этим возник вопрос.
Можно-ли как-то отследить режим показа колонок? Про SpecialView из wincmd.ini знаю. Только вот значения туда не пишутся в режиме реального времени.

Можно ли добавить функцию двойного щелчка в SetHotkeyAction?

AkulaBig писал(а):Вот правильный код

Можно и так, но первый тоже был правильный. Похоже, какой-то ещё баг.

AkulaBig писал(а):Можно-ли как-то отследить режим показа колонок?

Если имеется в виду номер выбранного режима просмотра (краткий, подробный, пользовательский), то можно, делал когда-то, но способ довольно кривой и громоздкий, через открытие контекстного меню с последующим его уничтожением. Сделано на основе идеи из TCFSTools.

[cut]

Код: Выделить всё

Global g_SelMenu = 0
Global g_ModeRes = -1
 
RegisterCommand 60068 TestGetSel
 
Func TestGetSel(lParam)
  MsgBox(GetSelectedMode(RequestCopyDataInfo("A")))
EndFunc
 
# register WM_INITMENU
SetMessageAction /P /S 278 "MenuProc"
 
Func GetSelectedMode(sPanel)
    g_ModeRes = -1
    g_SelMenu = sPanel = "R" ? 2 : 1
    SendCommand(g_SelMenu = 2 ? 170 : 70)
    Local nTimeout = 300
    While g_ModeRes = -1 And nTimeout > 0
      Sleep(10) 
      nTimeout -= 10
    Wend
    Return g_ModeRes = -1 ? 0 : g_ModeRes
EndFunc
 
Func MenuProc(hWnd, nMsg, wParam, lParam)
    If g_SelMenu Then 
        g_ModeRes = FindSelectedAndClear(wParam, g_SelMenu = 2)
        g_SelMenu = 0
    EndIf
EndFunc
 
Func FindSelectedAndClear(hMenu, bRight)
    Local nCount = DllCall("GetMenuItemCount", "handle", hMenu)
    If nCount = 0 Then Return 0
    
    Local Result = 0
    Static lpmii = Buffer(AUTORUN_TCARCH = 64 ? 80 : 48)
    lpmii.Zero()
    lpmii.SetNum(0, "uint", lpmii.size, "uint", 1) # MIIM_STATE
    For i = nCount - 1 to 0 Step -1
        DllCall("GetMenuItemInfoW", "handle", hMenu, "uint", i, "bool", 1, "ptr", lpmii.ptr)
        If lpmii.GetNum(12) = 0x8 Then # MFS_CHECKED
            Switch i
                Case 0
                    Result = bRight ? 201 : 101
                Case 1
                    Result = bRight ? 202 : 102
                Case 2
                    Result = bRight ? 200 : 100
                Case 3
                    Result = bRight ? 169 : 69
                Else
                    Result = 70 + i - 7
                    If Result < 100 Then
                        If bRight Then Result += 100
                    Else                        
                        Result += (bRight ? 7030 : 6530) - 100
                    EndIf
            EndSwitch
        EndIf
        DllCall("RemoveMenu", "handle", hMenu, "uint", i, "uint", 0x400)
    Next
    Return Result
EndFunc

[/cut]

yahuu писал(а):Можно ли добавить функцию двойного щелчка в SetHotkeyAction?

Наверно имелось в виду ControlSetMouseAction? В любом случае, к сожалению, нет. Есть технические сложности.

Loopback писал(а):но первый тоже был правильный

Не ожидал.

Loopback писал(а):Похоже, какой-то ещё баг.

Надо попробовать заменить "wstr:768" на "ptr".

Loopback писал(а):Если имеется в виду номер выбранного режима просмотра (краткий, подробный, пользовательский), то можно

Спасибо, потестю. Я тоже придумал решение. Можно с использованием cm_CopyHdrFileDetailsToClip попробовать. Мне достаточно отличать пользовательский режим отличать от всех других. Причем кажется уже даже не надо номер набора различать. Так что достаточно какой-нибудь уникальный хидер придумать. Но через контекстное меню тоже интересный вариант.

Добавлено спустя 12 минут:

Loopback
Попробовал вот так:

Код: Выделить всё

Local TitleTabTC
DllCall("GetWindowTextW", "hwnd", AUTORUN_TCHANDLE, "ptr", @TitleTabTC, "int", 768, "int")
OutputDebugString("Title TC " & TitleTabTC)

Выводит 0.

Добавлено спустя 10 минут:

Loopback писал(а):можно

Потестил. Отлично работает через кнопочку. Спасибо.

AkulaBig писал(а):Не ожидал.

Так синтаксис же не из ниоткуда появился

То что не работает - это баг, регресс с версии 2.2.17.

AkulaBig писал(а):Попробовал вот так

А вот так неправильно. Вместо буфера с указанной третьим параметром длиной, который ожидает GetWindowText, будет передан нулевой указатель.

Синтаксис вида "wstr:768" специально был сделан для упрощения работы с простыми буферами, чтобы не приходилось каждый раз задействовать Buffer, т.к. огромное количество API-функций использует буфер для возврата значений. Аналогичный механизм сделан и в Autoit (там в DllCall безальтернативно выделяется 64К буфер для строчных типов), а в AHK необходимо предварительно задать ёмкость переменной.

Синтаксис переменной с @ применим только к значениям, переданным по ссылке: типы со * (например int*) и str/wstr (которые по сути char*/wchar*). Остальные типы никак не меняют значение переменной.