windows .exe wrapper preventing console output about amidst HOT 10 OPEN

I currently to not have a Windows installation at hand. Just to be sure I understand the issue correctly: The exe never outputs anything on the console and the -help parameter was just an example? Also, does the console prompt return immediately after you execute amidst-v4-0-beta6.exe, or does it wait until Amidst is closed.

Since AmidstExporter and Amidst 4 both use launch4j for the Windows wrapper, the issue is probably related to this tool. I had a look at the documentation and we might be able to solve this by setting the property header=console or stayAlive=true.

from amidst.

See: http://www.indigorose.com/webhelp/tu/Windows_Basics/Command_Line_Arguments.htm
I haven't tried this with either program.
Why would someone open a command window to do this?

from amidst.

See: https://en.wikipedia.org/wiki/Command-line_interface
It is simply a matter of good application design to provide a command line interface, especially when the application accepts command line parameters. I know, it is uncommon and annoying to use the Windows command prompt, but it is quite common to use on Unix based systems.

from amidst.

The exe never outputs anything on the console and the -help parameter was just an example?

Correct. I never noticed it before because Amidst used to open a log window, then Amidst4 removed that window (good idea) but wasn't running on one of my computers so I went to view the log via the command-line.

It's a low priority issue because launch4j is still passing commandline args to the app correctly, i.e. -log amidstlog.txt still works, and because anyone who needs an interactive commandline can use the jar.

Also, does the console prompt return immediately after you execute amidst-v4-0-beta6.exe, or does it wait until Amidst is closed.

Yup, that would be the problem... command-prompt returns immediately. Because we can't pick stayAlive dynamically, I'm not sure which way it should be. We could leave stayAlive=false until someone adds a feature that needs commandline output.

from amidst.

Regarding the log window: Amidst still displays the crash window, when a crash occurs. The difference is, that I handled some errors more user friendly that would previously have caused a crash.

I do not know the exact difference between the header=console and the stayAlive=true options, however, since we run a GUI application I think we should first try to set stayAlive=true. I will include this change in the next beta, so we can test whether it fixes this bug and whether it has undesirable side-effects.

from amidst.

I just release the v4.0-beta7 which includes the possible fix for this issue. Can you try it out?

from amidst.

It hasn't made any difference to the behavior. beta7 still returns to the command-line immediately.

I take it you're not on a Windows system, which system are you using?

from amidst.

This is unfortunate. I am running an Ubuntu Linux operating system. Maybe you can try the other combinations of the header and stayAlive properties, since you are running Windows and are able to directly test whether the problem is solved? Otherwise, we would need a new release for each combination :-P You can see how to change the properties in #49 . The build process for the windows wrapper is described in this wiki entry.

from amidst.

Since I now have a windows machine available, I looked into this. It is fixed by #83.

from amidst.

I reopen this, because I reverted the fix, which had an undesireable side-effect. Namely, opening a dos-box which displayed stdout.

My hunch is still, that the current version of the pom.xml should result in a fixed exe file. However, it does not and I think this is a bug in launch4j. I might create a bug report about this when I get the time.

See also: How can I use launch4j to wrap a GUI application that also provides a command line interface?. Sadly, there were no answers.

from amidst.