Hook standard Inno Setup checkbox - inno-setup

I added an InputOptionWizardPage for selecting tasks. This works fine, but I would like to add some custom functionality. One task is dependent on the other, so if the second checkbox is checked, the first should be checked and grayed out.
To do this, I need to access the properties of a checkbox. I found ways to do this using a completely custom page, where I would explicitly create the checkbox myself, but that would be a lot of work, since most of what I have so far is satisfactory.
How can I hook a checkbox that was created by Inno Setup, using MyInputOptionWizardPage.Add('This will add a checkbox with this caption')?

In attempt to answer your question directly.
I suspect you have used CreateInputOptionPage() which returns a TInputOptionWizardPage
This has the '.Add('Example')` method that you mention.
TInputOptionWizard descends TWizardPage which descends from TComponent which has the methods you need.
Update: Replaced original Code, this example is based on a review of options available in the InnoSetup source code of ScriptClasses_C.pas My original example I thought
that TRadioButton and TCheckBox where individual controls. They instead its one control called TNewCheckListBox. There is a couple of ways someone could pull this off but the safest way is to use.
This example is a complete Inno Setup Script.
[Setup]
AppName='Test Date Script'
AppVerName='Test Date Script'
DefaultDirName={pf}\test
[Code]
const
cCheckBox = false;
cRadioButton = true;
var
Opt : TInputOptionWizardPage;
function BoolToStr(Value : Boolean) : String;
begin
if Value then
result := 'true'
else
result := 'false';
end;
procedure ClickEvent(Sender : TObject);
var
Msg : String;
I : Integer;
begin
// Click Event, allowing inspection of the Values.
Msg := 'The Following Items are Checked' +#10#13;
Msg := Msg + 'Values[0]=' + BoolToStr(Opt.Values[0]) +#10#13;
Msg := Msg + 'Values[1]=' + BoolToStr(Opt.Values[1]) +#10#13;
Msg := Msg + 'Values[2]=' + BoolToStr(Opt.Values[2]);
MsgBox(Msg,mbInformation,MB_OK);
end;
procedure InitializeWizard();
var
I : Integer;
ControlType : Boolean;
begin
ControlType := cCheckBox;
Opt := CreateInputOptionPage(1,'Caption','Desc','SubCaption',ControlType, false);
Opt.Add('Test1');
Opt.Add('Test2');
Opt.Add('Test3');
// Assign the Click Event.
Opt.CheckListBox.OnClickCheck := #ClickEvent;
end;

You can also control tasks by parent relationships, it gives you a similar behavior to what your asking for but is not 100% the same. I know this does not answer your question directly, but intends to give you an option that maybe easier to implement. Doing it this way you don't have to worry about managing a custom dialog at all.
[Setup]
;This allows you to show Lines showing parent / Child Relationships
ShowTasksTreeLines=yes
[Tasks]
;Parent Tasks don't use "\"
Name: p1; Description: P1 Test;
;Child Tasks are named ParentTaskName\ChildTaskName
;Flag don't inheritcheck:Specifies that the task
;should not automatically become checked when its parent is checked
Name: p1\c1; Description: C1 Test; Flags: dontinheritcheck;
Name: p1\c2; Description: C2 Test;
;Default behavior is that child must be selected
;when a parent is selected
;this can be overridden using the:
;doninheritcheck flag and the checkablealone flag.
Name: p2; Description: P2 Test; Flags: checkablealone;
Name: p2\c1; Description: P2-C1 Test; Flags: dontinheritcheck;
Name: p2\c2; Description: P2-C2 Test; Flags: dontinheritcheck;

Related

How to rename program group in an Inno Setup update installation?

Our Inno Setup based installer creates a program group and included the major version number in its name, e.g. "Foo Bar 2". This was initially done by the directives
[Setup]
; Note: there is no AppId
...
DefaultGroupName={#AppName} {#AppVersion}
UsePreviousGroup=yes
Inno Setup remembers this name and reuses it. So for our upcoming new release, the major number is now 3 but the program group is not updated to "Foo Bar 3" and remains at "Foo Bar 2".
I have unsuccessfully tried removing {group} via [InstallDelete]. Deleting the group folder or renaming it also does not work for me.
Based on Bill's hint, I would like to know how I can strip the version number of the program group during an update installation.
If the user changed the name of the group and it does no longer match the default name, I'm not going to change it.
You will have to code the in Pascal Script. Something like this:
#define AppName "My Program"
[Setup]
DefaultGroupName={#AppName}
[Code]
var
GroupPath: string;
procedure InitializeWizard();
var
GroupName: string;
begin
if not WizardForm.NoIconsCheck.Checked then
begin
GroupName := RemoveBackslashUnlessRoot(WizardForm.GroupEdit.Text);
if GroupName = '{#AppName} 2' then
begin
GroupPath := AddBackslash(ExpandConstant('{autoprograms}')) + GroupName;
WizardForm.GroupEdit.Text := '{#SetupSetting("DefaultGroupName")}';
Log(Format('Old version Start menu group "%s" (path "%s") was found, ' +
'it will be deleted and new icons will be created in "%s"', [
GroupName, GroupPath, WizardForm.GroupEdit.Text]));
end;
end;
end;
procedure CurStepChanged(CurStep: TSetupStep);
begin
if CurStep = ssInstall then
begin
if GroupPath <> '' then
begin
Log(Format('Deleting old Start menu group from folder "%s"', [GroupPath]));
if DelTree(GroupPath, True, True, True) then Log('Successfully deleted')
else Log('Error while deleting');
end;
end;
end;
Use with care. Calling DelTree (particularly with Administrator permissions) can cause disaster, if the path is calculated incorrectly. You might consider deleting specific individual icon files only and then the empty (if) folder instead.
Though note that start menu groups shall not be used as per Windows guidelines since like Windows 7. So the correct solution would be to remove the group instead of renaming it.

Inno Setup - Check if a component is installed

What I really want to do is have Inno Setup uninstall a component, if it's unchecked in a subsequent run. But, if I'm not mistaken, that is not possible in Inno Setup (actually, correct me, if I'm wrong on this).
So, instead I want to make check function to see if a component is installed, so I can hide it during subsequent runs. I'm not sure where else to get that info other than the Inno Setup: Selected Components under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[AppName]_is1.
Now the problem is my Inno Setup: Selected Components is as,as2,as3,bs,bs2,bs3.
How can I detect as, without detecting as2 or as3?
Indeed, Inno Setup does not support uninstalling components.
For a similar question (and maybe better), see:
Inno Setup: Disable already installed components on upgrade
For checking of installed components, I'd rather suggest you to check for existence of files corresponding to the component.
Anyway, to answer your actual question: If you want to scan the Inno Setup: Selected Components entry, you can use this function:
function ItemExistsInList(Item: string; List: string): Boolean;
var
S: string;
P: Integer;
begin
Result := False;
while (not Result) and (List <> '') do
begin
P := Pos(',', List);
if P > 0 then
begin
S := Copy(List, 1, P - 1);
Delete(List, 1, P);
end
else
begin
S := List;
List := '';
end;
Result := (CompareText(S, Item) = 0);
end;
end;
Note that the uninstall key can be present in HKCU (not in HKLM) under certain circumstances.

How to use Pipeline pattern in Delphi

I am trying to implement a Pipeline pattern in my test project (How to make a Mutlithreded idhttp calls to do work on a StringList), but am having a struggle adapting TThread code to Pipeline pattern code. There are not many resources about how to use it.
I tried my best below, please DO NOT downvote, I know my code is messy but I'll edit my question if needed.
type
TForm2 = class(TForm)
...
private
procedure Retriever(const input: TOmniValue; var output: TOmniValue);
procedure Inserter(const input, output: IOmniBlockingCollection);
function HttpGet(url: string; var page: string): boolean;
end;
procedure TForm2.startButton1Click(Sender: TObject);
var
pipeline: IOmniPipeline;
i : Integer;
v : TOmniValue;
s : string;
urlList : TStringList;
begin
pipeline := Parallel.Pipeline;
pipeline.Stage(Retriever);
pipeline.Stage(Inserter).NumTasks(10);
pipeline.Run;
for s in urlList do
pipeline.Input.Add(s);
pipeline.Input.CompleteAdding;
// wait for pipeline to complete
pipeline.WaitFor(INFINITE);
end;
function TForm2.HttpGet(url: string; var page: string): boolean;
var
lHTTP: TIdHTTP;
i : integer;
X : Tstrings;
S,M,fPath : String;
begin
lHTTP := TIdHTTP.Create(nil);
X := TStringList.Create;
try
X.Text := lHTTP.Get('https://instagram.com/'+fPath);
S:= ExtractDelimitedString(X.Text);
X.Clear;
Memo2.Lines.Add(fPath+ ' : '+ M ); //how to pass the result to Inserter
finally
lHttp.Free;
end;
end;
procedure TForm2.Inserter(const input, output: IOmniBlockingCollection);
var
result : TOmniValue;
lpage : string;
begin
for result in input do begin
Memo2.Lines.Add(lpage);
FreeAndNil(lpage);
end;
// correect?
end;
procedure TForm2.Retriever(const input: TOmniValue; var output: TOmniValue);
var
pageContents: string;
begin
if HttpGet(input.AsString, pageContents) then
output := //???
end;
First of all - describe what is your specific problem. No one can stand behind your back and look at your computer and see what you are doing.
http://www.catb.org/esr/faqs/smart-questions.html#beprecise
You do imply your program misbehaves. But you do not describe how and why. And we do not know it.
As general remarks, you overuse the pipeline a bit.
all the worker procedures you pass to OTL - in your case those are Inserter and Retriever work in random threads. That means none of them should touch GUI without synchronizing - VCL is not multithreaded.
Also using TThread.Synchronize is a poor choice as I explained to you in the linked question. It makes program slow and it makes forms unreadable. To update your form use polling with fixed framerate. Do not update your form from inside OTL workers.
In other words, Inserter is not what you need. All you need from the pipeline here is its Input collection, a downloader procedure and the Output collection. Yes it is very simple task for the complex things pipelines are, that is why I mentioned two other simpler patterns before it.
You need TTimer on your form that would poll the Output collection at fixed framerate 2-3 times per second, and check that the collection is not finalized yet ( if it is - the pipeline got stopped ) and that should update GUI from a main thread.
You should not wait for a pipeline to finish inside your main VCL thread. Instead You should detach the pipeleine and let it run totally in background. Save the reference to the created pipeline into the Form's member variable so you could access its Output collection from the TTimer event and also can free the pipeline after its process run over.
You should keep that variable linked to the pipeline object until the downloading is over and set to nil (Free the objects) after that, but not before. You know about interfaces and reference-counting in Delphi, right?
For other OTL patterns like parallel-FOR read OTL docs about their .NoWait() calls.
You should make this Your form bi-modal, to have different set of enabled controls when downloading is running and when it is not. I usually do it with special Boolean property like I shown to you in the topic you linked.
Your user is not supposed to change the lists and settings while the pipeline is in progress (unless you would implement that realtime task changing, but you did not yet). This mode switcher would also be a good place to free the finished pipeline object when the switching is going from working mode to idle mode.
If you would want to play with the pipeline workers chaining, then you can put into the Input Collection not the URL strings themselves, but the array of those - the Memo1.Lines.ToArray(), then you can start with Unpacker stage that gets string arrays from the input collection (there would be only one, actually) and enumerate it and put the strings into stage-output collection.
This however has little practical value, it would even slow your program down a tiny bit, as the Memo1.Lines.ToArray() function would still work in the main VCL thread. But just to experiment with the pipelines this might be funny.
So the draft becomes like that,
TfrmMain = class(TForm)
private
var pipeline: IOmniPipeline;
property inProcess: Boolean read ... write SetInProcess;
...
end.
procedure Retriever(const input: TOmniValue; var output: TOmniValue);
var
pageContents, URL: string;
lHTTP: TIdHTTP;
begin
URL := input.AsString;
lHTTP := TIdHTTP.Create(nil);
try
lHTTP.ReadTimeout := 30000;
lHTTP.HandleRedirects := True;
pageContents := ExtractDelimitedString( lHTTP.Get('https://instagram.com/' + URL) );
if pageContents > '' then
Output := pageContents;
finally
lHTTP.Destroy;
end;
end;
procedure TfrmMain.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
if InProgress then begin
CanClose := False;
ShowMessage( 'You cannot close this window now.'^M^J+
'Wait for downloads to complete first.' );
end;
end;
procedure TfrmMain.SetInProcess(const Value: Boolean);
begin
if Value = InProcess then exit; // form already is in this mode
FInProcess := Value;
memo1.ReadOnly := Value;
StartButton.Enabled := not Value;
if Value then
Memo2.Lines.Clear;
Timer1.Delay := 500; // twice per second
Timer1.Enabled := Value;
If not Value then // for future optimisation - make immediate mode change
FlushData; // when last worker thread quits, no waiting for timer event
If not Value then
pipeline := nil; // free the pipeline object
If not Value then
ShowMessage('Work complete');
end;
procedure TfrmMain.Timer1Timer(const Sender: TObject);
begin
If not InProcess then exit;
FlushData;
if Pipeline.Output.IsFinalized then
InProcess := False;
end;
procedure TForm2.startButton1Click(Sender: TObject);
var
s : string;
urlList : TStringList;
begin
urlList := Memo1.Lines;
pipeline := Parallel.Pipeline;
pipeline.Stage(Retriever).NumTasks(10).Run;
InProcess := True; // Lock the input data GUI - user no more can edit it
for s in urlList do
pipeline.Input.Add(s);
pipeline.Input.CompleteAdding;
end;
procedure TfrmMain.FlushData;
var v: TOmniValue;
begin
if pipeline = nil then exit;
if pipeline.Output = nil then exit;
if pipeline.Output.IsFinalized then
begin
InProcess := False;
exit;
end;
Memo2.Lines.BeginUpdate;
try
while pipeline.Output.TryTake(v) do
Memo2.Lines.Add( v.AsString );
finally
Memo2.Lines.EndUpdate;
end;
// optionally - scroll output memo2 to the last line
end;
Note few details, think about them and understand the essence of those:
Only FlushData is updating the output memo. FlushData is called from the TTimer event or from the form mode property setter. Both of them only are ever called from the main VCL thread. Thus FlushData is NEVER called form background threads.
Retriever is a free standalone function, it is not a member of the form and it knows nothing about the form and has no reference to your form instance(s). That way you achieve both goals: you avoid "tight coupling" and you avoid a chance of mistakingly access the form's controls from a background thread, which is not allowed in VCL.
Retriever functions work in background threads, they do load the data, they do store the data, but they never touch the GUI. That is the idea.
Rule of thumb - all methods of the form are only called from the main VCL thread. All pipeline stage subroutines - bodies of the background threads - are declared and work outside of any VCL forms and have no access to none of those. There should be no mix between those realms.
you throttle GUI update to a fixed refresh rate. And that rate should be not too frequent. Windows GUI and user eyes should have time to catch up.
Your form operates in two clearly delineated modes - InProcess and not InProcess. In those modes different sets of functions and controls are available to the user. It also manages mode-to-mode transitions like clearing output-memo text, alerting user of status changes, freeing memory of used threads-managing objects (here: pipelines), etc. Consequently, this property only is changed (setter is called) from main VCL thread, never from background workers. And #2 helps with that too.
The possible future enhancement would be to use pipeline.OnStop event to issue a PostMessage with a custom Windows Message to your form, so it would switch the mode immediately as the work is done, not waiting for the next timer olling event. This might be the ONLY place where pipeline knows anything about the form and has any references to it. But this open the can of Windows messaging, HWND recreation and other subtle things that I do not want to put here.

Inno setup hide installation items when switching from one installation to ther other

I should need your help.
I wonder if there is a possibility in Inno to set 2 different installation masks for 2 products (by selecting from the Dropdown).
We will call the 2 different installations “SETUP” and “PROGRAM”.
When Installing “SETUP” we should have the possibility to check/uncheck boxes for:
A.exe , B.exe, C.exe and D.exe that will be installed (no other check boxes should be seen).
When installing “PROGRAM” we should have the possibility to check/uncheck boxes for
A.exe, B.exe (common to “SETUP”), F.exe and G.exe (no other boxes should be seen).
I tried to add the “Flags : fixed” in [Components] section but am unable to hide the checkboxes linked to the other installation (from the drop down menu when selecting to install SETUP or PROGRAM we see the “greyed ”check box).
Is there a way to hide completely “C.exe” and “D.exe” when installing “PROGRAM” and hide completely “F.exe” and “G.exe” when installing “SETUP” ?
Thanks in advance for your help.
Meleena.
To hide components at runtime, the only way I can think of (in current version) is deleting the items from the components list. At this time, you can reliably identify component only by its description, so the idea in this code is making a list of component descriptions, iterating ComponentsList and deleting all that matches by its description:
[Setup]
AppName=My Program
AppVersion=1.5
DefaultDirName={pf}\My Program
[Components]
Name: "ProgramA"; Description: "{cm:CompDescrProgramA}";
Name: "ProgramB"; Description: "{cm:CompDescrProgramB}";
Name: "ProgramC"; Description: "{cm:CompDescrProgramC}";
Name: "ProgramD"; Description: "{cm:CompDescrProgramD}";
[CustomMessages]
; it's much better for maintenance to store component descriptions
; into the [CustomMessages] section
CompDescrProgramA=Program A
CompDescrProgramB=Program B
CompDescrProgramC=Program C
CompDescrProgramD=Program D
[Code]
function ShouldHideCD: Boolean;
begin
// here return True, if you want to hide those components, False
// otherwise; it is the function which identifies the setup type
Result := True;
end;
procedure DeleteComponents(List: TStrings);
var
I: Integer;
begin
// iterate component list from bottom to top
for I := WizardForm.ComponentsList.Items.Count - 1 downto 0 do
begin
// if the currently iterated component is found in the passed
// string list, delete the component
if List.IndexOf(WizardForm.ComponentsList.Items[I]) <> -1 then
WizardForm.ComponentsList.Items.Delete(I);
end;
end;
procedure InitializeWizard;
var
List: TStringList;
begin
// if components should be deleted, then...
if ShouldHideCD then
begin
// create a list of component descriptions
List := TStringList.Create;
try
// add component descriptions
List.Add(ExpandConstant('{cm:CompDescrProgramC}'));
List.Add(ExpandConstant('{cm:CompDescrProgramD}'));
// call the procedure to delete components
DeleteComponents(List);
finally
// and free the list
List.Free;
end;
end;
end;
Note, that once you'll delete the items from the ComponentsList, you cannot add them back because each item is holding a TItemState object instance which is released at deletion and there's no way to create nor define such object from script.

innosetup semicolon expected in code section

I have an error while compiling the code section of my inno script.
The code section
var
ServerID: String;
EditServerID: TEdit;
PageIDServer: TWizardPage;
function getServerID(Param: String): String;
begin
Result := ServerID.Text; <--- Error here
end;
And the procedure section:
if InstallService(ExpandConstant('"{app}\Client.exe -{code:GetServerID}" Client'),'Client','Client','Client',SERVICE_WIN32_OWN_PROCESS,SERVICE_AUTO_START) = true then
begin
StartService('Client');
Sleep(500);
end
else
MsgBox('Client service could not be installed',mbInformation, MB_OK);
I read that this error may be linked to the {code:} but don't know why.
Thanks for your help.
You were trying to access a Text property of a string variable ServerID, but you certainly wanted to get that value from the EditServerID edit box. If that is so, write it this way:
function GetServerID(Param: string): string;
begin
Result := EditServerID.Text;
end;
The same applies for the code in your NextButtonClick event method. Btw. the ServerID variable seems to be unused in your script, you're just assigning its value to the EditServerID.Text property when the edit box is created, but at that time the variable is empty, so I think you can just remove it from your script to not mislead you anymore.

Resources