Raw program works, installed program doesn't
I am maintaining a legacy app I wrote in VB6 a long time ago. Development is done on
an external hard drive that I switch between two machines, XP for development, and
Win7 to test run. I use Inno to build the installer. Installer works successfuly all
the way up through Win10. Installation occupies a shade under 1 MB.
All required associated files for the project, and four compiled executables
(including the new one) are gathered on the external hard drive in a folder named
"SS_Build".
I was asked to add a feature (MakeNewPlayers.exe). An Excel spreadsheet is read in,
modified, and written out. Works perfectly in development mode. Works perfectly when
executed from the Build folder under XP. Works perfectly when executed from the Build
folder under Win 7.
Doesn't work from the installation created by Inno. Program stalls near the bottom,
where the modified Excel spreadsheet is written out. The message box does not appear.
If I exit, system asks me if I want to save "Book1", which tells me the modified
spreadsheet actually was created (but apparently not named), confirmed by looking at
"Book1".
Here is the relevant source code:
Here are the relevant Inno.iss scripts: (First two lines are typical of a whole bunch.)
an external hard drive that I switch between two machines, XP for development, and
Win7 to test run. I use Inno to build the installer. Installer works successfuly all
the way up through Win10. Installation occupies a shade under 1 MB.
All required associated files for the project, and four compiled executables
(including the new one) are gathered on the external hard drive in a folder named
"SS_Build".
I was asked to add a feature (MakeNewPlayers.exe). An Excel spreadsheet is read in,
modified, and written out. Works perfectly in development mode. Works perfectly when
executed from the Build folder under XP. Works perfectly when executed from the Build
folder under Win 7.
Doesn't work from the installation created by Inno. Program stalls near the bottom,
where the modified Excel spreadsheet is written out. The message box does not appear.
If I exit, system asks me if I want to save "Book1", which tells me the modified
spreadsheet actually was created (but apparently not named), confirmed by looking at
"Book1".
Here is the relevant source code:
Set oXLApp = CreateObject("Excel.Application")
If oXLApp.Application.Version > "11.0" Then
iXLversion = 56
Else
iXLversion = -4143
End If
Set oXLApp = Nothing
Set oXLApp = CreateObject("Excel.Application")
(code that modifys spreadsheet goes here)
SavePath = App.Path & "\" & sWorkbookName
oXLBook.SaveAs SavePath, FileFormat:=iXLversion
oXLApp.Quit
Set oXLApp = Nothing
Set oXLBook = Nothing
Set oXLSheet = Nothing
sMsg = "Player Data has been saved"
MsgBox sMsg, vbInformation + vbOKOnly, "SAVED"
bSaveP = True
Exit SubHere are the relevant Inno.iss scripts: (First two lines are typical of a whole bunch.)
Source: "F:\SS_Build\Plan6.txt"; DestDir: "{app}"; Flags: ignoreversion
Source: "F:\SS_Build\Plan8.txt"; DestDir: "{app}"; Flags: ignoreversion
Source: "F:\SS_Build\MakeNewPlayers.exe"; DestDir: "{app}"; Flags: ignoreversion
Source: "F:\SS_Build\PoolSandS.exe"; DestDir: "{app}"; Flags: ignoreversion
Source: "F:\SS_Build\Scheduler.exe"; DestDir: "{app}"; Flags: ignoreversion
Source: "F:\SS_Build\Statistics.exe"; DestDir: "{app}"; Flags: ignoreversion
Source: "F:\SS_Build\MSFLXGRD.OCX"; DestDir: "{app}"; Flags: restartreplace sharedfile
regserverASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
John Tsioumpris
Probably it's a permission issue but dropping some msg boxes here and there to ensure where the application is getting into trouble is not a bad idea
The cause for working in the IDE but not in the exe is often because the exe is faster and long-running external processes don't get a chance to finish before the code moves on to the next line. In this case the culprit might be line 13 in the source code so try adding the DoEvents shown in line 14 of this code.
Set oXLApp = CreateObject("Excel.Application")
If oXLApp.Application.Version > "11.0" Then
iXLversion = 56
Else
iXLversion = -4143
End If
Set oXLApp = Nothing
Set oXLApp = CreateObject("Excel.Application")
'(code that modifys spreadsheet goes here)
SavePath = App.Path & "\" & sWorkbookName
oXLBook.SaveAs SavePath, FileFormat:=iXLversion
DoEvents
oXLApp.Quit
Set oXLApp = Nothing
Set oXLBook = Nothing
Set oXLSheet = Nothing
sMsg = "Player Data has been saved"
MsgBox sMsg, vbInformation + vbOKOnly, "SAVED"
bSaveP = True
Exit SubASKER
Permission issue: That may be it. When running this program from the VB development suite, I get a message saying I need permission to save the file. When I acknowledge that message, it goes ahead and saves anyway.
When running from the installed package, I don't see that warning. The program just hangs up. Inserting a MsgBox between each line in the program seems to show the program hangs at the Quit, line 15 above.
So, how do I fix this so the unwashed user doesn't have to worry about it?
=====
DoEvents did not make a difference. But I can understand why it is a good idea for it to be there. anyway.
=====
I set the .Visible for the generated spreadsheet to True. Program generates the thing, and then it is up to me to save it. But I don't want the user to have to do this.
When running from the installed package, I don't see that warning. The program just hangs up. Inserting a MsgBox between each line in the program seems to show the program hangs at the Quit, line 15 above.
So, how do I fix this so the unwashed user doesn't have to worry about it?
=====
DoEvents did not make a difference. But I can understand why it is a good idea for it to be there. anyway.
=====
I set the .Visible for the generated spreadsheet to True. Program generates the thing, and then it is up to me to save it. But I don't want the user to have to do this.
ASKER
Vadim and David: So, when the installer (created by Inno) runs, I can tell it to install in an "ordinary" folder of my own.
I do believe this is the key issue. Program has been around a long time. I usually install in a C-drive folder established for this program. This time, I just went ahead and took the default, "program files(x86)"
I will get back to you tomorrow.
I do believe this is the key issue. Program has been around a long time. I usually install in a C-drive folder established for this program. This time, I just went ahead and took the default, "program files(x86)"
I will get back to you tomorrow.
I think so, line 7 and 9 is not necesary.
You will be much better off to save the file in writable directory to begin with. In VB6, Environ$("TEMP") is all you need.
You say it hangs on Quit. Which means that it already has saved the file, so it's not a permission issue after all. Can you check - when it hangs, is the file already in place?
Also, I would try this:
You say it hangs on Quit. Which means that it already has saved the file, so it's not a permission issue after all. Can you check - when it hangs, is the file already in place?
Also, I would try this:
oXLBook.SaveAs SavePath, FileFormat:=iXLversion
oXLBook.Close SaveChanges:=False
Set oXLBook=Nothing
oXLApp.QuitASKER
OK! Success!
Vadim and David: I deleted the program. Made a new folder in C: Installed there. Everything works! So I learned something. If program is going to be writing back to same installation folder, don't install in the default "Program" windows folders. Thank you.
Actually, this program has been around for a long time, and I had always done this (not because I understood why). This time I just got lazy and let the installer use the default folder.
jcgd: This saving of a new or modified spreadsheet happens in several places in the entire package. I just establish iXLversion once in the initial form load. That's lines 1 to 7 in the code (above).
Martin: Your suggestion is a good idea in any event.
Actually the saving write-out at issue here takes enough time to worry the user. I added a "pacifier" to the code to assure the user that the thing isn't just dead in the water.
Again, thank you everyone.
Vadim and David: I deleted the program. Made a new folder in C: Installed there. Everything works! So I learned something. If program is going to be writing back to same installation folder, don't install in the default "Program" windows folders. Thank you.
Actually, this program has been around for a long time, and I had always done this (not because I understood why). This time I just got lazy and let the installer use the default folder.
jcgd: This saving of a new or modified spreadsheet happens in several places in the entire package. I just establish iXLversion once in the initial form load. That's lines 1 to 7 in the code (above).
Martin: Your suggestion is a good idea in any event.
Actually the saving write-out at issue here takes enough time to worry the user. I added a "pacifier" to the code to assure the user that the thing isn't just dead in the water.
Again, thank you everyone.
ASKER
Thank you all.
Wouldn't it save time if you deleted lines 7 and 9 on your source code?
>I just establish iXLversion once in the initial form load.
I was actually wondering why this is necessary. You basically tell the old excel to save in the old format, and new Excel to save in the new format. But they both probably would do exactly that without any extra effort.
I was actually wondering why this is necessary. You basically tell the old excel to save in the old format, and new Excel to save in the new format. But they both probably would do exactly that without any extra effort.
I insist, lines 7 and 9 are not necessary, because between 6 and 9 there is no process with the Excel instance raised on line 1, so why create another instance (line 9) if I can use the one created by the line 1?
I also believe that line 7 is leaving an excel instance in memory because there is no previous oXLApp.Quit.
I also believe that line 7 is leaving an excel instance in memory because there is no previous oXLApp.Quit.
ASKER
About lines 7 and 9: Presented code was misleading. I just grabbed two pieces. Should have presented them in two different listings. The purpose of establishing iXLversion is lost to ancient history. I must have had a reason back then. I believe it is to handle differences between .xls and ,xlsx
I do this in main form load just once, I open the resident version of Excel, get the version, and close it. iXLversion is then available for use in various places in the entire package.
By the way: Martin was kind enough to put my submission into line-numbered coding form. For the future, how do I do that?
I do this in main form load just once, I open the resident version of Excel, get the version, and close it. iXLversion is then available for use in various places in the entire package.
By the way: Martin was kind enough to put my submission into line-numbered coding form. For the future, how do I do that?
Select the code and then click the indicated icon.
"If program is going to be writing back to same installation folder, don't install in the default "Program" windows folders."
If the program is going to be writing to the installation folder, rewrite the program, because sooner or later this gross incompatibility with modern security standards won't be tolerated any longer.
If the program is going to be writing to the installation folder, rewrite the program, because sooner or later this gross incompatibility with modern security standards won't be tolerated any longer.
ASKER
Vadim: I've posted this as a separate question.