BSkene, sithstalker: I believe the temp file cleanup which happens when the Module Manager is closed was getting stuck for you in 3.2.11. Please try 3.2.12-svn9018.
It never rains but it pours.
I figures I should uninstall 3.2.11 before running the new exe. But that generated an error (I was able to uninstall a different program I wanted to get rid of anyway). So I went ahead and ran the exe. There was no difference. 1 start up, then nothing on the 2nd attempt.
Thanks for all the work you’re doing on this by the way.
Thus spake BSkene:
“uckelman” wrote:
BSkene, sithstalker: I believe the temp file cleanup which happens
when the Module Manager is closed was getting stuck for you in 3.2.11.
Please try 3.2.12-svn9018[1].It never rains but it pours.
I figures I should uninstall 3.2.11 before running the new exe. But that
generated an error (I was able to uninstall a different program I wanted
to get rid of anyway).
What error? We can’t troubleshoot problems for which we don’t have any
details.
So I went ahead and ran the exe. There was no
difference. 1 start up, then nothing on the 2nd attempt.
Would you answer my question about the errorLog, please?
–
J.
Thus spake Rindis:
“uckelman” wrote:
Thus spake Rindis:
Ah, ha. Yep, that was the problem. I’ll note that the entry in the
App
menu (which is the Win 8 Start Menu with a different layout) has the
problem.I don’t follow—has what problem? Are you saying that the entry in
the App menu has a bad path? If so, what is the bad path?The install of 3.2.11 left the shortcut for Vassal pointed at the old
(Progam Files (x86)) path instead of updating to the 64-bit Program
Files path.
Did you check the box telling the installer to create a desktop shortcut
for this install?
I’ll also note that my main desktop machine (Win 7) has not had this
problem, but all the file extension associations went away when I
upgraded to 3.2.11 (was fine with 3.2.10).Can you be more specific about this? Did this happen with a custom
install? With a regular install?–
J.Custom install. I still have 3.1.20 installed as well as the latest
3.2.x (and of course, I occasionally have testing versions installed),
so I always go custom to manage which versions are on the machine. This
has never had a problem (or at least, not this problem), but this last
time, the extension associations went away.
We’ve never had file associations for module extensions (.vext). Or is
this not what you’re saying?
–
J.
Rindis, try 3.2.12-svn9019: vassalengine.sourceforge.net/builds/
Nothing changed in the Windows installer between 3.2.9 and 3.2.11, so I don’t have any explanation for what you’re seeing. However, I made a change in trunk@9019 which causes the installer to be more paranoid about ensuring that it is writing to the correct (32- or 64-bit) registry hive.
No. I never use desktop shortcuts, and always use the Start Menu (or Start screen, in the case of Win 8, here). I don’t know if a desktop shortcut would have been replaced/updated, but the Start/App Menu one was not.
[/quote]
Um, no, it’s not. All the file extension associations went away. *.vsav, *.vmod, *.vlog…
Thus spake Rindis:
Did you check the box telling the installer to create a desktop
shortcut
for this install?No. I never use desktop shortcuts, and always use the Start Menu (or
Start screen, in the case of Win 8, here). I don’t know if a desktop
shortcut would have been replaced/updated, but the Start/App Menu one
was not.
Did the most recent 3.2.12 build do the right thing in this regard?
Um, no, it’s not. All the file extension associations went away.
*.vsav, *.vmod, *.vlog…
Same question.
–
J.
Okay, this gets complicated:
Since the given problem was the shortcut not switching over correctly on Win 8, I uninstalled Vassal and installed 3.2.8, which installs to the ‘(x86)’ directory.
Then I did a standard install of 3.2.12-svn9019 (which is what I did with .11 earlier). Install goes fine, Vassal launches at the end of the install. Close, and go to the Start/App Menu. Vassal is there, but refuses to launch. Try a couple more times: nothing. Check everything: Vassal is indeed in the (x86) directory, the shortcut is pointing there; everything looks fine. Try a couple more times: nothing.
Open Task Manager: There is about a dozen copies of “Java™ Platform SE binary” listed, plus one that says, “Java™ Platform SE binary (32 bit)”. I can close the former, but not that last one. Clean up the various extra copies: Vassal starts. (I have seen this situation once before recently, but wasn’t paying attention enough to know how I got there, or what I was doing at the time.)
Close Vassal, copy of Java appears in Task Manager. Try to start Vassal. No Vassal, but a second copy of Java appears in Task Manager. End task on those two, go to menu, Vassal starts this time. (I poke around after this, and it looks like full sequence is: Launch Vassal, copy of Java appears, Module Manager comes up, copy of Java disappears, exit Vassal, copy of Java reappears.)
Back to main task: Install 3.2.12-svn9019. Message: “Windows protected your PC – Windows SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.” Run anyway.
Standard install goes fine, and the menu shortcut now points at the standard (64-bit) directory, and will launch Vassal fine. However, the Java problem causing it to not be able to launch twice in a row (as above) persists.
Windows 7; Custom Install
Start installer, and the ‘Remove Old Versions’ dialog only shows 3.1.20. 3.2.11, which is installed on the machine (I’ve been running it), and is listed in the Control Panel uninstall list, does not show in the Vassal installer dialog.
Rest of the install goes fine. File associations are back.
I tend to suspect that something odd (and likely inexplicable) just happened when I installed 3.2.11 on my main machine. But the fact that the installer can’t see the previous version is interesting.
Thus spake Rindis:
Standard install goes fine, and the menu shortcut now points at the
standard (64-bit) directory, and will launch Vassal fine. However, the
Java problem causing it to not be able to launch twice in a row (as
above) persists.
Now it looks like you’re having the same problem as BsKene and
sithstalker.
I tend to suspect that something odd (and likely inexplicable) just
happened when I installed 3.2.11 on my main machine. But the fact that
the installer can’t see the previous version is interesting.
Check in the registry under HKLM\Software\vassalengine.org\VASSAL.
What do you see there?
Does the 3.2.12-svn9016 installer see 3.2.11?
–
J.
Rindis, if VASSAL now won’t start for you on subsequent attempts, please post the errorLog you’re getting from the first attempt.
Okay, error log after first (successful) launch on Win 8:
2014-02-24 08:41:30,807 [0-main] INFO VASSAL.launch.StartUp - Starting
2014-02-24 08:41:30,807 [0-main] INFO VASSAL.launch.StartUp - OS Windows 8 6.2
2014-02-24 08:41:30,807 [0-main] INFO VASSAL.launch.StartUp - Java version 1.6.0_45
2014-02-24 08:41:30,807 [0-main] INFO VASSAL.launch.StartUp - VASSAL version 3.2.12-svn9019
2014-02-24 08:41:30,994 [0-AWT-EventQueue-0] INFO VASSAL.launch.ModuleManager - Manager
2014-02-24 08:41:46,813 [0-AWT-EventQueue-0] INFO VASSAL.launch.ModuleManagerWindow - Exiting
And it doesn’t start on the second go, and the Error Log is not updated.
I’ll try to remember to test svn9016 on my Win7 desktop tonight.
Thus spake Rindis:
“uckelman” wrote:
Rindis, if VASSAL now won’t start for you on subsequent attempts,
please post the errorLog you’re getting from the first attempt.Okay, error log after first (successful) launch on Win 8:
2014-02-24 08:41:30,807 [0-main] INFO VASSAL.launch.StartUp - Starting
2014-02-24 08:41:30,807 [0-main] INFO VASSAL.launch.StartUp - OS
Windows 8 6.2
2014-02-24 08:41:30,807 [0-main] INFO VASSAL.launch.StartUp - Java
version 1.6.0_45
2014-02-24 08:41:30,807 [0-main] INFO VASSAL.launch.StartUp - VASSAL
version 3.2.12-svn9019
2014-02-24 08:41:30,994 [0-AWT-EventQueue-0] INFO
VASSAL.launch.ModuleManager - Manager
2014-02-24 08:41:46,813 [0-AWT-EventQueue-0] INFO
VASSAL.launch.ModuleManagerWindow - ExitingAnd it doesn’t start on the second go, and the Error Log is not updated.
I’ll try to remember to test svn9016 on my Win7 desktop tonight.
Please also try to determine the latest version which does not have
the startup problem for you.
–
J.
Registry: I see a subfolder marked “VASSAL (3.1.20)” with an InstallLocation key (or whatever it would be called).
The svn9016 installer only sees 3.1.20. It does not see 3.2.11, nor does it see 3.2.12-svn9019 (which is still installed).
I… can’t seem to find one that doesn’t have the problem. I’ve gone all the way back to 3.1.17 (earliest version I had to hand), and they all showed the same behavior on my Win 8 machine.
If there’s any particular version you want me to try, just tell me.
Thus spake Rindis:
Registry: I see a subfolder marked “VASSAL (3.1.20)” with an
InstallLocation key (or whatever it would be called).The svn9016 installer only sees 3.1.20. It does not see 3.2.11, nor does
it see 3.2.12-svn9019 (which is still installed).
What does the 3.2.12-svn9019 installer see?
–
J.
Thus spake Rindis:
I… can’t seem to find one that doesn’t have the problem. I’ve gone
all the way back to 3.1.17 (earliest version I had to hand), and they
all showed the same behavior on my Win 8 machine.
This is exactly what I expected would happen. I think the problem
is with your install of Java, not with VASSAL. Try uninstalling and
reinstalling Java.
–
J.
Hmm… two versions of Java present: 6 Update 27 and 6 Update 45 (64-bit)…
Uninstalled both, went to java.com, and it installed 6 Update 51. Reinstalled Vassal 3.2.11, and it seems to work now.
Now, I hadn’t fiddled with Java on my machine. (I think the second copy is from Vassal 3.1.20 installing.) So, I would think that it was still the original configuration from Microsoft when they put together the Surface Pro 2…
Thus spake Rindis:
“uckelman” wrote:
Thus spake Rindis:
I… can’t seem to find one that doesn’t have the problem. I’ve
gone
all the way back to 3.1.17 (earliest version I had to hand), and
they
all showed the same behavior on my Win 8 machine.This is exactly what I expected would happen. I think the problem
is with your install of Java, not with VASSAL. Try uninstalling and
reinstalling Java.–
J.Hmm… two versions of Java present: 6 Update 27 and 6 Update 45
(64-bit)…
Oh, yes. Having more than one version of Java installed tends to
cause neither to work properly, in my experience. I should have asked
about that.
–
J.
Rindis, I believe I know why your file associations disappeared: The uninstaller was unconditionally removing VASSAL file associations if they existed—which is incorrect if those file associations were put there by a different version of VASSAL. This causes a problem only when you run the uninstaller manually. When the uninstaller is launched from a later version of the installer, new file associations are established by the (new) installer after the (old) uninstaller removes them, which is why most people would never see the problem.
I’ve fixed this in 3.2.12-svn9021: vassalengine.sourceforge.net/builds/
I won’t do anything further on this problem until I hear back that someone having it has only one version of Java installed.