I noticed that we use 2 different ways to set the DefaultError name from its path in 2 different places.
This patch ensures we always use MiscUtilities.getFileName to do this.
Just in case it's helpful, I have attached a patch combining this and the patch from tracker item 3517170.
Removed patch containing out-dated code.
Sorry, having updated to latest I now see you have fixed the main issue. The replacement patch attached just (hopefully) ensures this won't happen again. Feel free to ignore it if you prefer not to call a setter from the constructor.
I can see that this patch does effectively refactor out one redundant line of code, so in that sense it is not a bad thing to apply, but I can't think of a situation this patch can fix - that is, if there was a problem before with errors not disappearing, I don't see how this can fix it. But thank you for testing my new FileOpenerService! In the future, if you find a bug, please describe detailed steps to reproduce it.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.