Well - Install 5 Exe's one after the other (please read)

[James Stanich]

I have created 5 installation files (msi) using Visual Studio Installer. I copy all to a CD and distribute. What would be the easiest way, upon completion of the first install, to lauch the second, then the third, and so on?

I don't want the end user having to install 5 apps.

Does this at all make sense?

Distribution currently on CD (if that matters)

[NoteMe]

What are the diffrent apps...If they are something like Office, so the user don't have to install all of them...then you could make a splash screen and make some cool logos for the user to click so the installation can start.. then the user would have to install all of them, but it is a common thiing to do...

[James Stanich]

The 5 apps make up :

1 Switchboard

2 - 5 Task of the Application

I want all 5 installed, and more may be developed in the future...

[NoteMe]

Why can't you put everything in the same installation file???

[James Stanich]

I suppose I could, but like the flexibility of having installs seperated (especially when providing updates to one facet of the application).

[NoteMe]

Yes it might be easier for you...but I have to admitt that I have never seen an installer that has called an other one 5 times on a row...so I actually can't give you any better advises at the moment. Sorry.

[Armbruster]

Could you wrap up the other 4 programs as merge modules? Merge modules are kind of a pain in the but to create but it would be pretty clean.

[McGenius]

I would modify Setup1.vbp to create custom installation process: next is triggered upon successfull completion of the previous or exits otherwise.

[Armbruster]

Originally posted by McGenius
I would modify Setup1.vbp to create custom installation process: next is triggered upon successfull completion of the previous or exits otherwise.

That's not a bad idea at all, except that he is using VSI, not P&D. It would be an interesting approach still. Since the P&D's setup.exe just reads the setup.lst file, you could modify it to cycle through all setup.lst files and just use one setup.exe program. Still I do like VSI because it installs MUCH faster than P&D and P&D has a few bugs when registering some dll's and tlb's (easy to overcome, but still a pain!)

[McGenius]

Originally posted by Armbruster
That's not a bad idea at all, except that he is using VSI, not P&D. It would be an interesting approach still. Since the P&D's setup.exe just reads the setup.lst file, you could modify it to cycle through all setup.lst files and just use one setup.exe program. Still I do like VSI because it installs MUCH faster than P&D and P&D has a few bugs when registering some dll's and tlb's (easy to overcome, but still a pain!)

I personally preffer P&DW as it offers entire source which is simple enough to modify and I don't really care if it takes a few minutes more to install. At the moment "my" P&DW is re-written by good 60% of the original. As you mentined tons of bugs were fixed and many new features were added.

[Armbruster]

Originally posted by McGenius
As you mentined tons of bugs were fixed and many new features were added.

That sounds pretty cool!! Any chance you'll post your version?

[McGenius]

He, he .. I'll think about it. ;-)

[Microbasic]

I don't use VSI very often (I do not like the .msi files requiring Windows Installer to run), but you could make a "Super Setup File" (in Visual C++, if you do not want to pre-distribute MSVBVM60) that will Execute each and every one of your Windows Installer setups when run.

[KayJay]

Try the DOS Batch Command "START". On NT Systems (XP) the /W switch is /WAIT

@ECHO OFF
START /WAIT C:\FAT32OS\NOTEPAD.EXE  
ECHO NOTEPAD CLOSED AND LAUNCHING CALCULATOR
START /WAIT C:\FAT32OS\SYSTEM32\CALC.EXE
ECHO CALCULATOR CLOSED AND LAUNCHING SPIDER SOLITAIRE
START /WAIT C:\FAT32OS\SYSTEM32\SPIDER.EXE
ECHO SPIDER SOLITAIRE CLOSED

Copy that as a batch file and watch the "Echoed" message when you close the applications one by one.

HTH

[KayJay]

VB Implementation

Private Type STARTUPINFO
    cb As Long
    lpReserved As String
    lpDesktop As String
    lpTitle As String
    dwX As Long
    dwY As Long
    dwXSize As Long
    dwYSize As Long
    dwXCountChars As Long
    dwYCountChars As Long
    dwFillAttribute As Long
    dwFlags As Long
    wShowWindow As Integer
    cbReserved2 As Integer
    lpReserved2 As Long
    hStdInput As Long
    hStdOutput As Long
    hStdError As Long
End Type
 
Private Type PROCESS_INFORMATION
    hProcess As Long
    hThread As Long
    dwProcessID As Long
    dwThreadID As Long
End Type
 
Private Declare Function WaitForSingleObject Lib _
"kernel32" (ByVal hHandle As Long, ByVal _
dwMilliseconds As Long) As Long
Private Declare Function CreateProcessA Lib "kernel32" _
(ByVal lpApplicationName As String, ByVal lpCommandLine As String, _
ByVal lpProcessAttributes As Long, ByVal lpThreadAttributes _
As Long, ByVal bInheritHandles As Long, _
ByVal dwCreationFlags As Long, ByVal lpEnvironment As Long, _
ByVal lpCurrentDirectory As Long, lpStartupInfo As _
STARTUPINFO, lpProcessInformation As PROCESS_INFORMATION) As Long
Private Declare Function CloseHandle Lib "kernel32" _
(ByVal hObject As Long) As Long
 
Private Const NORMAL_PRIORITY_CLASS = &H20&
Private Const INFINITE = -1&
 
Private Sub ExecCmd(sCmdLine As String)
    Dim lR As Long      'Return
    Dim uProc As PROCESS_INFORMATION
    Dim uStart As STARTUPINFO
    uStart.cb = Len(uStart)
    lR = CreateProcessA(sCmdLine, vbNullString, 0&, _
    0&, 1&, NORMAL_PRIORITY_CLASS, 0&, 0&, uStart, uProc)
    lR = WaitForSingleObject(uProc.hProcess, INFINITE)
    lR = CloseHandle(uProc.hProcess)
End Sub
 
 
Private Sub Command1_Click()
ExecCmd "C:\FAT32OS\NOTEPAD.EXE"
DoEvents
ExecCmd "C:\FAT32OS\SYSTEM32\CALC.EXE"
DoEvents
ExecCmd "C:\FAT32OS\SYSTEM32\SPIDER.EXE"
DoEvents
End Sub

Of course, the above presupposes VB runtime files in the end-user's machine. The previous batch file compiled to a ".com" application will not require any runtime support