Inno Script: Strange Empty Folder - directory

My Inno Script installer makes an empty folder in the C: drive but only on one machine. Every other machine I've tested the script on works without this problem. I've tested on two Windows 7 computers, an XP computer and a Windows XP virtual computer. For all of these computers the installer doesn't create this empty folder.
However, on my colleague's Windows XP computer the installer behaves as it should except that it also creates an empty directory on the C Drive. Uninstalling does not remove the folder.
I've had a look through my script and looked for things that could possibly be creating the extra folder, but I can't see anything. It's especially hard to solve because I can't seem to replicate the problem.
Does anyone here have an idea of why this could be happening?
#define MyAppName "Program1"
#define MyAppVersion "1.0"
#define MyAppExeName "program1.exe"
[Setup]
AppName=Test
AppVersion=1.0
AppPublisher=Me
AppSupportURL=www.google.com
AppUpdatesURL= www.google.com
DefaultDirName={code:getDirectory}
UsePreviousAppDir=no
DisableDirPage=yes
DefaultGroupName={#MyAppName}
DisableProgramGroupPage=yes
OutputBaseFilename={#MyAppName} {#MyAppVersion} Setup
Compression=lzma
SolidCompression=yes
OutputDir=output
UninstallFilesDir={code:getDirectory}
[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"
Name: "german"; MessagesFile: "compiler:Languages\German.isl"
[Files]
Source: "test.iss"; DestDir: "{code:getDirectory}"; Flags: ignoreversion;
[Code]
var
InstallTestVersionCheckBox: TNewCheckBox;
Directory : string;
// ------------------------------
// INSTALL
// ------------------------------
procedure InitializeWizard;
var
MainPage: TWizardPage;
begin
MainPage := CreateCustomPage(wpWelcome, 'text', 'text');
// make the checkbox
InstallTestVersionCheckBox := TNewCheckBox.Create(MainPage);
InstallTestVersionCheckBox.Parent := MainPage.Surface;
InstallTestVersionCheckBox.Caption := 'Test Version';
end;
function InstallTestVersion: Boolean;
begin
Result := InstallTestVersionCheckBox.Checked;
end;
procedure CurPageChanged(CurPageID: Integer);
begin
if InstallTestVersion() then
begin
// Set the test version directory
Directory := ExpandConstant('{pf32}\Testversion');
end
else
begin
// Set the production version directory
Directory := ExpandConstant('{pf32}\Normal');
end;
end;
// Returns the correct directory
function getDirectory(Param: String): String;
begin
Result := Directory;
end;

For those who might run into similar problems: Inno setup suddenly created additional empty folders I didn't want to have. Finally I understood the reason: I tried to create a single empty folder within the [Files] section. That was no good idea... So you just create your empty folder with the [Dirs] section to do it the good way.
DO NOT DO THIS:
[Files]
Source: "M:\My_Empty_Folder"; DestDir: "{userdocs}\My_App_Name"; Flags: ignoreversion
THIS IS BETTER:
[Dirs]
Name: "{userdocs}\My_App_Name\My_Empty_Folder"

Related

Starting .NET Core installer using Inno Setup fails with result code 2

I'm trying to build up an installer using Inno Setup. I need to setup a prerequisite installation for .NET Core framework. By far I'm able to detect .NET Core existence. But I'm having difficulty with executing the installation.
Here's the code I have by far:
[Files]
Source: "\\shared\path\dotnet-runtime-3.1.10-win-x64.exe"; DestDir: "{tmp}"; \
Flags: deleteafterinstall; BeforeInstall: InstallFramework; \
Check: FrameworkIsNotInstalled
[Code]
var
CancelWithoutPrompt: boolean;
InstallValue: Cardinal;
function InitializeSetup(): Boolean;
begin
CancelWithoutPrompt := false;
result := true;
end;
procedure CancelButtonClick(CurPageID: Integer; var Cancel, Confirm: Boolean);
begin
if CurPageID=wpInstalling then
Confirm := not CancelWithoutPrompt;
end;
function FrameworkIsNotInstalled: Boolean;
begin
Result := not RegQueryDWordValue(HKEY_LOCAL_MACHINE,
'SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\x64\sharedfx\Microsoft.NETCore.App',
'3.1.10', InstallValue) or (InstallValue <> 1)
end;
procedure InstallFramework;
var
StatusText: string;
ResultCode: Integer;
begin
StatusText := WizardForm.StatusLabel.Caption;
WizardForm.StatusLabel.Caption := 'Installing .net core framework...';
WizardForm.ProgressGauge.Style := npbstMarquee;
try
if not Exec(ExpandConstant('{tmp}\dotnet-runtime-3.1.10-win-x64.exe'), '/q /norestart', '', SW_SHOW, ewWaitUntilTerminated, ResultCode) then
begin
// you can interact with the user that the installation failed
MsgBox('.NET Core installation failed with code: ' + IntToStr(ResultCode) + '.',
mbError, MB_OK);
CancelWithoutPrompt := true;
WizardForm.Close;
end;
finally
WizardForm.StatusLabel.Caption := StatusText;
WizardForm.ProgressGauge.Style := npbstNormal;
end;
end;
I'm getting result code 2 response from the installation, anyone could enlighten me what's code 2 error about? Or is that any way I could extract further detail on the error information? I tried empty argument and tried to search for Code 2 error information on the internet but still no luck.
I had tried with Shellexec and both return the same result
The installation directly using the .net exe are working fine locally
Any help or information would be much appreciate =)
You are trying to run the dotnet-runtime-3.1.10-win-x64.exe before you actually "install" it to the {tmp}:
BeforeInstall: InstallFramework
You have to use the AfterInstall parameter:
AfterInstall: InstallFramework

Error using 'synaser.pas' with FreePascal (Lazarus)

I'm trying to read serial data from an Arduino to my Mac (10.12.6). I have downloaded the Synapse library for FreePascal (Lazarus v.2.0.8) from here but I run into an error...
The Arduino is programmed using the Arduino IDE and sends random numbers (between 0 and 255) as a string to the serial port. I am trying to read these strings using FreePascal so that I can plot the values.
Following instructions here I have downloaded and used the Synapse library in the following way:
1) Uncompress the library folder
2) In Lazarus goto 'Project' -> 'Project Inspector' -> 'Add Files from File System' -> select 'synaser.pas'.
3) Add the following code to the form button event:
procedure TForm1.Button1Click(Sender: TObject);
var
ser: TBlockSerial;
begin
ser := TBlockSerial.Create;
try
ser.Connect('my-com-port'); // write here Arduino COM port number (on linux it's something like '/dev/ttyUSB0')
Sleep(250);
ser.config(9600, 8, 'N', SB1, False, False);
ser.SendString('on'); // button 2 should have 'off' here
finally
ser.free;
end;
end;
4) Press run.
An error message appears in the synaser.pas file:
Error incompatible types: got "ShortInt" expected "Pointer"..
Here's the part of the synaser.pas file referred to:
{$IFNDEF MSWINDOWS}
procedure TBlockSerial.Purge;
begin
{$IFNDEF FPC}
SerialCheck(ioctl(FHandle, TCFLSH, TCIOFLUSH));
{$ELSE}
{$IFDEF DARWIN}
SerialCheck(fpioctl(FHandle, TCIOflush, TCIOFLUSH)); { <------ here*******}
{$ELSE}
SerialCheck(fpioctl(FHandle, TCFLSH, Pointer(PtrInt(TCIOFLUSH))));
{$ENDIF}
{$ENDIF}
FBuffer := '';
ExceptCheck;
end;
I am using a Mac and this error seems to be related to a windows system?
Thanks #tonypdmtr.
I had to change the 'synaser.pas' file in the following way to get it to work. Bit of a hack I feel:
Change line 1939 to the following:
SerialCheck(fpioctl(FHandle, TCIOflush, Pointer(PtrInt(TCIOFLUSH))));
Comment out lines 2201, 2202 and 2204 in the same. This sounds like a bad way of doing it but I got it to work.
Changing the button event to the following code allows me to read a single line of data from the Arduino with each button click:
procedure TForm1.Button1Click(Sender: TObject);
var
ser: TBlockSerial;
begin
ser := TBlockSerial.Create;
try
ser.Connect('/dev/cu.wchusbserial1420'); // write here Arduino COM port number (on linux it's something like '/dev/ttyUSB0')
Sleep(250);
ser.config(9600, 8, 'N', SB1, False, False);
Label1.Caption := ser.RecvString(100);
finally
ser.free;
end;
end;
I feel the library should just work without having to change it.

QBS: Explicitly setting qbs.profiles inside Products causing build to fail

My use-case is this:
I have a static library which I want to be available for some profiles (e.g. "gcc", "arm-gcc", "mips-gcc").
I also have an application which links to this library, but this applications should only build using a specific profile (e.g. "arm-gcc").
For this I am modifying the app-and-lib QBS example.
The lib.qbs file:
import qbs 1.0
Product {
qbs.profiles: ["gcc", "arm-gcc", "mips-gcc"] //I added only this line
type: "staticlibrary"
name: "mylib"
files: [
"lib.cpp",
"lib.h",
]
Depends { name: 'cpp' }
cpp.defines: ['CRUCIAL_DEFINE']
Export {
Depends { name: "cpp" }
cpp.includePaths: [product.sourceDirectory]
}
}
The app.qbs file:
import qbs 1.0
Product {
qbs.profiles: ["arm-gcc"] //I added only this line
type: "application"
consoleApplication: true
files : [ "main.cpp" ]
Depends { name: "cpp" }
Depends { name: "mylib" }
}
The app build fails. Qbs wrongly tries to link to the "gcc" version of the library instead of the "arm-gcc" version, as you can see in the log:
Build graph does not yet exist for configuration 'default'. Starting from scratch.
Resolving project for configuration default
Setting up build graph for configuration default
Building for configuration default
compiling lib.cpp [mylib {"profile":"gcc"}]
compiling lib.cpp [mylib {"profile":"arm-gcc"}]
compiling lib.cpp [mylib {"profile":"mips-gcc"}]
compiling main.cpp [app]
creating libmylib.a [mylib {"profile":"gcc"}]
creating libmylib.a [mylib {"profile":"mips-gcc"}]
creating libmylib.a [mylib {"profile":"arm-gcc"}]
linking app [app]
ERROR: /usr/bin/arm-linux-gnueabihf-g++ -o /home/user/programs/qbs/usr/local/share/qbs/examples/app-and-lib/default/app.7d104347/app /home/user/programs/qbs/usr/local/share/qbs/examples/app-and-lib/default/app.7d104347/3a52ce780950d4d9/main.cpp.o /home/user/programs/qbs/usr/local/share/qbs/examples/app-and-lib/default/mylib.eyJwcm9maWxlIjoiZ2NjIn0-.792f47ec/libmylib.a
ERROR: /home/user/programs/qbs/usr/local/share/qbs/examples/app-and-lib/default/mylib.eyJwcm9maWxlIjoiZ2NjIn0-.792f47ec/libmylib.a: error adding symbols: File format not recognized
collect2: error: ld returned 1 exit status
ERROR: Process failed with exit code 1.
The following products could not be built for configuration default:
app
The build fails only when selecting one profile in the app.qbs file, and this profile should not be the first profile in the qbs.profiles line in the lib.qbs file.
When selecting two or more profiles - the build succeeds.
My analysis:
I think this problem is related to multiplexing:
The lib.qbs contains more than one profile. This turns on multiplexing when building the library, which, in turn, adds additional 'multiplexConfigurationId' to the build-directory name (moduleloader.cpp).
The app.lib contains only one profile, so multiplexing is not turned on and the build-directory name does not get the extra string.
The problem can be solved by changing the code (moduleloader.cpp) so that multiplexing is turned even if there is only one profile i.e. with the following patch:
--- moduleloader.cpp 2018-10-24 16:17:43.633527397 +0300
+++ moduleloader.cpp.new 2018-10-24 16:18:27.541370544 +0300
## -872,7 +872,7 ##
= callWithTemporaryBaseModule<const MultiplexInfo>(dummyContext,
extractMultiplexInfoFromProduct);
- if (multiplexInfo.table.size() > 1)
+ if (multiplexInfo.table.size() > 0)
productItem->setProperty(StringConstants::multiplexedProperty(), VariantValue::trueValue());
VariantValuePtr productNameValue = VariantValue::create(productName);
## -891,7 +891,7 ##
const QString multiplexConfigurationId = multiplexInfo.toIdString(row);
const VariantValuePtr multiplexConfigurationIdValue
= VariantValue::create(multiplexConfigurationId);
- if (multiplexInfo.table.size() > 1 || aggregator) {
+ if (multiplexInfo.table.size() > 0 || aggregator) {
multiplexConfigurationIdValues.push_back(multiplexConfigurationIdValue);
item->setProperty(StringConstants::multiplexConfigurationIdProperty(),
multiplexConfigurationIdValue);
This worked for my use case. I don't know if it make sense in a broader view.
Finally, the questions:
Does it all make sense?
Is this a normal behavior?
Is this use-case simply not supported?
Is there a better solution?
Thanks in advance.
Yes, the default behavior with multiplexing is that the a non-multiplexed product depends on all variants of the dependency. In general, there is no way for a user to change that behavior, but there should be.
However, luckily for you, profiles are special:
Depends { name: "mylib"; profiles: "arm-gcc" }
This should fix your problem.

Inno Setup Choose a directory to install files from a pre-defined set

In this situation, I need to install a file to specific directory, but in different computer it might be in different folder so I need to check which on is correct.
For example, I have a file and it needs to install in A folder or B folder or C folder, depends on the computer has A or B or C. So I need to check them first, if the computer has B, then install the file in the B folder, etc.
I know I can use check after file's DestDir, if the directory doesn't exist then it won't install anything, but what I need is install that file to other directory.
Thanks in advance.
In the InitializeSetup event function, check for existence of your pre-defined set of directories and remember the one you find. Then set the default installation path to the found one using a scripted constant in the DefaultDirName directive.
You will possible also want to set the DisableDirPage=yes and the UsePreviousAppDir=no.
[Setup]
DefaultDirName={code:GetDirName}
DisableDirPage=yes
UsePreviousAppDir=no
[Files]
Source: "MyProg.exe"; DestDir: "{app}"
Source: "MyProg.chm"; DestDir: "{app}"
[Code]
var
DirName: string;
function TryPath(Path: string): Boolean;
begin
Result := DirExists(Path);
if Result then
begin
Log(Format('Path %s exists', [Path]))
DirName := Path;
end
else
begin
Log(Format('Path %s does not', [Path]))
end;
end;
function GetDirName(Param: string): string;
begin
Result := DirName;
end;
function InitializeSetup(): Boolean;
begin
Result :=
TryPath('C:\path1') or
TryPath('C:\path2') or
TryPath('C:\path3');
if Result then
begin
Log(Format('Destination %s selected', [DirName]))
end
else
begin
MsgBox('No destination found, aborting installation', mbError, MB_OK);
end;
end;
Instead of using DefaultDirName={code:GetDirName}, you can also use DestDir: "{code:GetDirName}" in the respective entries of the [Files] section, if appropriate.

segmentation fault pro*c code for database connection

I wrote simple pro*c program to check database connectivity. The code is :
int main()
{
char *conn_string = "IDA/IDA#DBISPSS";
int x = 10;
printf("value of x is before db connection %d\n",x);
printf(" conn_string %s \n",conn_string);
EXEC SQL CONNECT :conn_string;
EXEC SQL SELECT 1 INTO :x FROM DUAL;
printf("value of x is %d\n",x);
return 0;
}
Following commands I executed to create exectuable (test_connection) of pro*c code
proc test_connection.pc
cc -I${ORACLE_HOME}/precomp/public -c test_connection.c
cc test_connection.o -o test_connection -L$ORACLE_HOME/lib -lclntsh
and when I executed test_connection exe,the output is
value of x is before db connection 10
conn_string IDA/IDA#DBISPSS
Segmentation fault
But the same code workes well in another linux machine and solaris machine.
Why segmentation fault is thrown?
I tested in HPUX 11.11/Oracle 11 and work ok. I don't see any problem, but try some changes:
Declare 'x' into a DECLARE SECTION:
EXEC SQL BEGIN DECLARE SECTION;
int x = 0;
EXEC SQL END DECLARE SECTION;
Try this connection command:
EXEC SQL BEGIN DECLARE SECTION;
char *user = "abc", *password = "123", *database="base";
EXEC SQL END DECLARE SECTION;
EXEC SQL DECLARE BASE_HANDLE DATABASE;
...
EXEC SQL CONNECT :user IDENTIFIED BY :password AT BASE_HANDLE USING :database;
...
EXEC SQL AT BASE_HANDLE SELECT 1...
Insert a printf("here 1"); between EXEC SQL CONNECT... and EXEC SQL SELECT ... to see where SEGFAULT is thrown.
I had that problem and no amount of fiddling with my source made any difference. What finally worked was when I reinitialized all (ALL) my libraries to make sure that Oracle only had access to the 32 bit versions of the library. It seems Oracle was somehow getting connected to a 64 bit library. Only by removing all references to any libraries or executables except the 32 bit versions worked. This included running a 32 bit version of Pro*C.

Resources