Normally no, I have to log out to see them along with avatars and other niceties. So you need for all 3 systems you use or only linux?
Really ? I see all the signatures etc while logged in. Are you using another viewer ?
its how I always setup any forums I read its on the forum settings.
My work platform is Linux, is all I use personally. But I make an app that is used on Linux, Windows and Mac. The decision to use Lazarus was its ability to do just that.
what happens when its not started from a console? would you be ok (for example in windows) to always show the console regardless if the gui form is shown? How about replacing the console output with a better formatted html (or rtf or anything else) view?
Honestly, Windows and Mac users do not want to see a console, so, let them be. What I am think about is an app that can be console if it gets particular parameters on the command line on Linux but is a GUI-only on Windows and Mac. Linux users love to script things up.
Ok on windows there are 2 different solutions
make sure the option Win32 GUI application is not checked in the project options and the first code you run is to hide the console from the end user. After that if command line parameters are in place show it write the help and readln to exit.
Second choice is to allocConsole; sysinitSTDOut; IsConsole := true; after the parameter check succeed.
Don't forget to readln to allow the user to read the help before closing the window.
On other system I have no idea.
My prefared solution would be to have an html with the help somewhere on the disk an call openDocument on it. That would give you more freedom and make things a bit easier for the end user too.
@Thaddy, thanks, (sorry I missed your message before my last reply), I did not know about forcing Windows to have a console. Thats something I will have to look into. I have a number of built in debug switches but when a Windows user asks me how to use them, I get worried .....
I wonder if that "force a windows console" trick would protect from the nasty crash that Windows does if it encounters a writeln(), I tend to use them a lot when debugging. Windows does not like writeln() ! (and the answer of course is the use debugln() instead of writeln(), its safe on all platforms).
Davo
When developing under Linux, its far
Lets place the blame where it belongs. its not windows that does not like it its the default setup of FCL in windows that does not like it and our own inability to set it up correctly to accept it.
There are a number of options for that If I remember correctly, and that was long ago, you need to allocate a console window initialize the output,stdOut, stdIn, etc global variable properly and writeln will work as expected
there is a streamIO(?) unit you can use as an inspiration that does something similar sorry the details are foggy.
Or you can wait for thaddy to provide the code that he has.