.: NSIS - все вопросы :. часть 2.

[MKN]

iglezz, подскажи пожалуйста, как поместить в собственное окно (CreateWindowEx) чекбоксы и кнопки ?
Про размещение текста инфа есть, про прочее - не нашёл... Вероятно нужен какой то спец стиль ?

[iglezz]

MKN, Все стандартные контролы создаются одинаково через CreateWindowEx (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-createwindowexw)/CreateWindow (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-createwindoww), только у простого текста будет ClassName STATIC, у кнопки - BUTTON и т.д.

[MKN]

iglezz, т.е. в собственном окне, созданным с помощью CreateWindowEx, можно создать ещё 10 чекбоксов и кнопок ?
Хмм... Никак не получается...

[iglezz]

MKN, для вновь создаваемых окон-детей (в терминологии WinAPI) нужно в функции CreateWindowEx указать дескриптор окна-родителя.
В качестве микро-дополнения к моему примеру на прошлой странице: ${NSD_CreateCheckBox} 40u 5u 40u 20u "111.1"
Pop $hChildButton1
System::Call 'user32::SetParent(i$hChildButton1,i$hButtonOpt11)i.R0'

SetParent поменяет родителя с окна nsDialogs на кнопку $hButtonOpt11, координаты x,y будут задавать положение относительно нового родителя.
Тоже самое можно сделать и через System::Call 'user32::CreateWindowEx... + SendMessage ... ${WM_SETFONT}

Такие детки будут прятаться/показываться/перемещатся вместе с родителем.
Сразу проблема - навешивание функций-обработчиков через ${NSD_OnClick} и т.п. не работает для таких деток. Так как события получает родитель, который должен иметь обработчик этих событий. Обработчик написать не проблема, а вот как в nsis получить дескриптор функции-обработчика (необходим для установки функции обработчиком) - хз
Доступное костыльное решение (больше костылей богу костылей!) -- менять родителя туда-сюда (окно nsDialogs <--> своё окно)


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

[MKN]

Подскажите, в чём проблема ? - не подключается !include "CommCtrl.nsh"
При компиляции ошибка :

!include: "CommCtrl.nsh" (UTF8)
Bad text encoding: CommCtrl.nsh:2
!include: error in script: "CommCtrl.nsh" on line 2

(на второй строке хедера всего лишь - !define COMMCTRL_INCLUDED )

Пробовал штук пять вариантов CommCtrl.nsh. Без результата.
NSIS 3.8.0.0 WINDOWS 7 X64

C NSIS 3.0 всё нормально

[iglezz]

!include: "CommCtrl.nsh" (UTF8)
Bad text encoding: CommCtrl.nsh »
Неверно распознало кодировку как UTF-8 и файл в итоге содержит некорректные для UTF-8 символы. Например в !define COMMCTRL_INCLUDED будет буква O,E,.. из кириллицы.
Архив с nsis.sourceforge.io/Header_file_for_Listview (https://nsis.sourceforge.io/Header_file_for_Listview) такой проблемы не имеет, CommCtrl.nsh там в кодировке ANSI/ACP (только пришлось самому дописать отсутствующий !define _COMMCTRL_NSH_VERBOSE 1)

Этот тип ошибок лечится принудительным указанием кодировки: !include /charset=кодировка файл

[MKN]

там в кодировке ANSI/ACP (только пришлось самому дописать отсутствующий !define _COMMCTRL_NSH_VERBOSE 1) »
Так я оттуда и использую... Может дело в отсутствующем !define _COMMCTRL_NSH_VERBOSE 1 ?
Куда его правильно конкретно дописать ? (или просто 3 заменить на 1...)

[iglezz]

MKN, После скачивания и распаковки попытка компиляции примерок ведёт к ошибке !verbose: Invalid verbose level
Error in macro __NSD_LV_InsertColumn_Call on macroline 2
А вторая строка в этом макросе - !verbose ${_COMMCTRL_NSH_VERBOSE}.
Т.е. ошибка в том что _COMMCTRL_NSH_VERBOSE не задан.

Сейчас уже вижу, что мой быстрый фикс с добавлением !define _COMMCTRL_NSH_VERBOSE 1 был слишком быстрый, а правильный способ - замена _COMMCTRL_NSH_VERBOSE на _COMMCTRL_VERBOSE.
Это явно было последнее изменение перед запаковкой, т.к. даже отступ изменён с двух пробелов на табуляцию в строках с _COMMCTRL_NSH_VERBOSE

После исправления примеры компилируются без ошибок.

[MKN]

iglezz,
У меня __NSD_LV_InsertColumn_Call on macroline 2 на 1292 строке...
Изменил в макросе на !verbose ${_COMMCTRL_VERBOSE}. Ошибка...

Может скинешь мне свой рабочий CommCtrl.nsh ? И с какой версией NSIS проверяешь ? С 3.0 ведь работает безо всяких правок...

А !verbose ${_COMMCTRL_NSH_VERBOSE} у мня в хедере 14 штук... Все изменять ?
- Изменил - ошибка та же...
Преобразовал хедер в UTF-8 - та же ошибка...

[iglezz]

MKN, использую страндартную 3.08

[MKN]

использую страндартную 3.08 »
Удалил 3.08, переустановил(с https://sourceforge.net/projects/nsis/files/latest/download), скопировал твой CommCtrl.nsh, компилю - не работает, та же ошибка...
Удалил, установил 3.0.6.1 и т.д. - всё работает...
(Скрипт для теста - ранее всегда рабочий и даже пробовал пустой, только с CommCtrl.nsh)
И что это такое ? :cool: Позже попробую на др. компе...

ps Если в 3.08 заменить файл Program Files (x86)\NSIS\Bin\makensis.exe файлом из 3.06 - всё работает.
Прочие файлы на работу вроде как не влияют...

[iglezz]

MKN, Есть у меня виртуалка с Win7x32 чистая 6.1.7601 без обновлений и модификаций - работает корректно. Проблема, видимо, зависит от каких-то специфичных вещей в конкретных сборках винды.
Такое лечить правильнее указанием кодировки !include /charset=...
В порядке предположения, судя по исходникам, 3.07 у тебя должна так же сбоить.

Сверху ещё можно накатить обнову с https://github.com/kichik/nsis/.
Как минимум забрать папку Include\ - исправлен баг в LogicLib.nsh и обновление WinVer.nsh (определение вин 11 и билдов вин10 после 2021 года)

[MKN]

Как минимум забрать папку Include\ - исправлен баг в LogicLib.nsh и обновление WinVer.nsh »
Я туда периодически заглядываю, забираю обновы. Хотя WinVer.nsh там уже устаревший... (Сам принцип определения W11 в нём наверное не совсем удачный... Обновлять всё время каждый чих MS... не есть хорошо.)
Также видел у китайцев версии(ими названные) 3.0.8.1 - и x86 и даже x64. Причём с защитой от взлома, (вероятно имеется ввиду защита от декомпилляции), там почти все файлы другие и фейс китайский. (Но CommCtrl.nsh и с ними у меня не работает... :( )

[Flix]

Также видел у китайцев версии(ими названные) 3.0.8.1 - и x86 »
Это компиляция с последними изменениями из официального хаба, с момента релиза 3.0.8, плюс свои фишки и плюшки.

и даже x64 »
Это компиляция на базе неофициальной NSIS 64-bit (https://github.com/negrutiu/nsis), плюс все то же что и у х86.

Причём с защитой от взлома, (вероятно имеется ввиду защита от декомпилляции) »
Измените в исходниках exeheader (fileform.cpp, fileform.c, fileform.h) и любой декомпилятор (автораспаковщик) обломается.
Вот как раз это и наблюдается в хидере инсталляторов, собранных китайской версией. :yes:

[inco1]

Всем доброго дня.
Подскажите пожалуйста, как правильно и оптимально кратко прописать проверку всех серверных версий, чтобы получилось примерно так: "Если запущено на любой серверной виндовс, то...".

${If} ${IsWin2003}
${orIf} ${IsWin2003R2}
${orIf} ${IsWin2008}
${orIf} ${IsWin2008R2}
${orIf} ${IsWin2012}
${orIf} ${IsWin2012R2}
${orIf} ${IsWin2016}
${orIf} ${IsWin2019}
${orIf} ${IsWin2022}
DetailPrint "Running on Windows Server"
${EndIf}

Не на чем проверить.

[iglezz]

Должно быть достаточно ${If} ${IsServerOS} ...

[inco1]

Компилируется, но не уверен, что определит 2019 и 2022. Ведь мой вариант с ${IsWin2019} и ${IsWin2022} даже не компилируется, а только компилируется без них. Использую последнюю WinVer.nsh с хитхаба.

Нашел выход через реестр. Да и в этом варианте WinVer.nsh применять не нужно. Думаю, что в реестре для всех же серверных версий прописано

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion]
"InstallationType"="Server"

Function .onInit
Var /GLOBAL Server
ReadRegStr $Server HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion" "InstallationType"
FunctionEnd

Section
${If} $Server == Server
; ====Running on Windows Server"
${EndIf}
SectionEnd

[iglezz]

Компилируется, но не уверен, что определит 2019 и 2022 »
Информация по системе собирается при запуске nsis-инсталлятора (используя GetVersionEx (https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexw)).
Так что будет определять, пока сами мелкомягкие не сломают.

Ведь мой вариант с ${IsWin2019} и ${IsWin2022} даже не компилируется »
Логично, т.к. такие определения ещё не добавлены в WinVer.nsh

Нашел выход через реестр. Да и в этом варианте WinVer.nsh применять не нужно. Думаю, что в реестре для всех же серверных версий прописано »
Использование готовых библиотек и системных API вместо прямого чтения реестра и прочих конфигурационных сущностей рекомендуется для того, чтобы не тратить силы на реализацию того, что уже реализовано и не зависеть от разнородных структур/форматов одного и того же, но в разных версіях.

Те же ${IsWin2019} и ${IsWin2022} (как и любые другие проверки) можно легко добавить.
И даже в основной пакет исправления/дополнения можно добавить -- патчи/пулреквесты принимаюся на github/sourceforge

[inco1]

iglezz, Приветствую. Тут еще появилась проблема. Можно как то прописать, чтобы екзешник не запускал себя повторно , если найден процесс с его именем? Всё перерыл, ничего не подходит.

[Begin2Fly]

Можно как то прописать, чтобы екзешник не запускал себя повторно , если найден процесс с его именем? »
В справочнике NSIS есть раздел "Предотвращение множественности запуска" и "Работа с процессами с помощью NSIS", оба подойдут.