End Logfile dump error V3.3.1

But we used to put up a much friendlier error in the “just couldn’t write the file” or “just couldn’t rename the tmp file” cases, not the normal “Vassal has encountered an error. Click here for huge scary stack trace” error.

Thus spake Cattlesquat:

But we used to put up a much friendlier error in the “just couldn’t
write the file” or “just couldn’t rename the tmp file” cases, not the
normal “Vassal has encountered an error. Click here for huge scary stack
trace” error.

I’m not following here. What makes you think we’re showing a different
error dialog than before?


J.

Here is friendlier file-write failure from Vassal 3.2.17 (you can repro by editing a module, opening the module in 7 zip, and then trying to save the module from the module editor)

[attachment=1]friendlyfail.png[/attachment]

Now here is what happens when you do the exact same thing in the 3.3 line…

[attachment=0]unfriendlyfail.png[/attachment]

Somewhere along the way we lost a path that went to a friendlier write message.

Brian

Isn’t the second one friendlier? Both have the stacktrace hidden behind “show details” but the first has this intimidating red cross, says “unable to do something” which could also be an accusation of the user, and just an “OK” button, while the second one has a cute little bug, none of the alarming red colors, says “we had an internal problem, nothing to do with you dear user” and even offers a way to communicate with the Vassal team.

Agree with you on the ‘friendliness’ measurements.

The main problem with the second version is that it pushes a new bug report into bugzilla for a something that isn’t really a bug.

Something between the two would be better. No bug report option but less intimidating and it should rename the tmp file to something better (gamemodule-copy23vmod instead of TMP122323j2jj3.zip) and tell the user where to find it.

I apparently get a mostly blank crash window when I get VASSAL to crash…see my post in the [url]https://forum.vassalengine.org/t/surface-not-cachable-3-3-2/10910/1] thread…

Edit: Okay, realized I should probably try the latest release (3.3.2), and it populates the error window correctly. So, false alarm, I guess.

Thus spake Cattlesquat:

Here is friendlier file-write failure from Vassal 3.2.17 (you can repro
by editing a module, opening the module in 7 zip, and then trying to
save the module from the module editor)

friendlyfail.png

Now here is what happens when you do the exact same thing in the 3.3
line…

unfriendlyfail.png

Somewhere along the way we lost a path that went to a friendlier write
message.

Am I the only one who read the stack trace? :slight_smile:

The bug dialog was not displayed for the write error. The bug dialog was
displayed because there was an NullPointerException when trying to display
the write error dialog.


J.

Haha I probably got to “Error.ProblemDialog” and stopped reading.

But since we’ve got a discussion of error UI flow going, some opinions!
(1) Apart from the scary-red-X, the first dialog box is more “normal user friendly” because it (a) explains a fairly specific problem in fairly common English, (b) doesn’t ask scary “send-in-a-bug-report” questions which make it sound like Vassal has crashed, and (c) doesn’t follow up with the “and now Vassal may or may not be stable any more” message.
(2) But yes let’s get rid of the red X!
(3) And absolutely yes, let’s go to a better filename (approximating our desired filename with a .vmod extension). Operating systems usually do things like putting a (1) and then a (2) etc after the name.
(4) And preferably make the explanation a little better here, like a reasons-could-include-this-file-being-open-in-another-window-or-app.

Thus spake Cattlesquat:

(c) doesn’t
follow up with the “and now Vassal may or may not be stable any more”
message.

That’s true in the cases when the bug report dialog is shown.

(2) But yes let’s get rid of the red X!

What’s done on Windows natively these days when a file can’t be written?

(3) And absolutely yes, let’s go to a better filename (approximating our
desired filename with a .vmod extension). Operating systems usually do
things like putting a (1) and then a (2) etc after the name.
(4) And preferably make the explanation a little better here, like a
reasons-could-include-this-file-being-open-in-another-window-or-app.

Open a ticket?


J.

It’s very app-dependent and situation-dependent. Like Notepad trying to save a file on top of one that’s already open says “The process cannot access the file because it is being used by another process.”. Whereas if you’re in the “file explorer” (i.e. a folder) and have a copied file in your clipboard and try to paste on top of an existing file of the same name it will add " - Copy" to the end of the filename, and after that it goes to " - Copy(2)" etc.

Will do – now open as 13204 (vassalengine.org/tracker/sho … i?id=13204). I’m assuming that getting this particular situation back to displaying our traditional file-write problem dialog is already being handled separately, unless you let me know you want me to open one for that too.

Actually I’m going to open a bug 13205 (vassalengine.org/tracker/sho … i?id=13205) for the NPE displaying the file dialog.

Brian

Thus spake Cattlesquat:

It’s very app-dependent and situation-dependent. Like Notepad trying to
save a file on top of one that’s already open says “The process cannot
access the file because it is being used by another process.”. Whereas
if you’re in the “file explorer” (i.e. a folder) and have a copied file
in your clipboard and try to paste on top of an existing file of the
same name it will add " - Copy" to the end of the filename, and after
that it goes to " - Copy(2)" etc.

Hmm. That’s disappointing. I’d thought there’d be a standard way.

Will do. I’m assuming that getting this particular situation back to
displaying our traditional file-write problem dialog is already being
handled separately, unless you let me know you want me to open one for
that too.

That dialog display bug is one which is (a) old, (b) almost for sure has
at least one ticket open already, and (c) I think isn’t our bug. The
ticket will probalby have the name of the function where the NPE happened
in it.

Go find it and post a link here?


J.

I think it’s this bug: vassalengine.org/tracker/sho … gi?id=4159

It’s a bug in MigLayout. I fixed this problem in 2012 and sent them a patch. (See the commit message for c23c4c13.) In that commit, I added a modified miglayout-swing JAR, containing my patch… I wonder if that JAR got blown away… yes, yes, I think it did when we switched to using Maven.

So that’s the problem—pulling the unpatched miglayout-swing-4.2.jar via maven reintroduced the bug.

The link in my commit message to my MigLayout forum post (and whole forum, apparently) is dead, but fortunately I still have the patches. I’m not sure what the best approach is here—I’d assumed that they had merged my patch, but apparently they kicked the bucket before they got to it.

I wonder if anyone else picked up development?

This looks like the current (?) git repo: github.com/mikaelgrev/miglayout

I guess 13205 can represent “re-fixing that”. I will add a reference to your above messages.

That repo did pick up my patch. Looks like there is a 5.1 release.

PR: github.com/vassalengine/vassal/pull/116

Please try vassalengine.org/~uckelman/t … ows-64.exe in the situation where the file being saved isn’t writable. This build includes a miglayout-swing JAR new enough to include the patch I contributed to them, so you should not see a bug dialog with it.

Here is what I see. [attachment=1]Annotation 2020-07-24 062944.png[/attachment]

Good, that fixed the dialog display bug. Thanks for trying the test build.

I’m merging PR #116 now that we’ve confirmed it fixes that problem.