Этот сайт создан как клуб русификаторщиков. Для нас существуют три основных правила.
1. Мы никому и ничего не должны!
2.Один пришедший на сайт толковый русификаторщик дороже всех пользователей.
3. Мы делаем русификаторы для своего сайта, но в оригинале ими могут пользоваться все в интернете.
Я правильно понял, что процедуры InitializeWizard можно переименовать, а оставить только одну. И вот в неё вставить обращение к этим, переименованным. Причем, в коде сначала должны идти переименованные процедуры, а только потом главная, т.е. так как ты показал в своем примере. Или порядок не играет роли? Хотя нет, наверное порядок важен.
function InitializeSetup(): Boolean;
begin
...
Result:=...
end;
begin
...
Result:=...
end;
begin
...
Result:=...
end;
Или надо их все объединять между общими begin...end, т.е. вот так
function InitializeSetup(): Boolean;
begin
begin
...
Result:=...
end;
begin
...
Result:=...
end;
begin
...
Result:=...
end;
end;
Или это вообще, все неправильно?! Хотя с процедурами этот вариант, наверное пройдет, а вот с функциями нет.
Меня что смущает, так это название переменной, которая возвращает значение функции - Result. Я пробовал давать другие имена (Result1, Result2... Result(n)), но компилятор ругается на неизвестные типы данных.
Наверное это все не к тебе.... Пожалуй, надо восполнить пробел по процедурам и функциям из области программирования. Извини, что отвлекаю глупыми вопросами.
Я пока еще в полном тумане......
Вот еще одна мысль посетила: - Как-то модульно можно это все сделать? Отдельно файл со скриптом на музыку, отдельно файл со сплэшскрином, отдельно файл со редизайном и т.д. А потом в скрипте на программу указать обращение к этим отдельным файлам сценария. Т.е. что нужно, то и прицепил к сценарию. И огород по объединению скриптов городить не нужно. А?
Короче, без 100 грамм не разберешься. Не, 100 грамм мало будет...
с процедурами - все правильно. переименовывая - ты вместо встроенной получаешь свои, которые вызываешь тогда, когда тебе нужно. с функциями-же - все совершенно неоднозначно. просто приведи содержимое своих функций и я покажу, как нужно сделать именно в твоем случае, поскольку с функциями всегда разное решение их объединения. А модульное строение скрипта - это да, но от объединения все равно никуда не уйти, компилятор все равно обрабатывает все это как одну портянку, и соответственно дублирования не допустит.
просто приведи содержимое своих функций и я покажу, как нужно сделать...
Вот смотри две функции InitializeSetup():
// функция инициализации звука
function InitializeSetup():Boolean;
begin
ExtractTemporaryFile('temp.wav');
Play(ExpandConstant('{tmp}')+' emp.wav');
Result:= True;
end;
// функция инициализации скина
function InitializeSetup():Boolean;
begin
ExtractTemporaryFile('temp.cjstyles');
LoadSkin(ExpandConstant('{tmp} emp.cjstyles'), '');
Result := True;
end;
Еще обратил, когда проверяю отдельно функцию воспроизведения звука, что если по каким-то причинам его проиграть не удалось (наверное функция возвращает False), то инсталлятор автоматически закрывается без каких-либо сообщений. Это можно как-то обойти? Т.е. если не удалось воспроизвести музыку, то продолжить работу инсталлятора, не закрывая его. Я так понимаю
В твоем случае функции объединяются просто, как процедуры, поскольку они маленькие, то лучше просто собрать все в одну.
function InitializeSetup(): Boolean;
begin
ExtractTemporaryFile('temp.wav');
Play(ExpandConstant('{tmp} emp.wav'));
ExtractTemporaryFile('temp.cjstyles');
LoadSkin(ExpandConstant('{tmp} emp.cjstyles'), '');
Result := True;
end;
по второму моменту, можно попробовать добавить в конце строчку:
if not Result then Result := true;
хотя, привязок результата к проигрыванию музыки нет, то скорей всего происходит крах инсталла при запуске команды Play, соответсвенно, нужно смотреть именно ее, в чем может быть причина.
Leserg, теперь смотри Вылет из установки бывает только на юникоде, так? На нескольких форумах уже отвечал, и тут недавно тоже. элементарное несоответствие типов. сопоставляем:
function sndPlaySound(lpszSoundName: PansiChar; uFlags: cardinal):Integer;
Procedure Play(filename:String);
тоесть, зявляем мы явный тип PansiChar, точнее, этот тип и является родным для функции, ну точнее, можно посмотреть на MSDN:
LPCTSTR можно представить как PAnsichar так и AnsiSrting, но никак не WideString, каковым в юникоде является тип string. отсюда - Procedure Play(filename:AnsiSrting); вот так будет правильно и работать будет как в анси, так и в юникоде.
но никак не WideString, каковым в юникоде является тип string
Это меня натолкнуло заглянуть в справку к Unicode версии Inno Setup. Там есть такая строка:
"If you want to compile an existing script that imports ANSI Windows API calls with the Unicode compiler, either upgrade to the "W" Unicode API call or change the parameters from "String" or "PChar" to "AnsiString". The "AnsiString" approach will make your [Code] compatible with both the Unicode and the non Unicode version."
В общем здесь сказано о том, о чем ты рассказал выше.
Заменил "String" на "AnsiString" и вроде бы работает . Спасибо, что потратил на меня свое время.
Leserg, мне нравится тратить время. это наверное, самый большой из моих минусов. с заменой в юникоде "String" на "AnsiString" нужно так-же быть аккуратнее, смело можно менять только в тех местах, где в этой перменной передается путь к файлу, в других случаях нужно уже смотреть точно параметры функций. многие API-функции имеют так-же юникодные аналоги, и это тоже нужно учитывать. в данном случае sndPlaySound относится к MMAPI, по сути довольно устаревшая и вроде-бы не имеет юникодных версий своих функций. в общем, головняк сплошной с этими функциями, которые берутся из системных библиотек
Gnom, с таким вопросом, видимо, лучше обратиться к автору программы, но все-таки, может, какую-никакую логику поясните? Суть в чем: В инсталляторе нескольких програм лежат два идентичных исполняемых файла программы, отличающиеся только именами.
В общем, посмотрел - файлы идентичны на 100%. Единственная мысль - заложенная возможность объединить в один инсталлятор х86 и х64 версии с флагом IsWin64, других предположений нет.