Using V7.3 Build 0 I was able to prepare a script in Safe Mode for installing a VB6 app on XP. With V8.0 Build 0 Beta I get 19 missing files, all of which seem to be in WindowsSystem32 and all of which are found in Unsafe Mode. What am supposed to do?
Also, the requirement to run the program in 1280x800 screen resolution is ridiculous. Why should I have to screw up my display with small print for the sake of this program? (My normal setting is 1024x758.)
You can run with any setting you want... It just states that that is the best setting to see everything... Your choice.
A good choice would have been to read the instructions that state exactly how to handle missing files and why they are missing. That information is explained in detail.
You are supposed to research those files to make sure they can be deployed and then copy them to another folder that you will tell InnoScript to search for those files.
Look, I don't wish to get into an unproductive debate, but:
-- 1280x800 is the MINIMUM setting to see everything. It's not a matter of choice if one wants to see it all. My display setting of 1024x768 is what came with the computer so I doubt 1280x800 is a standard. Could it possibly be that the situation is caused by poor screen design on your part?
-- You say research those files to make sure they can be deployed. What does that mean - that they exist or something else? If the former, why do they need to be in another folder?
What does safe to redistribute mean (as quoted in the instructions that I did read)? I challenge your statement that the information is explained in detail. Is it intelligible detail?
-- Why the difference between the previous V7.3 conversion and the V8.0 conversion with respect to missing files?
The app was designed to show on best on the screen it was designed for, what some says is standard really means minimum... We don't operate at the minimum requirements.
Research the files mean to make sure you can deploy those file. Meaning that you don't need a license to re-distribute and that they are actually safe for the target OS... You can always just throw caution to the wind and just include them without the research...
The system files need to be in another folder to make sure that if you include those files in your deployment you actually made the effort to make sure they were included and it was not a mistake. It helps to keep people from blaming the software (You can argue with JR Software on that one , but I agree with them).
Safe to Re-distribute mean that you will not corrupt the target system when you deploy those files. For most of the files, care has been taken using the UnSafe file list to remove files that should not be deployed but there are always more...
There is no difference in the version with respect to missing files...
More information on the changes can be found here Release History (https://randemsystems.support/index.php?topic=452.0)
Research the files mean to make sure you can deploy those file. Meaning that you don't need a license to re-distribute and that they are actually safe for the target OS...
And just how am I supposed to know those two things?
To further clarify on the missing files. The only difference in files that are missing would be files that are removed by the Unsafe file list. If both versions have the same updated UnSafe file list then the same files will be removed.
And just how am I supposed to know those two things?...
That's where the research comes in... We have done most of the work already but we can't do it all... Most of the files you don't need to worry about but there are always some that are there... That's the way MS likes everyone to be... Confused. They could supply a list but then again that would be too simple...
That's the way MS likes everyone to be... Confused.
Well, MS (and InnoScript) have certainly succeeded in confusing me. I have no idea how to do the research. If you've done most of the work already and most of the files you don't need to worry about where do I go from here (except perhaps back to the PDW)?
Yeah, Good luck with PDW. You will not only be lost but will take out the target computer...
You really don't need to do anything but run the program it will do 99% of everything for you.
Basically if you have third party software that you use in your application you check with the vendor to make sure you can re-distribute the components you want to use. Some vendors do require royalties for use of their components in your application. It's really a legal issue...
It would really be more helpful if you ran the program and posted the script then directed the question to the portions you have trouble with...
Yeah, Good luck with PDW. You will not only be lost but will take out the target computer...
You folks are really good at fear marketing. We've distributed five apps with PDW Setup and have yet to take out the target computer. That said, this app uses ADO databases which led me to look for what supposedly is a safer approach.
You really don't need to do anything but run the program it will do 99% of everything for you.
The program (InnoScript) tells me I have 19 missing files, ALL of which are in WindowsSystem32. How am I to know if any of them are unsafe?
I'm not sure of the significance of your point about third party components. We have some and I know they can be re-distrubuted. Interestingly, InnoScript accepts them without question.
Yes, any installer or tool will accept your components without question (nothing interesting there). That is what the research is all about, the owner making sure... If the owner re-distributes an component that they should not then the liability is on the owner not the software...
As far as knowing if they are unsafe or not, the ones not taken out by InnoScript are most likely safe (I would actually need to see them first).
Again... Post your script. All this theory making is academic. Copy those system files to another folder, run InnoScript then post the results. In that manner we can move forward...
Here's the script (attched).
Ooops - I sent the script as done in Unsafe Mode. I'm now getting Error Code 500 when I try to upload the Safe Mode script.
That is ok. I see you are using two Auto OS Updaters, you only need one of them. The one without XP in the name will cover all OS's from Win95 to Vista no need for a second one.
These files I do have not seen before and would only need to be checked. If you know about these files already then there is nothing to do.
Source: c:program filesmicrosoft visual studiovb98package (6)supportgbprintdialog.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:program filesmicrosoft visual studiovb98package (6)supportresizekit.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:program filesmicrosoft visual studiovb98package (6)supportdymolbl.exe; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:program filesmicrosoft visual studiovb98package (6)supportvarbetterbutton.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:program filesmicrosoft visual studiovb98package (6)supportgbgraphs.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:program filesmicrosoft visual studiovb98package (6)supportghm.exe; DestDir: {app}; Flags: restartreplace sharedfile;
Source: c:program filesdymo labellabels.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Copying your MDAC folder will be a waste of installer size... Otherwise it looks good. Make those changes and well look again...
Now mind you, with this installation to the default Program Files folder a person with Limited user rights probably won't be able to use it because they will not be able to write to that protected folder.
This installation is for XP and Vista Correct?
This installation is for XP and Vista Correct?
No, this one is just XP. Based on our interaction yesterday I'm going to do Vista separately after I resolve the paths for files situation.
All the files you list are third party files plus the main executable (GHM.EXE). All are okay, so what I'm left with are the 19 missing files that are in WindowsSystem32.
As for the MDAC folder, that is where I downloaded the Auto OS Updaters (for whatever reason) - it's not MDAC stuff. BTW, I see only the XP version in the script and logs.
I'll try to send the Safe Mode script again in another post.
I keep getting the Error 500 when I try to send the post with the attached script. Here are the names of the missing files (forgive any misspellings):
msdatsrc.tlb, mshtml.tlb, kernel32.dll
user32.dll, advapi32.dll, comctl32.dll
ntdll.dll, shell32.dll, ole32.dll
gdi32.dll, msdart.dll, shkwapi.dll
version.dll, winspool.drv, comdlg32.dll
winmm.dll, mpr.dll, rpcrt4.dll
secur32.dll
On second thought, I guess the script is for Windows 2000, XP and Vista (I have W2000 checked in the NT Version section). But I am going to use it only for Win2000 and XP Setups.
Zip the file first, then post it.
Get the same Error 500 with the zipped file.
Let me check some things. I just uploaded with no problem...
I see no restrictions to your account. Please try again.
No go -- both the original file and the zipped file fail with Error 500. Can you do an evaluation of the missing files from the list I sent previously?
The real question was why they were missing from the original script?
On review of those files they were removed, that is not the same thing as missing...
Why are you looking at those files?
When you attempted to upload are you typing the information in or using the drop down and menu choices?
The Run Log says they are missing and they are marked in red in the script. I don't understand your second question -- these files were included (and marked as missing) by InnoScript.
BTW, if it means anything, the one script file I was able to send was that from Unsafe Mode.
Then why are they not in the script you posted? You didn't have 19 files total...
Take a look at the script you posted, there is nothing missing...
Perhaps the script I posted was from another project. The script now in question (and which I can't send) has 29 Found files and 19 Not Found files.
I just looked at the script that was posted. It is the one I ran under V7.3.
Then just post it (Cut and Paste), don't upload it.
Here you go.
; InnoScript Version 8.0 Build 0
; Randem Systems, Inc.
; Copyright 2003-2008
; Website: https://randemsystems.com (https://randemsystems.com)
; Support: https://randemsystems.support (https://randemsystems.support)
; OS: Windows XP 5.1 build 2600 (Service Pack 2)
; Date: November 28, 2007
; VB Runtime Files Folder: C:\Program Files\Randem Systems\InnoScript\InnoScript 7\VB 6 Redist Files\
; Visual Basic Project File (.vbp): C:\Program Files\Microsoft Visual Studio\VB98\GHM.vbp
; Inno Setup Script Output File (.iss): C:\Program Files\Microsoft Visual Studio\VB98\GHMXP Trial Trial.iss
; Script Template Files (.tpl): C:\Documents and Settings\Tom\Application Data\Randem Systems\innoscript\Templates\Trial.tpl
; ------------------------
; References
; ------------------------
; Visual Basic For Applications - (MSVBVM60.DLL)
; OLE Automation - (STDOLE2.TLB)
; Microsoft Data Source Interfaces - (msdatsrc.tlb)
; Microsoft Data Binding Collection VB 6.0 (SP4) - (MSBIND.DLL)
; Microsoft Data Formatting Object Library 6.0 (SP6) - (MSSTDFMT.DLL)
; Microsoft ADO Ext. 2.8 for DDL and Security - (msadox.dll)
; Microsoft ActiveX Data Objects Recordset 2.8 Library - (msador15.dll)
; Microsoft Visual Basic 6.0 Extensibility - (VB6EXT.OLB)
; Microsoft ActiveX Data Objects 2.7 Library - (msado27.tlb)
; Microsoft Scripting Runtime - (scrrun.dll)
; Dymo Library - (Dymolbl.exe)
; Microsoft OLE DB Provider for Visual FoxPro 7.0 Type Library - (vfpoledb.dll)
; Microsoft HTML Object Library - (mshtml.tlb)
; Microsoft Shell Controls And Automation - (SHELL32.dll)
; Dymo Library - (LABELS.DLL)
; --------------------------
; Components
; --------------------------
; ResizeKit ActiveX Control - (ResizeKit.ocx)
; Microsoft Comm Control 6.0 - (MSCOMM32.OCX)
; Variad BetterButton(tm) Control 1.1 - (varBetterButton.ocx)
; Microsoft Windows Common Controls 6.0 (SP6) - (mscomctl.ocx)
[Setup]
AppId=GHMP Trial
;-----------------------------------------------------------------------------------------------------
; Taken from VBP Project File Parameters AppName, AppName AppVersion and Company
;-----------------------------------------------------------------------------------------------------
AppName=GHMP
AppVerName=GHMP 1.32.11
AppPublisher=SportsWare Ltd.
;-----------------------------------------------------------------------------------------------------
AppVersion=1.32.11
VersionInfoVersion=1.32.11
AllowNoIcons=no
DefaultGroupName=GHM
DefaultDirName={pf}\GHM
AppCopyright=
PrivilegesRequired=None
MinVersion=0,5.0
Compression=lzma
OutputBaseFilename=GHM13211Trial
[Tasks]
Name: desktopicon; Description: {cm:CreateDesktopIcon}; GroupDescription: {cm:AdditionalIcons}
Name: AutoOSUpdater; Description: Install Support for Database Operations; GroupDescription: Install Database Support:
Name: ScriptingRuntime; Description: Install Microsoft's Scripting Runtime; GroupDescription: Install Scripting Runtime:
[Files]
Source: c:\mdac\vb_dcom_mdac_jet_autosetup_xp.exe; DestDir: {tmp}; Flags: deleteafterinstall ignoreversion nocompression; Tasks: AutoOSUpdater
Source: c:\vbpackagefiles\scripten.exe; DestDir: {tmp}; Flags: deleteafterinstall ignoreversion nocompression; MinVersion: 0,5.0; OnlyBelowVersion: 0,5.02; Tasks: ScriptingRuntime
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\ghm_v70.add; DestDir: {app}; Flags: ignoreversion;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\ghm_v70.dbf; DestDir: {userappdata}\sportsware ltd.\innoscript\package (6)\support\; Flags: ignoreversion;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\ghm_v70.trn; DestDir: {userappdata}\sportsware ltd.\innoscript\package (6)\support\; Flags: ignoreversion;
Source: c:\ghmconv\ghmhclst.dat; DestDir: {userappdata}\SportsWare Ltd.\innoscript\; Flags: ignoreversion;
Source: c:\ghmconv\ghmhcnum.dat; DestDir: {userappdata}\SportsWare Ltd.\innoscript\; Flags: ignoreversion;
Source: c:\ghmconv\ghmoclst.dat; DestDir: {userappdata}\SportsWare Ltd.\innoscript\; Flags: ignoreversion;
Source: c:\ghmconv\ghmparms.dat; DestDir: {userappdata}\SportsWare Ltd.\innoscript\; Flags: ignoreversion;
Source: c:\ghmconv\ghmring.dat; DestDir: {userappdata}\SportsWare Ltd.\innoscript\; Flags: ignoreversion;
Source: msdatsrc.tlb; DestDir: {sys}; Flags: uninsneveruninstall restartreplace sharedfile regtypelib;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\msbind.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\msstdfmt.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\gbprintdialog.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\msadox.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\common files\system\ado\msador15.dll; DestDir: {cf}\system\ado\; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\vb6ext.olb; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\msado27.tlb; DestDir: {sys}; Flags: uninsneveruninstall restartreplace sharedfile regtypelib;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\odbcconf.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\scrrun.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\resizekit.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\dymolbl.exe; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\vfpoledb.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: mshtml.tlb; DestDir: {sys}; Flags: uninsneveruninstall restartreplace sharedfile regtypelib;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\mscomm32.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\varbetterbutton.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\mscomctl.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\gbgraphs.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\ghm.exe; DestDir: {app}; Flags: restartreplace sharedfile;
Source: kernel32.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: user32.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: advapi32.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: comctl32.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: c:\program files\microsoft visual studio\vb98\package (6)\support\msvcrt.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: ntdll.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: shell32.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: ole32.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: gdi32.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: msdart.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: shlwapi.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: version.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: winspool.drv; DestDir: {app}; Flags: ignoreversion;
Source: comdlg32.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: c:\program files\dymo label\labels.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: winmm.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: mpr.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: rpcrt4.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
Source: secur32.dll; DestDir: {sys}; Flags: restartreplace sharedfile;
[INI]
Filename: {app}\GHM.url; Section: InternetShortcut; Key: URL; String:
[Icons]
Name: {group}\GHMP; Filename: {app}\GHM.exe; WorkingDir: {app}
Name: {group}{cm:ProgramOnTheWeb, GHMP}; Filename: {app}\GHM.url
Name: {group}{cm:UninstallProgram, GHMP}; Filename: {uninstallexe}
Name: {commondesktop}\GHMP; Filename: {app}\GHM.exe; Tasks: desktopicon; WorkingDir: {app}
[Run]
Filename: {tmp}\VB_DCOM_MDAC_JET_AutoSetup_XP.exe; Parameters: /NORESTART /VERYSILENT; WorkingDir: {tmp}; Flags: skipifdoesntexist; Tasks: AutoOSUpdater
Filename: {tmp}\scripten.exe; Parameters: /r:n /q:1; MinVersion: 0,5.0; OnlyBelowVersion: 0,5.02; WorkingDir: {tmp}; Flags: skipifdoesntexist; Tasks: ScriptingRuntime
Filename: c:\program files\microsoft visual studio\vb98\package (6)\support\dymolbl.exe; Parameters: /regserver; WorkingDir: c:\program files\microsoft visual studio\vb98\package (6)\support\;
Filename: {app}\GHM.exe; Description: {cm:LaunchProgram, GHMP}; Flags: nowait postinstall skipifsilent; WorkingDir: {app}
[UninstallDelete]
Type: files; Name: {app}\GHM.url
[Registry]
Check to see if you can upload a small file...
Check to see if you are checking for UnSafe Files
Settings->Parameters
The Check for Unsafe files should be checked...
Check for Unsafe Files is checked. I just tried to send a very small file of 7 bytes - same Error 500.
On the main menu there is a button to view the Unsafe file. Let me know what you see. It looks like it may be empty or incomplete...
It is empty.
I just saw a post I missed about how I am trying to upload. I'm typing in and browsing for the file. I'll try again the other way.
That is why you have so many missing files. Please download the Unsafe file and copy it to your APPDATA\Randem Systems\InnoScript folder over the empty one.
Another shot at uploading. But, the only thing I see in the Upload window are boxes for the file name and for the results of the Browse.
Drop-down menu - ??
To find your APPDATA path go to the command prompt (Start->Run) then key in cmd and when the box opens type in Set APPDATA
Sorry, the browse button...
Oh boy! Set APPDAta yields C:Documents and SettingsTomApplication Data. But I can't find an Application Data folder in that path.
You would need to go Tools->Folder Options in Windows explorer then select to show hidden folders and files.
Remember to reset them back when you are finished...
Okay, I now have an Unsafe Files List. Was it missing because of an oversight in V8.0?
More importantly, I reran the script and now have 22 files with no missing files. Forgive my newness with all of this, but what happened? I assume the previously missing files were on the Unsafe List and were therefore removed from the script. Are there any implications of this or do I now have a solid script with which I can create a Setup?
I don't know what happened. The UnSafe file is installed with InnoScript and copied to the APPDATA folder upon first run. Check the installed location for the Unsafe file to see if it is there and has data.
There are no implication as long as you installed what was removed IE. MDAC's, Crystal Reports, Scripting Runtime and other such application. Some of the files were your XP system files which should Basically NEVER be installed on a prior OS or they might cause failure.
Ok, Now show your completed script and we will see if you need anything else...
Oversight in 8.0 Not likely but anything is possible. It is being updated all the time...
I won't belabor the point but the UnSafe file was empty in my installation (and then replaced with the file you sent). Apparently, it was not copied on the first run.
You say there are no implications as long as I installed what was removed. I'm confused (again). Do you mean previously installed on my system? What about the end user systems that will get the Setup? If Setup has to install them, how is that done inside or outside of InnoScript? The app needs MDAC (except on Vista) and Scripting Runtime. It looks like the script includes a Run of these.
I am unable to send the script, either via upload or Copy/Paste - same Website Problem and Error Code 500.
Apparently, it was not copied on the first run.
I should have said that an empty file was apparently copied.
I am only talking about the end user. Files that were removed consisted of portions of MDAC's, Scripting Runtimes and other such installation that need to have a complete installation for they consist of more than one file that was included in the script before removal.
Since youu check off to include the AUTO OS Updater and Scripting Runtime the target system will have a complete installation and not get one file that may be the wrong version than what was already installed on that system.
I don't understand why you can't copy and paste you had just done it...
I should have said that an empty file was apparently copied.
Ok, so that is why it is Beta. Major changes and somethings fall thru the cracks... It has been corrected.
I don't understand why you can't copy and paste you had just done it...
I don't understand either. I just tried it again and it failed. Remember that I was also able to upload a script file one time only.
The good news is your latest word that the inclusion of AutoOS Updater and Scripting Runtime will do what is needed to be done. I'll test things tomorrow and let you know. I'll also try again to send the script.
OK, I see what I can find out about the posting/pasting...
Test message on IE7
Message received
Great, I see you can post again...
Obviously, I can now post a very short message. Here goes an attempt to upload the zipped script file.
NO Go - Error 500 again.
Ok, I will try to upload using IE. You try pasting your text.
Here's a try at Copy/Paste.
No Go.
I am using IE7 for this upload...
Look at this script that I generated from your setup.lst file. Are you sending me those files I asked for?
I need two more files for now.
dymolbl.exe
ghm.exe
I see that the PDW has some other files listed so you must have added them in somehow.
itircl.dll
itss.dll
hhctrl.ocx
You are also missing from the PDW file:
newhist.hst
Just a upload test using a user account
I have throughly checked the server for problems and have posted large amounts of data and uploaded data without errors. I do see where you got errors they were Out of Memory Errors How much memory do you have on your computer?
Did you zip those files yet?
Memory: 1 Gigabyte. I'm working on the zipping.
To Zip files Download a program called WinRar from http://www.rarlabs.com (http://www.rarlabs.com) and install it. Once you install it you can highlight all the files you want to zip (in the same folder) then right click and select Archive.
I am now missing labels.dll
What are these files for?
itircl.dll
itss.dll
I just sent labels.dll in a new archive with all the files.
I'm not really really sure what the two dll's are for. They were presented by the PDW and I included them. I believe they are related to use of HTML Help Files. They are on a list of files that are shipped with Vista and therefore don't need to be deployed as part of of a VB Setup package for Vista. Don't know about the XP package I'm trying to do but they presented no problem in the PDW Setup.
I have found out what they are for. They are for your Help File. The file come from a .dep file on your system for the help dll file
You have on your system a file named hhctrl.dep. If you could send that file also. It should be in the same location as the hhctrl.ocx file. I believe that would be in your WindowsSystem32 folder.
BTW: You don't use the hhctrl.ocx in your project. Why do you include these files???
There is no hhctrl.dep file on my syste, just the .ocx. BTW, hhctrl is also related to HTML Help Files.
itircl.dll
itss.dll
hhctrl.ocx
are all for the HTML Help Files of which you don't include the OCX in your project. How does your project work if you don't include the ocx file.
Also I need the labels.def file...
BTW: You don't use the hhctrl.ocx in your project. Why do you include these files???
When you asked for the .OCX files I included all of them that were in the PDW's Support folder. Also, it is presented in the PDW's list of files for inclusion. However, I believe it can be excluded because it's related to hh.exe which I don't include. I'll research the documentation for the Help package I'm using to verify.
If the help package you are using is not on the target systems by default you will need to deploy the help installation as well.
What is the help package you are using and how do you call it?
I just created an installed from a PDW Setup without including itircl.dll, itss.dll, hh.exe and hhctrl.ocx. The Help System works well without them - that is, on my machine which is also the development machine.
Not a good test environment for it already has those files so you don't know if they are being used...
Only on a clean machine without those files installed can you tell if your system will work without them.
What help system are you using?
I'm using HelpScribble (a great program by the way). It creates a .CHM file (HTML Help File) that is completely independent of the authoring program (i.e. independent of HalpScribble) and can be viewed on any Windows system from 98 through Vista.
I just checked the VB app code and found the following related to calling it:
Private Declare Function HTMLHelp Lib HHCtrl.ocx Alias HtmlHelpA _
and
App.HelpFile = App.Path & GHMhelp.chm
and
Private Sub mnuHelp_Click()
HTMLHelp hWnd, GHMhelp.chm, HH_HELP_CONTEXT, ByVal 500&
End Sub
The first item above seems to say that hhctrl.ocx is needed but Help runs okay in the app both from menu selections and via the F1 Key from any screen in the app. Again, I'm going to have to test on other than the development machine. I do know that the four files (the two it...'s and the two hh...'s) DO NOT have to be deployed on a Vista system.
Perhaps the safest bet for XP is to include them.
Well, Actually you don't need to include them at all.
Just change your help click to ShellEx to GHMhelp.chm and Windows will run it on it's own. Then you do not need to deploy the hhctrl.ocx at all.
Try it... Comment out that definition and call then replace the HTMLHelp call with a ShellEx call.
I will try it but not tonight. It's approaching midnight here on the U.S. East Coast. I know - the sun just went down a bit ago in Hawaii
That's fine those three files InnoScript removes them from the script anyway for they are unsafe to deploy. Windows already has those files and they should not be overwritten...
This is the part of the research I was referring to earlier...
Where do things stand regards InnoScript?
Another situation. I set up a XP machine with Microsoft Virtual PC and tried to run my PDW Setup. It copies the files and I then get a message that some system files are not up to date and that I should restart to have Setup update the files. I've done that about six times but I continue to get the message every time I run Setup. What is this all about?
Please read Installer Problems (https://randemsystems.com/installationproblems.html) for more help on this situation.
Umm, What do you mean Where do things stand regards InnoScript?
Umm, What do you mean Where do things stand regards InnoScript?
You folks were working on a script for my VB6 app, for which I sent you files.
We still need the labels.def file...
Here you go - hopefully it will uplosd.
Please zip the files first before uploading to avoid conversions.
Here is what I have now. Do I have all the files need for your app?
; InnoScript Version 8.0 Build 0 Beta
; Randem Systems, Inc.
; Copyright 2003-2008
; Website: https://randemsystems.com (https://randemsystems.com)
; Support: https://randemsystems.support (https://randemsystems.support)
; OS: Windows XP 5.1 build 2600 (Service Pack 2)
; Date: December 01, 2007
; VB Runtime Files Folder: C:\Program Files\Randem Systems\InnoScript\InnoScript 8\VB 6 Redist Files\
; Visual Basic Project File (.vbp): E:\Works\TomBuggy\GHM.vbp
; Inno Setup Script Output File (.iss): E:\Works\TomBuggy\Scripts\Swagolf Release.iss
; Script Template Files (.tpl): C:\Documents and Settings\Ralph James\Application Data\Randem Systems\InnoScript\Templates\Release.tpl
; ------------------------
; References
; ------------------------
; Visual Basic For Applications - (MSVBVM60.DLL)
; Standard OLE Types - (OLEPRO32.DLL)
; OLE Automation - (STDOLE2.TLB)
; Microsoft Data Source Interfaces - (msdatsrc.tlb)
; Microsoft Data Binding Collection VB 6.0 (SP4) - (MSBIND.DLL)
; Microsoft Data Formatting Object Library 6.0 (SP6) - (MSSTDFMT.DLL)
; Microsoft ADO Ext. 2.5 for DDL and Security - (msadox.dll)
; Microsoft ActiveX Data Objects Recordset 2.5 Library - (msador15.dll)
; Microsoft Visual Basic 6.0 Extensibility - (VB6EXT.OLB)
; Microsoft ActiveX Data Objects 2.7 Library - (msado27.tlb)
; Microsoft Data Access Components Installed Version - (odbcconf.dll)
; Microsoft Scripting Runtime - (scrrun.dll)
; Microsoft HTML Object Library - (mshtml.tlb)
; --------------------------
; Components
; --------------------------
; Microsoft Comm Control 6.0 - (MSCOMM32.OCX)
; Microsoft Windows Common Controls 6.0 (SP6) - (mscomctl.ocx)
[Setup]
AppId=GHMP Release
;-----------------------------------------------------------------------------------------------------
; Taken from VBP Project File Parameters AppName, AppName AppVersion and Company
;-----------------------------------------------------------------------------------------------------
AppName=GHMP
AppVerName=GHMP 1.0.4 Release
AppPublisher=SportsWare Ltd.
;-----------------------------------------------------------------------------------------------------
AppVersion=1.0.4
VersionInfoVersion=1.0.4
AllowNoIcons=yes
DefaultGroupName=GHM
DefaultDirName={pf}\GHM
AppCopyright=
PrivilegesRequired=Admin
MinVersion=4.0,4.0
Compression=lzma
OutputBaseFilename=GHM104Release
[Tasks]
Name: AutoOSUpdater; Description: Install Support for Database Operations; GroupDescription: Install Database Support:
[Files]
Source: e:\server data\randem\develop\support\scripts\output\vb_dcom_mdac_jet_autosetup.exe; DestDir: {tmp}; Flags: deleteafterinstall ignoreversion nocompression; Tasks: AutoOSUpdater
Source: e:\works\tombuggy\ghm_v70.add; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\ghm_v70.dbf; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\ghm_v70.hst; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\ghm_v70.rng; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\ghm_v70.trn; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\hcpcard.lwt; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\labels.def; DestDir: {app}; Flags: ignoreversion;
Source: e:\server data\randem\develop\deployable system files\msbind.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\server data\randem\develop\deployable system files\msstdfmt.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\gbprintdialog.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\resizekit.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\dymolbl.exe; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\vfpoledb.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\server data\randem\develop\deployable system files\mscomm32.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\varbetterbutton.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\server data\randem\develop\deployable system files\mscomctl.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\gbgraphs.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\ghm.exe; DestDir: {app}; Flags: restartreplace ignoreversion;
Source: e:\works\tombuggy\labels.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
[INI]
Filename: {app}\GHM.url; Section: InternetShortcut; Key: URL; String:
[Icons]
Name: {group}\GHMP; Filename: {app}\GHM.exe; WorkingDir: {app}
Name: {group}{cm:ProgramOnTheWeb, GHMP}; Filename: {app}\GHM.url
Name: {group}{cm:UninstallProgram, GHMP}; Filename: {uninstallexe}
[Run]
Filename: {tmp}\VB_DCOM_MDAC_JET_AutoSetup.exe; Parameters: /NORESTART /VERYSILENT; WorkingDir: {tmp}; Flags: skipifdoesntexist; Tasks: AutoOSUpdater
Filename: e:\works\tombuggy\dymolbl.exe; Parameters: /regserver; WorkingDir: e:\works\tombuggy\;
Filename: {app}\GHM.exe; Description: {cm:LaunchProgram, GHMP}; Flags: nowait postinstall skipifsilent; WorkingDir: {app}
[Dirs]
Name: {userappdata}\SportsWare Ltd.; Flags: uninsalwaysuninstall;
Name: {userappdata}\SportsWare Ltd.\GHM; Flags: uninsalwaysuninstall;
[UninstallDelete]
Type: files; Name: {app}\GHM.url
Type: filesandordirs; Name: {userappdata}\SportsWare Ltd.\GHM
Type: filesandordirs; Name: {app}
Type: dirifempty; Name: {app}
Type: dirifempty; Name: {userappdata}
Zipped file.
Do I have all the files need for your app?
I believe so.
I think I remembered you mentioning an Access database or something of the sort. Is that the case?
No. The databases we use are the GHM_V70.xxx files we sent you and are included in the script you just posted.
Ok, I will generate the installation file and test it. Any information on how to test?
The database files in the script are skeleton files for new users and thus require the user to set up System Parameters, add real player to the database, etc. I'm attaching a series of real files that will resolve this situation for you. Copy these files to the installation folder (C:\Program Files\GHM) before you run the program.
You should then be able to go the Handicap Maintenance from the main menu and then to Player Maintenance from the next menu. From there you can do variouus things via the buttons at the bottom of the window.
Try this installation - GHM (https://randemsystems.com/scripts/downloadit.php?filename=GHM104Release.zip)
This is what generated it:
; InnoScript Version 8.0 Build 0 Beta
; Randem Systems, Inc.
; Copyright 2003-2008
; Website: https://randemsystems.com (https://randemsystems.com)
; Support: https://randemsystems.support (https://randemsystems.support)
; OS: Windows XP 5.1 build 2600 (Service Pack 2)
; Date: December 01, 2007
; VB Runtime Files Folder: C:\Program Files\Randem Systems\InnoScript\InnoScript 8\VB 6 Redist Files\
; Visual Basic Project File (.vbp): E:\Works\TomBuggy\GHM.vbp
; Inno Setup Script Output File (.iss): E:\Works\TomBuggy\Scripts\Swagolf Release.iss
; Script Template Files (.tpl): C:\Documents and Settings\Ralph James\Application Data\Randem Systems\InnoScript\Templates\Release.tpl
; : E:\Works\TomBuggy\Templates\Swagolf.tpl
; ------------------------
; References
; ------------------------
; Visual Basic For Applications - (MSVBVM60.DLL)
; Standard OLE Types - (OLEPRO32.DLL)
; OLE Automation - (STDOLE2.TLB)
; Microsoft Data Source Interfaces - (msdatsrc.tlb)
; Microsoft Data Binding Collection VB 6.0 (SP4) - (MSBIND.DLL)
; Microsoft Data Formatting Object Library 6.0 (SP6) - (MSSTDFMT.DLL)
; Microsoft ADO Ext. 2.5 for DDL and Security - (msadox.dll)
; Microsoft ActiveX Data Objects Recordset 2.5 Library - (msador15.dll)
; Microsoft Visual Basic 6.0 Extensibility - (VB6EXT.OLB)
; Microsoft ActiveX Data Objects 2.7 Library - (msado27.tlb)
; Microsoft Data Access Components Installed Version - (odbcconf.dll)
; Microsoft Scripting Runtime - (scrrun.dll)
; Microsoft HTML Object Library - (mshtml.tlb)
; --------------------------
; Components
; --------------------------
; Microsoft Comm Control 6.0 - (MSCOMM32.OCX)
; Microsoft Windows Common Controls 6.0 (SP6) - (mscomctl.ocx)
[Setup]
AppId=GHMP Release
;-----------------------------------------------------------------------------------------------------
; Taken from VBP Project File Parameters AppName, AppName AppVersion and Company
;-----------------------------------------------------------------------------------------------------
AppName=GHMP
AppVerName=GHMP 1.0.4 Release
AppPublisher=SportsWare Ltd.
;-----------------------------------------------------------------------------------------------------
AppVersion=1.0.4
VersionInfoVersion=1.0.4
AllowNoIcons=yes
DefaultGroupName=GHM
DefaultDirName={pf}\GHM
AppCopyright=
PrivilegesRequired=Admin
MinVersion=4.0,4.0
Compression=lzma
OutputBaseFilename=GHM104Release
[Tasks]
Name: AutoOSUpdater; Description: Install Support for Database Operations; GroupDescription: Install Database Support:
[Files]
Source: e:\server data\randem\develop\support\scripts\output\vb_dcom_mdac_jet_autosetup.exe; DestDir: {tmp}; Flags: deleteafterinstall ignoreversion nocompression; Tasks: AutoOSUpdater
Source: e:\works\tombuggy\ghm_v70.add; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\ghm_v70.dbf; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\ghm_v70.hst; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\ghm_v70.rng; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\ghm_v70.trn; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\hcpcard.lwt; DestDir: {app}; Flags: ignoreversion;
Source: e:\works\tombuggy\labels.def; DestDir: {sys}; Flags: ignoreversion;
Source: e:\server data\randem\develop\deployable system files\msbind.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\server data\randem\develop\deployable system files\msstdfmt.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\gbprintdialog.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\resizekit.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\dymolbl.exe; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\vfpoledb.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\server data\randem\develop\deployable system files\mscomm32.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\varbetterbutton.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\server data\randem\develop\deployable system files\mscomctl.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\gbgraphs.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
Source: e:\works\tombuggy\ghm.exe; DestDir: {app}; Flags: restartreplace ignoreversion;
Source: e:\works\tombuggy\labels.dll; DestDir: {sys}; Flags: regserver restartreplace sharedfile;
[INI]
Filename: {app}\GHM.url; Section: InternetShortcut; Key: URL; String:
[Icons]
Name: {group}\GHMP; Filename: {app}\GHM.exe; WorkingDir: {app}
Name: {group}{cm:ProgramOnTheWeb, GHMP}; Filename: {app}\GHM.url
Name: {group}{cm:UninstallProgram, GHMP}; Filename: {uninstallexe}
[Run]
Filename: {tmp}\VB_DCOM_MDAC_JET_AutoSetup.exe; Parameters: /NORESTART /VERYSILENT; WorkingDir: {tmp}; Flags: skipifdoesntexist; Tasks: AutoOSUpdater
Filename: e:\works\tombuggy\dymolbl.exe; Parameters: /regserver; WorkingDir: e:\works\tombuggy\;
Filename: {app}\GHM.exe; Description: {cm:LaunchProgram, GHMP}; Flags: nowait postinstall skipifsilent; WorkingDir: {app}
[UninstallDelete]
Type: files; Name: {app}\GHM.url
Type: filesandordirs; Name: {userappdata}\SportsWare Ltd.\GHM
Type: filesandordirs; Name: {app}
Type: dirifempty; Name: {app}
Type: dirifempty; Name: {userappdata}
[Dirs]
Name: {userappdata}\SportsWare Ltd.; Flags: uninsalwaysuninstall;
Name: {userappdata}\SportsWare Ltd.\GHM; Flags: uninsalwaysuninstall;
I created a CD with the .EXE you sent. When I went to run it on the XP Virtual PC I got the message The Setup files are corrupted. Please obtain a new copy of the program.
It had not finished uploading when you downloaded it. I will let you know when it finishes uploading...
BTW: You can remove the X at the top of the forms so that no one can attempt to use it or just ignore the close request instead of issuing the messages...
Ok, you can download it now (36.3 mb)
Still get the corrupted message. But, it seems you have the program running.
With respect to the X my understanding is that it can't be removed without removing the entire Control Box and I want to leave the Minimize option. But, you make a good point - why a message instead of just ignoring - probably because we have neophyte users who want to know why about everything. If the program bugs them enough with the message perhaps they'll stop trying.
Ok, but why can't the window close with the X? You should still be able to run the same code...
I am downloading the program now to see if I get any errors. You may get errors downloading exe files. I will upload a zip file to see if you get errors on that.
Ok, but why can't the window close with the X?
I don't understand why but in some cases in the past it shut the program down and Windows thought it was still running. I supose I could recode and return to the previous window when X is clicked.
I'll look forward to the zipped file. Perhaps you could also send the script in a file that I can use with Inno Setup to create a Setup executable.
I'll be gone for a few hours in a bit but I'll pick up when I return.
Ok, You could run any code that your program needs (a function) then when it returns it would still shut down the normal way.
The Exit button would run the same function then exit the program.
I'll let you know when the zip file is uploaded.
BTW: I downloaded the exe file and had no problems starting it up...
Ok, use the same link in the post to download the zip file.
The Installer Problems link has been fixed in the post also...
Some progress but not enough. The Setup ran to a point until I got an error reading the file VB_dcom_mdac_jet_autosetup.exe - says the file is corrupted.
Don't know what else might be done regards downloading the Setup .exe file. I guess my next step is to edit the script file to substitute my file sources and then run Inno Setup.
I'm leaving now for a few hours. If you have any other ideas I'll read them on my return and work on all this tomorrow.
I will say this is one of the best examples of user support I have ever experienced. My compliments and thanks.
Thank you...
I will do you one better than just the script. Here is the pjt file for InnoScript that will allow you to change things and still get the same results. You can change the search and file location inside InnoScript and that way you don't have to start from scratch...
Thanks. I've edited the script for the file locations on my development system and ran a compile with Inno Setup. Two questions before I attempt to use the generated Setup program:
1) I notice that Scripting Runtime (scripten.exe) is not included in the Files or Run sections. scrrun.dll is included in the References section.
I use File System Objects in the app. Should Scripting Runtime be included in the script?
2) Inno Setup gave a Warning about labels.def: Unsafe File Usage - the ignoreversion flag should not be used on files installed to the Windows System Directory. What to do about that?
1 - Yes Include the scripting runtime
2 - Don't worry about that message, it is a warning to get you to make sure of what you are doing. An I am sure...
2 - The file Labels.def has to be installed where the Labels.dll is installed and you could remove the ignoreversion flag for if there is already a file by that name there it will not be copied over.
The tricky part is if the labels.dll file is not newer that the one already installed then it will not be copied and the labels.def file will. So it's a judgement call for that file...
You also have support files in you added into PDW that may need to be added into your script:
varbetterbutton.hlp
msstkprp.dll
ghmhelp.chm
Question: Did you edit the script or did you change the values in InnoScript to recreate the proper script? The latter is the best way.
Here are updated pjt, tpl and iss file
I''ve been away most of the day (and night). It's now 12:20 AM and I'm just reading you new posts.
Yeah right, you know I know what I'm doing! But I will say that I'm gaining on it, including research.
The labels.dll and labels.def files will likely never change or, if they do, they will be newer.
The ghmhelp.chm file definitely has to be added, which I also noticed after my last post. The varbetterbutton.hlp file isn't needed and I should delete it in the PDW build. I'm not sure about msstkprp.dll - I'll do some research!
With respect to you question, what I did was use your script and change the sources of the files to their location on my system. That's what I meant by editing the script.
Going to bed - I'll finish things in the morning and test on my clean Virtual XP PC.
Not quite to bed. I noticed that you included the dymolabel.exe in the Run section. I'm not sure about that - I think its inclusion is what screwed up my standard Dymo Label installation with my first script try a few days ago. I'll do some research (that word again) in the Dymo SDK I used to integrate label printing into the app.
Now I am going to bed!
Yes, Remove it from the run section. I had to change InnoScript no to do that with ActiveX exe's.
BINGO!!! With some additional script modifications I was able to get a Setup package that installed the app on my clean XP system under Virtual PC. Although additional testing is required, the app appears to be running well - including being able to print a label over anetwork to a shared label printer.
The major script change was to install dymolbl.exe to the App folder versus the Sys folder (we both missed that one). I also had to research the location of scripten.exe and scr56en.exe on the development system.
Three followup questions:
1) I have been working only with the script file. I think I should also modify the project file you sent me. Any suggestions in that regard?
2) I assume the script is usable for Vista installs except for the taboo of installing to Program Files when there are data files to be written to in that folder (which is my present situation). Should I prepare a separate script for Vista installs?
3) At the end of the Setup run there's an Available Switches window with an OK button. It doesn't seem to have any value to end users and may confuse our neophyte users. Is there a way to eliminate it?
Thanks again for your EXTRAORINARY support. I not only have a Setup package I can be comfortable with versus PDW, but I have learned a great deal about the installation proces (which is far more complex than I imagined). You can be sure that I will recommend InnoScript and Randem Systems to others.
Scripten.exe and Scr56en.exe you just download from our site at https://randemsystems.com/innoscript// (https://randemsystems.com/innoscript//)
1) Yes, that is exactly what I was suggesting. In that way you can duplicate the script at anytime with just a push of a button anytime you add something new. Use the script as documentation also.
2) No, if your program is not setup to use the APPDATA environment yet. You can add in the Vista Template so that you can have your installation detect if it is on Vista and install to the C:\Users\Public\YourAppName folder so that your app can work under Vista (with no protection).
3) Available Switches? InnoScript doesn't build such a screen in the installation. Perhaps you can show a screen print of this window?
Thank you for your kind words...
Scripten.exe and Scr56en.exe you just download from our site
I got them from C:VBPackageFiles on my development system. I'm not sure if I created this folder or it was already there. In any case, here's version comparison between what I used and what I just downloaded from your site.
scripten: Used - 6.2.29.0 Your site - 5.50.4134.600
scr56en: Used - 5.50.4134.0 Your site - 5.50.4134.600
Implications?
Is not another approach for Vista to prepare a separate Setup and have it install to C:UsersPublicAppName? Or, require Administrator Privileges and install to Program Files? I realize that you advise against the latter (I did read your Vista page) but most all of our customers run on a single standalone computer that they control, so it may not be a problem. Plus, I read an article in vbforums that recommended Run As Administrator for Setups.
The Available Switches window may have come from Inno Setup versus InnoScript. I'll do some more research and see if I can get a screen print.
Another question from research -- what are the implications on my app of the Security Update for the VB6 Redidistributable -- that is, the change from a single OLEAUT32.DLL to system-dependent versions? (KB Article 924053)
I don't have subfolders under the Redist folder so it looks like I haven't installed the security update. Thus, I should be okay with the dll version that works on all systems supported by VB6.
However, is not OLEAUT32.DLL from the Randem VB Runtime Files rather than from the PDW Redist folder?
The OS Updater has the universal VB Runtime files and will be fine for all OS's before Vista. On Vista it would not deploy any VB Runtime files.
Okay on OLEAUT32.DLL - the universal files will handle it. Did you see my questions 4 posts up?
I have never seen an Available Switches screen in Inno Setup. I could come from the ActiveX exe the was in the run section if you haven't removed it.
As I stated in a prior post you can add the Vista Template to your script and add in the parameters screen for DefaultDirName to be {code:GetFolderName} then re-run InnoScript.
When you run your setup on a Vista box you will see a new default folder as the one I have stated for a Vista install.
Scripten.exe and Scr56en.exe you just download from our site
I got them from C:VBPackageFiles on my development system. I'm not sure if I created this folder or it was already there. In any case, here's version comparison between what I used and what I just downloaded from your site.
scripten: Used - 6.2.29.0 Your site - 5.50.4134.600
scr56en: Used - 5.50.4134.0 Your site - 5.50.4134.600
Implications?
None... Use the latest version.
Curious, Where did you get version 6.2? The latest I have found is 5.7
I did some research on the scripten.exe file and 5.6 contains both installations for Windows 2K and XP and 5.7 is broken up for each OS. Being that the case version 5.6 will continue to be advised by InnoScript.
Dummy me - The Version 6.2 is a cabinet file. When I double-clicked it I got an install window for Version 5.7. I'm going to reference the Randem files in my script.
Your post says InnoScript will advise Version 5.6; the files I downloaded from your site are 5.5 - ??
Never mind the last post - I see that your files install Version 5.6 of the .exe files.
The mystery of the Available Switches window at the end of the install appears to be related to the use of Version 5.7 of scripten.exe. When I reinstalled using Version 5.6 the window did not appear. (BTW, I got the Version 5.7 from the Microsoft website.)
Anyhow, FYI the attached .bmp file is a graphic of the window that appeared.
Ok, then it seems that the 5.7 scripten is a msi file and you need to use the msi switches to run that installation. If you want to use that one look in the CR templates for examples of how to set that line up in Inno Setup. Then you can add that to a template of your own and use that in InnoScript.
No need -- I'm staying with V5.6 from your site.
Youe are going to hate me (and my inexperience with InnoScript) but I'm having a terrible time modifying the project file to get a script that corresponds with the modifications I made to the script file with which I've successfully installed the app on XP. All the source folders are changed okay but here are some of the question and problem areas. Note that in all cases when I refer to a script it is both the script you sent and my modification of it.
-- The modified script (and your script) contained a reference to OLEPRO32.DLL. It is not being included in the script generated from the project file.
-- The data files are going to userappdata versus app. For XP and lower I want both the app and the data files in the same folder (Program Files).
-- dymolbl.exe has a destination directory of sys versus app. (Remember that I changed this in my modified script)
-- labels.def in not being included. If I add it via Add Files the destination directory is app versus sys.
-- With regard to Uninstall, nothing is in the [UninstallDelete] and [Dirs] sections in the script generated from the project file. In your original script there were these sections. In addition, what I want to do on Uninstall is remove the app and the desktop icon but not the data files. How do I do that?
-- Finally, what is GHM on the Web that gets generated in the install and which leads to nothing?
First thing you need to use the same version that I am Download the updated Beta version 8.0 Build 0 and install that. Let's concentrate on having one version to use.
GHM on the web is there because the include URL links is checked and you have not provided any information about a website in the parameters screen.
The labels.def file you need to add that line in the template with the change that you want, then when you run InnoScript again it will be changed.
Let's start from there with the last project file/template that I sent you...
Okay - I downloaded the current V8.0 Build 0. One thing I notice is that there is now a [UninstallDelete] section.
Based on your post: 1) What/where is the parameters screen?, and 2) how does one create or modify a template?
I found the Parameters Screen unde Settings.
I have just uploaded a version that takes care of the ActiveX issues.
Parameters Screen - From the main menu Settings->Parameters.
To modify a template - Go to the templates tab. Either add a template or modify an existing one. If you double click on an existing template it will open up in notepad and you can modify it from there. Check the documentation on templates.
To not remove the data files then remove from the [UninstallDelete] section the data file folder or change the flags on how it gets deleted.
Okay - I see where V8.0 is now going into a new folder (Inno Script 8). I had to uninstall/reinstall to get InnoScript to run.
In the Templates subfolder, the Release and Trial tpl files are 0 bytes - ??
I'm out for dinner - will be back in an hour or so.
Yes, those files should be 0 bytes... You haven't added anything to them yet. You could add information to the release template or use the template I included for your project (which should be your choice) and add any information to that. This way you can use multiple projects and have different templates. If you use the Release template that is something that you may want to include in all your projects.
Why did you have to uninstall and re-install to get it to run???
Why did you have to uninstall and re-install to get it to run???
Don't know. I did one download after your first post and that seemed okay. When you posted that you uploaded another version, I downloaded that. But when I went to run from a Desktop Icon it flashed red in the Tray and nothing ran. That's when I did the uninstall/reinstall. Perhaps the icon pointed to the old InnoScript 7 subfolder - ?
Now I am off to dinner.
That would be it, The desktop pointed to an old installation then InnoScript 7 folder. You could always check that by right clicking on the icon and selecting properties.
Yeah, I know about right-click/Properties to see where the Shortcut is pointing. I would have thought that the install of the upload would create the appropriate path for the icon it creates. Oh well, all is okay now.
I've relooked at the Project, Script and Template files you originally sent. The only thing in the Template file is the Source for labels.def. When I modify your Project file to reference the .vpf's location on my system and run, the labels.def entry shows up in the generated script in blue.
All the data files are in the Add Files list. In your script they all have a DestDir of {app}. In the script generated in the modiified project they have a DestDir of {userappdata}. Is that because of changes in the latest Beta version I uploaded? If not, why the difference? If so, how do I change to {app}? I tried an experiment of removing one of the files from the Add Files list and including it in the Template with the {app} destination. That got it into the generated script - it shows up in red. Is that okay?
Yes the {userappdata} is a change in the beta version if you select (checkmark) then line items in the add files and add folders tabs.
Check the Documentation... Experimenting and guessing causes weird results.
No that is not ok, unless you want failure later...
All you need to do is uncheck the box and it will be sent to the {app} folder instead of the {userappdata} folder in the next generation of the script.
A related question. I just used Add Files to include msstkprp.dll. It showed up in the generated script with a DestDir of {userappdata} - ? I removed it from the Add Files List and added it to the Template with a DestDir of {sys}. It showed up in the script as I wanted it - in red. Again, is that okay.
BTW, I think I missed your last post.
I got your last post and I understand what you are saying about checking and unchecking item in the Add Files. I missed that in the documentation.
Okay, I now have all the data files destined for {app}. All I need to do now is figure out how to not uninstall the data files from the app folder. You say:
To not remove the data files then remove from the [UninstallDelete] section the data file folder or change the flags on how it gets deleted.
I assume what I have to do is list as Type Files; all the files I want to remove (the .exe, .chm, etc.) and not use the Type: filesandordirs; Name: {app} entry.
Why would you not want to remove the file on an uninstall? If the files are in a separate folder let's say {app}Data and you uninstall the app and want all the information removed except that folder, do this:
[UninstallDelete]
Type: files; Name: {app}
You can do that with the inside the template.
Why would you not want to remove the files on an uninstall?
Because, for now at least, I'm stuck with the data files being in the same folder as the app. And, for future releases of the app I want both this common folder and the user's data files to remain.
I realize that a separate data folder is a better approach and eventually I will go that route. But, for now can I just do a series of:
Type: files; Name {app}filename
for the files I want to uninstall?
Yes, that will work...
Progress, although not complete progress. I now have an Inno Setup with my revised [UninstallDelete] section. However, I went a bit nutso in doing so. Here's why.
I created a script in InnoScript and edited it in Inno Setup to make the [UninstallDelete] changes. However, if I go back to InnoScript to do anything and run it again (I'm wearing out the traffic light) the script changes I made in Inno Setup are lost and I have to do them over again. Questions:
-- Why doesn't Inno Script recognize the script changes made in Inno Setup? Or, why is there no capability to edit a script in InnoScript?
Perhaps the best way to do the [UninstallDelete] changes is via my Template but I'm not sure how to do so. For example, how do I delete a line generated by InnoScript? This time I did read the documentation but didn't find it definitive. It mentions keywords but I'm not sure what they are. In the example:
Type: files; Name: {app}InnoScript.url: whatever
What is whatever? Also, why the inclusion of quote marks (there are none in an actual Template file)?
Here's another usability situation. When I return from double-clicking a Template to edit it the checkbox that was previously checked is unchecked. It took me a while to recognize that this was happening. Why does it happen? (If I am editing a Template I sure want to continue to use it.)
One final question regards my script. The original script you sent me included a Reference to OLEPRO32.DLL which is no longer included when I run the script - ??
Why should InnoScript recognize change made to a script after InnoScript created it??? I repeatedly stated that you should make changes in the template file in InnoScript so that when you re-run InnoScript you would not loose changes. You constantly ignore those suggestions...
The template process is described in the documentation and I have given you examples. All you need to do is to take the line that InnoScript created copy it to the template file under the proper section and then make your changes to it. The next time you run it will change the line...
I can't tell you where whatever came from I don't know where you got it from.
The check box issue we will be working on. Thank you for bring it up.
If you removed the reference it will not show up. I create the script with what you had given me.
For give my frusration, and I understand yours with me. Although I think an editing process would be less complex and easier than a template process, I suppose templates are necessary because InnoScript is a script generator from VB project files, etc. But enough, templates it is.
The whatever comes for your documentation and from the template example in your Examples folder. I thought I understood how to add items to the template via the first-character asterisk, e.g:
*Type: files; Name: {app}GHM.exe
The line gets added when I run the script but it's in red - ??
I don't yet understand how to remove a generated item. For example, if a have a generated item in [UninstallDelete] of:
Type: filesandorfolders; Name: {app}
how do I remove it?
I'll do some research in my VB References about why OLEPRO32.DLL is missing. It may be related to something I removed. Perhaps you what causes that file to be included as a reference.
You don't remove anything thru the template process, you only add and modify. To remove you eliminate the process that included it in the first place or remove it manually. Perhaps a removal in the template may be productive...
No, I never cause it to be included. That is exactly what the documentation in the script is for. So that you can tell what was removed or added between runs.
With respect to add, see my previous post. Using the asterisk resulted in the line being add, but in a red color. Why the red?
I don't want to delete the {app} folder. I don't know how to eliminate the process that included it and I guess the only way to remmove it manually is via editing of the script in Inno Setup.
OLEPRO32.DLL is listed in the Dependencies and also in Deleted Files.
Why not red??? You can change those colors...
That file is removed because it is a VB runtime file and since you included the OS Update those files are not needed since the OS Updater installs the VB Runtime file also. No need to have them installed twice.
Why not red??? You can change those colors...
The other items that are changed in the template (in the [Files} section) show up in blue. I would think these changes should be in the same color. Besides, red usually means error.
I used the script with Inno Setup and the changes in Red were accepted without error. I also checked the Colors tab in InnoScript (which you will say I should have done when the Red situation occurred). Actually, the default color for Added Lines is dark Magenta, which is very close to Red and a source of confusion. I've changed my Added Lines color to a lighter shade of Magenta (so at least I'm not confused anymore).
You said in a previous post: To remove you eliminate the process that included it in the first place or remove it manually. I assume that the process that included it is the provision of default [UninstallDelete] items by InnoScript. Have I (again) missed something that would allow me to modify the defaults? Also, I assume that the only present way to remove it manually is via editing of the script in Inno Setup - is that true?
I also realize that if I was doing the standard thing of keeping my data files in a folder separate from the app folder we wouldn't be discussing this.
Considering this is a Beta version This is exactly the kind of response I wanted so that certain procedures could be refined. Perhaps InnoScript need a way to remove Items from the script.
Changes have been made and a new version uploaded. Check .InnoScript History (https://randemsystems.support/index.php?topic=452.0) for new changes.
Oh boy - I just downloaded and installed the new beta version. When I attempted to run it I got:
Run-time error 430 - Class does not support Automation or does not support expected interface.
Uninstall/Reinstall did not resolve.
Let me check to see what the case may be...
Replace your 8.0 exe with this one
No difference - same error.
Try re-downloading and re-installing. What version is your rsgenrtns.dll file in the windowssystem32 folder?
Download & Reinstall: Same result - same error.
rsgenrtns.dll Version: 4.00
Do you get that error running 7.3. Do you still have that installed?
What version is your InnoScript.exe file?
No on 7.3 and No, that version is no longer installed. InnoScript.exe Version: 8.0.0.1
You have all the correct versions. Let me try something...
Try this, delete the rsgenrtns.dll and re-install. That should do it.
That did it. Out of curiosity - why?
Should I now reinstall the .dll?
No you should not re-install the dll it was re-installed with the software. Different version of the dll but the version number did not change.
Don't ask me why I may want to do this but is there a way to prevent the user from changing the Destination Location? (First screen in the install with the Browse Button)
Yes, In Inno Setup:
[Setup]: DisableDirPage
Valid values:
yes or no
Default value:
no
Description:
If this is set to yes, Setup will not show the Select Destination Location wizard page. In this case, it will always use the default directory name.
Thanks in great measure to your outstanding assistance I now have an Inno Setup for XP and all Windows versions below it. Thanks again.
I am now ready to move on to a Vista install. I have read and reread your documentaion on this and it will come as no surprise to you that I am more than a little confused about how to use APPDATA in the app and have users deal with the generated long path to the data (our current users are going to have to get their present data there after they install the app).
Therefore, I'm considering living with what I think is a limited security exposure in the app's user environment by installing both the app and the data to C:UsersMyAppName. In that regard I notice that the Vista Template specifies an install to C:UsersPublicMyAppName. I assume all I need to do is modify the template statement to remove Public from the path.
I am going to take your good advice to create a public variable for the path to the data (to C:UsersMyAppName) and use it it all Connection Strings and Open Statements.
Great. One thing your current users would have to do nothing when they upgrade if your upgrade program copies the data automatically for them. Since you know where it is to go and where the old data is also you don't need to worry them about it. On startup of your app, check the new data folder location for the existence of the data files, if they do not exist then you copy the users data to the new location and they are none the wiser and you get them in compliance with the Limited User model.
Note: If you are going to copy the data and change your app to reference the Limited User installations locations you don't want to use the Vista Template You actually want your program installed in the Program Files Folder.
When you reference the data in your app you do use fully qualified paths don't you... IE. App.Path & yourFileName and not just yourFileName, correct? If so you would just do the following:
AppDataPath = Environ(APPDATA)
Then replace all occurences of App.Path with AppDataPath. Simple... If you just used the filename you would have to prepend all the filenames with AppDataPath & ",
You say: AppDataPath = Environ(APPDATA)
What I'm not understanding (dummy me) is how Environ(APPDATA) knows where the data is. I assume in InnoScript that I check the data files in Add Files which gets them to {userappdata}. Is that what establishes their location for the Environ statement?
Yes, if you check the files in Add Files they will go to {userappdata} which will become the APPDATA path on the target machine.
APPDATA is a default windows variable to show you where your data is supposed to go. If you open a DOS command prompt and type in Set APPDATA, windows sets this path.
Got it (finally), at least with respect to a standalone computer. For installs on multiple network workstations I have the user made a drive (e.g. Drive Z) to a UNC Path (e.g. \hostnamesharename) and change the installation path to that UNC Path, where sharename is a shared folder on the host. That works fine when both the app and the data are in the shared folder. What are the implications now that the data files will be in a different folder (the APPDATA folder) on the host?
In addition to my question above about network workstation installs, another question.
I have this simple concept that I want the data in a folder named GHMDATA. I placed the data files to be installed in that folder on the development computer; put the files in Add Files with the folder as the source; and added the folder to the Search Files list. However, apparently in InnoScript the PDW's Package folder takes precedence and the Destination Folder for the files becomes:
{userappdata}sportsware ltd.ghmpackage (6)ghmxpsupport
There are problem resolution situations in use of the app where we ask the user to send us one or more data files. The above path may be a source of user confusion.
If I remove the data files from Add Files and place the GHMDATA folder in Add Folders I get the following Destination Folder for all the files sourced from C:GHMDATA*.*:
{userappdata}sportsware ltd.GHMGHMDATA
That's simpler, but I've modified it via template to {userappdata}GHMDATA - is that okay?
Sure, If you had the folder under your development folder it would amount to the same and be the preference. Ex. Your development folder is GHM ande under that folder is a sub folder GHMDATA. IF you add this folder (GHMDATA) in add folders on the target system it would either go to {app}GHMDATA or {userappdata}yourcompanynameyourappnameGHMDATA on the target system.
It should not be confusing to your users. All you need to do is to create a batch file that will copy the data to a location they can find when you want them to send you data. Perhaps the temp folder inside a folder named GHMDATA.
In reference to a server install you do not use {userappdata} because the user would not be able to access it for they would need administrator privilegews on the server to see it. That is where you would use something like C:UsersPublicyourappnameGHMDATA to have your data. You would need to seperate installations, One for the server install and one for the client install.
Vista Standalone Computer Install: I understand what you are saying regards GHMDATA as a subfolder under yourappname (which is GHM). But, IF I wanted GHMDATA to be a standalone folder, are you saying that a template change to DestDir: {userappdata}GHMDATA will do that?
Vista Network Install: I really want to stay away from our neophyte users having to do separate installations for the server and clients. I know you discourage Run as Administrator, but would that not be a simpler approach, and would it not apply only to this one app? Does checking the Vista Admin Request box provide Administrator privileges for the app on a client?
In my 95-XP setup I have the data files in the same folder as the app - that is, the Destination Directory for the data files is {app}. What is Environ(APPDATA) going to produce in that case? If not the app folder then I'm going to have to redo the 95-XP setup to put the data in a separate folder.
If you use Run As Administrator on the clients machine that does not give access to the protected areas of the server unless you the same user and password is and admin on the server also and they have to be logged on, Not good. Too much power for the user to do damage to the server...
As far as a Win95 install, I don't know what it would return but my guess would be either it would return nothing or the {app} path. That would need to be tested though.
In running the app on my XP development machine, Environ(APPDATA) returns:
C:Documents and SettingsTomApplication Data
Not good. Forgive my inexperience but:
-- Is there a way to determine the OS in VB code?
-- If so, can I Set APPDATA in VB code?
Or, maybe I should just bite the bullet and get the data out of the {app} folder for all OS's not just Vista.
Getting the data out of the app folder would be good for all OS's. Why would you want to deal with a different set of rules for each OS.
Why do you think that application data path is not good?
If you want to set the APPDATA environment you can shell to DOS and use the Set APPDATA = yourpathname command. Yes, there are ways to determine the OS in VB code using API's.
Ex.
Private Declare Function GetVersion Lib kernel32 () As Long
Public Function GetWinVersion() As String
Dim Ver As Long, WinVer As Long
Ver = GetVersion()
WinVer = Ver And &HFFFF&
'retrieve the windows version
GetWinVersion = Format((WinVer Mod 256) ((WinVer \ 256) / 100), Fixed)
End Function
Private Sub Form_Load()
'KPD-Team 1999
'URL: http://www.allapi.net/ (http://www.allapi.net/)
'E-Mail: KPDTeam@Allapi.net (mailto:KPDTeam@Allapi.net)
MsgBox Windows version: GetWinVersion
End Sub
I have tested {userappdata} under Win98 and the data goes to WindowsApplication Data. That is the default for Win98 and I don't know where it would go under Win95. I would choose not to support this OS for various reasons.
Why do you think that application data path is not good?
Because it's not the folder where the app and data is, not that I expected it would be.
I agree about Win95. I was wondering why you included it in the script you did for me. Based on a survey of our users I'm thinking about eliminating Win98 also.
Thanks for the code for determining the Windows version. It may be useful in the future - not now because I'm going to take your advice and get the data out of the app folder via {userappdata}.
Final question (at least for now): What are the effects of checking/not checking the Allow NoIcons item in Parameters?
What do you mean it's not where the data is? You do have to put the data there. Why would that be a problem?
From Inno Setup Help Documentation:
[Setup]: AllowNoIcons
Valid values:
yes or no
Default value:
no
Description:
When set to yes, Setup will display a Don't create a Start Menu folder check box on the Select Start Menu Folder wizard page, which allows the user to skip creation of program shortcuts. Note that this check box does not affect [Icons] entries that have Tasks parameters since they have their own checkboxes.
With respect to the Application Data Path, my assumption is that {userappdata} in the script is what creates the path which is then retrieved from Environ(APPDATA). I also assume that if I have the following in the script under [Files]
Source: C:GHMDATA*.*; DestDir: {userappdata}SportsWare Ltd.GHMGHMDATA; Flags: ignoreversion
Setup will create the required folders. Are my assumptions valid?
With respect to AllowNoIcons in the documentation, I don't know what doc you are referring to. I've looked at both the online and pdf doc and there's nothing like you posted. I also looked at the Help Tab and see nothing that would lead me to what you posted.
Well, either my assumptions above are not valid or I'm preparing the script incorrectly. Here's what I've done:
-- Created the folder GHMDATA on the development computer and placed my data files in it.
-- Added C:GHMDATA via Add Folders
-- Modified [UninstallDelete] and [Dirs] via Template
-- Modified the script in Inno Setup to delete the last two items in [Dirs]
With respect to the last thing above, I could not comment out the last two lines in [Dirs] with the & prefix. The generated script contained the &'s - ?? (and I tripled-checked that the template entry matched the script entry)
When I ran the Setup on my Virtual XP system (non-development computer) I did not get a GHMDATA subfolder under GHM, did not get a SportsWare Ltd. folder, and I could not find the data files anywhere on the machine. Do I need to specify those folders in Add Folders? Or, something else.
When I uninstalled the Program FilesGHM folder was deleted. Is my [UninstallDelete] section faulty?
Why is Flags: uninsalwaysuninstall genereated in the [Dirs] section of the script? (By the way, the online and pdf documentation does not cover this section.)
A zipped text file of the generated script is attached.
Yes, The setup will create the folder located in DestDir:
I can't tell anything without seeing your script...(No attachment)
The attachment didn't get attached - trying again.
When normal apps uninstall they should clean up after themselves and remove everything it created hense the flag uninsalwaysuninstall. BTW, the flag is covered in the Inno Setup documentation. That's the way it should work. Why would you want to leave the folder GHM after an uninstall?
If you used {userappdata} That's where the data went. If you wanted the folder under the installation folder you should have used {app}. You are still very confused. This is one of those times when pen and paper does wonders by writing the locations and where the information is going.
{app} = Installation folder
{userappdata} = APPDATA path
These location are not inter-changeable...
I understand what you just said but your are correct about me being confused. I am especially confused about how the APPDATA path gets generated and what I do in the script to have the data placed there.
What I want to acheive is to separate the data from the installation folder and get it to whatever folder {userappdata} puts it. I thought the presence under [Files] of
Source: C:GHMDATA*.*; DestDir: {userappdata}SportsWare Ltd.GHMGHMDATA; Flags: ignoreversion
would do that but it didn't (I couldn't find the data files anywhere after install).
With respect to the always uninstall I misspoke - given that the data is separate from the Program FilesGHM installation folder, I don't care if the installation folder is removed on uninstall. What I'm concerned about is the last two lines of the [Dir] section because they seem to mean that the data will be removed. Or do they just mean that the APPDATA path specification is being removed?
Have you seen the script I resent? I apologize for the dicumentation confusion. I didn't pick up that you were referring to Inno Setup (versus InnoScript) documentation.
What is your APPDATA path? that is where you should check for the data files you copied. What I like to do is to install the data into the {App} folder then on program start copy the data to where it needs to be if it is not already there. This would handle multiple users using the system and each having different data of their own (in their own profiles). If all user are supposed to share the same data then you would install in the ALL USERS Application Data folder.
Yes the data will be removed from the appdata folder if you don't change the flags in the [uninstalldelete] section to that folder. You could also set a flag to ask the user if they want to delete the data upon uninstall. Which I probably should make the default.
Yes, I did see the script.
Why are you listing each file in your app folder to be deleted separately when you could just delete the files and the folder in one line?
Type: filesandordirs; Name: {app}
Or is there other files in that folder that you want to keep?
What is your APPDATA path?
That's what I want to know!!! Given the statement in the script I thought that setup created the path and placed the data files in it - I guess not. I just checked the Environment Variables on the installation computer and there is no APPDATA. How do I, or more importantly the users, create it? Once that's resolved then I guess I have to copy the data there in the app startup (something I thought Setup would do).
All users will have the same data. I'm not sure what you mean by install in the ALL USERS Application Data folder.
I have discovered the Inno SETUP Help doc and have been reading it. I think I've commented out in the script the things in [UninstallDelete] that would remove the data. As for the [Dirs} section, uninsalwaysuninstall does the uninstall ONLY if the folder is empty.
As for the list of files in the app folder, it's a hangover in the templete from a previous misinterpretation. I'll changed to what you posted.
BTW, in preparation for all of this I have already modified the app to use Environ(APPDATA) to get a public constant that is now part of every file access via Connection String or Open. Now if I could only install the app and the data.........
What OS are you using XP and Vista have APPDATA in the environment. If not you can use an API to get the users Profile area and append Application Data to it.
use these function to get the APPDATA path
Private Declare Function GetUserProfileDirectory Lib userenv.dll Alias GetUserProfileDirectoryA (ByVal hToken As Long, ByVal lpProfileDir As String, lpcchSize As Long) As Boolean
Private Declare Function GetCurrentProcess Lib kernel32 () As Long
Private Declare Function OpenProcessToken Lib advapi32 (ByVal ProcessHandle As Long, ByVal DesiredAccess As Long, TokenHandle As Long) As Long
Public Function GetAppDataFolder() As String
Dim sBuffer As String
Dim hToken As Long
Const TOKEN_QUERY = (&H8)
sBuffer = String(255, 0)
OpenProcessToken GetCurrentProcess, TOKEN_QUERY, hToken
GetUserProfileDirectory hToken, sBuffer, 255
GetAppDataFolder = FixPath(StripTerminator(sBuffer)) & Application Data
End Function
Public Function StripTerminator(sInput As String) As String
Dim ZeroPos As Long
ZeroPos = InStr(1, sInput, Chr$(0))
If ZeroPos > 0 Then
StripTerminator = Left$(sInput, ZeroPos - 1)
Else
StripTerminator = sInput
End If
End Function
WOW - not your everyday code!!! So every computer has its own APPDATA Path.
Tell you what - I've got exactly one Vista user right now. He's in Michigan and won't be installing this golf application until Spring, as will be the case for most all new or current users who have Vista. I'm going back to what worked with XP - {app} versus {userappdata} with the data in a subfolder of the installation folder. That way I can hard-code the public variable that has the path to the data. I'll work on Vista and {userappdata} later.
A curiosity -- why can't/doesn't Inno Setup determine the APPDATA Path on the installed-to machine when {userappdata} is used?
APPDATA is for each USER not each machine...
What do you mean userappdata is returned in Inno Setup?????
Oops - Each User versus Each Machine -- another reflection of my inexperience with the new world of system and security things, but I understand better now. Thanks.
Interestingly, in my Googling for various things I came across a Microsoft KB article about QuickBasic (the old DOS-based Basic) that discussed how you could set the APPDATA Path on an application basis and then have it revert to its original setting when the app closed.
I don't think I said that userappdata is returned in Inno Setup. What I said was a value was returned in my app when I used Environ(APPDATA).
On XP APPDATA should always be set unless something deleted it. Go to the command prompt and type SET APPDATA or just SET and see what shows. But that is exactly the argument of why one should use the API's to get this sort of data.
I've done that before. It says:
C:Documents and SettingsTomApplication Data
which, of course, is the same thing that's returned from Environ(APPDATA). Why do you ask?
Because you keep confusing me when you ask question like
A curiosity -- why can't/doesn't Inno Setup determine the APPDATA Path on the installed-to machine when {userappdata} is used?
I am truly sorry to confuse you after all you've done to unconfuse me. I asked the question you reference before you made me understand that APPDATA was on a User basis and not a machine basis.
Off to bed - hopefully a clearer mind in the morning.
You made a comment about the & being added into the script from the template file. Yes, that would be true... you never updated to the later version that handled that...
Yes I did update to the later version that uses $ and & to remove and comment out lines, respectively, in a template. Notice in my script the commented-out lines in [UninstallDelete]. Where the & appeared on lines in the generated script was in the [Dirs] section. You won't see that in the script because I deleted the lines from the template after experiencing the situation.
Perhaps template modifications are not allowed in the [Dirs] section (I notice that there's no coverage of that section in the template documentation or sample template file). Or, perhaps there was an oversight in the implentation of the $/& feature.
While on the subject of features I humbly pass along the following suggestions:
-- A feature to copy/paste from the generated script to a template would be useful. The exactness requirement between the two is somewhat tedious and error prone.
-- You rejected this idea previously but I encourage you to consider a redesign the InnoScript screen so that it's fully visible at a resolution lower than the required 1280x800 (say 1024x768). I find myself switching back and forth between resolutions just for InnoScript. For other uses 1280x800 produces ovals instead of circles, skinny text that's more difficult to read, etc.
If you will bear with me, back to the where to put the data issue. You said in a previous post: If all users are supposed to share the same data then you would install in the ALL USERS Application Data folder. That is my situation - that is, I want a single data folder for all users (and one that is accessible permissions-wise from network clients).
Based on some experimenting I note that there's a difference between XP and Vista:
XP: C:Documents and SettingsAll UsersApplicaton Data
Vista: C:UsersDefaultAppDataRoamingCompanyNameRoamingCompanyNameAppNameEtc.
For Vista there's also: C:UsersPublicRoamingCompanyNameAppNameEtc. but I don't see an AppData folder anywhere in that path.
So, using your practice of installing the data files in the installation folder and then moving them at app statup to where they should go, I'm thinking I could hard-code the public variable with the path to the data versus using Environ(APPDATA). However, that brings in the variability among Windows versions. XP looks clear but I don't know where the equivalent of All Users is in Me, 98, 95, NT and 2000, and I'm not sure of which of the Viata paths above to use. It would be great if I could define the app's own data folder and have it accessible to all users on either a standalone computer or a network client.
Your guidance will be appreciated.
I show that you are on 8.0 Build 1 and the latest revision is 8.0 Build 8 and will soon be build 9. So how are you running the latest updated version? I will get to your other questions...
The beta versions are coming fast and furious. I assume if I subscribe to updates I will be notified of new versions. However, when I click on Subscribe Updates there's an attempt to go to my email system, which is AOL. In AOL I get a message that the file is too large -- just another of my many problems.
The Beta version are not included on the Update list because they change too quickly and that would amount to too many emails to our client list. We do not want people to turn us off because we seem like SPAM. You just have to check back with the site especially when you find a problem to make sure you have the latest release and try that to see if it resolves your issue. If it does not then report it and we will see about correcting that issue in the next beta release.
This also goes for the Release version also. We do not send emails for very minor corrections.
The issue with the & is real and is being worked on as I type. It will be corrected in build 9.
BTW: When you purchase InnoScript you are automatically added to the email updates.
You can copy and paste under normal windows techniques highlight the line then Press Ctrl-C, open the template file and Paste.
Hardcode exactly what?
What generated the file paths you posted?
I never knew about Ctrl-C but that won't surprise you.
Hardcode exactly what? For example in XP:
C:Documents and SettingsAll UsersApplicaton DataSportsWare Ltd.GHMGHMDATA
What generated the file paths? Nothing more than exploring MyComputer for Users folders.
My Appdata paths:
XP: C:Documents and SettingsRalph JamesApplication Data
Vista: C:UserRalph JamesAppDataRoaming
You have some other information in your entries. Where did they come from?
Please continue to Part 2 (https://randemsystems.support/index.php?topic=270.0) of this thread