Recent

Author Topic: [solved]non-GUI "mainForm"  (Read 1976 times)

dbannon

  • Hero Member
  • *****
  • Posts: 3614
    • tomboy-ng, a rewrite of the classic Tomboy
[solved]non-GUI "mainForm"
« on: April 28, 2020, 05:18:18 am »
I know its silly wording but you get the idea.

Is it possible for the first unit of a Lazarus application to be a non-GUI one ?  Simplest example is perhaps a unit that looks at the command line parameters, if it sees --help then it should just print some help and exit.

That non-gui unit could go onto dynamically create forms if necessary.

That would avoid the end user seeing a form flash up and then disappear.

I have not tried it yet myself, maybe someone will tell me not to bother ....

Davo
« Last Edit: April 29, 2020, 01:55:16 am by dbannon »
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

eljo

  • Sr. Member
  • ****
  • Posts: 468
Re: non-GUI "mainForm"
« Reply #1 on: April 28, 2020, 05:33:14 am »
depends on what you mean with the phrase "it should just print some help and exit" print it where? and depending on your answer you might need to provide the target OS as well so it would be nice to add it in advance.

bytebites

  • Hero Member
  • *****
  • Posts: 767
Re: non-GUI "mainForm"
« Reply #2 on: April 28, 2020, 06:34:20 am »
Projects main file checks parameter count and exits if none
Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. uses
  6.   {$IFDEF UNIX}
  7.   cthreads,
  8.   {$ENDIF}
  9.   {$IFDEF HASAMIGA}
  10.   athreads,
  11.   {$ENDIF}
  12.   Interfaces, // this includes the LCL widgetset
  13.   Forms, unit1
  14.   { you can add units after this };
  15.  
  16. {$R *.res}
  17.  
  18. begin
  19.   if ParamCount<2 then begin
  20.     writeln('help');
  21.     exit;
  22.   end;
  23.   RequireDerivedFormResource:=True;
  24.   Application.Scaled:=True;
  25.   Application.Initialize;
  26.   Application.CreateForm(TForm1, Form1);
  27.   Application.Run;
  28. end.
  29.  

Thaddy

  • Hero Member
  • *****
  • Posts: 18524
  • Here stood a man who saw the Elbe and jumped it.
Re: non-GUI "mainForm"
« Reply #3 on: April 28, 2020, 07:37:57 am »
@bytebites Windows also need {$apptype console} for that to work. Otherwise there is no console to write to.... Linux is OK.
The GUI app part should still work.
You can also create and set up the console manually if needed.
This should work with {$apptype console} and use windows in the program file.
Code: Pascal  [Select][+][-]
  1.     ShowWindow(GetConsoleWindow, SW_HIDE); // hide the console
  2.    if ParamCount<2 then
  3.    begin
  4.          ShowWindow(GetConsoleWindow, SW_SHOW); // only show if needed
  5.          writeln('help');
  6.       exit;
  7.   end;
  8.  // the rest of your code
« Last Edit: April 28, 2020, 07:58:42 am by Thaddy »
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

dbannon

  • Hero Member
  • *****
  • Posts: 3614
    • tomboy-ng, a rewrite of the classic Tomboy
Re: non-GUI "mainForm"
« Reply #4 on: April 28, 2020, 07:47:22 am »
yep, bytebites, indeed that does work.

I made a simple unit with one function that returns false, then in the main project file, I ask it should we continue, it says no and we call exit.  Thats pretty obvious I guess but never considered putting things like an 'if' statement in there !

Thanks.

@eljo, see my sig ?  If you are starting from the Linux command line, its likely you have a console, (but maybe one no one is looking at it). Windows does also have a console but no one wants to use it, so write your output  with debugln, it can be captured to a file. Mac, sigh, its all just just too hard to start what might be a GUI app from the console. Possible, but ...

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

Thaddy

  • Hero Member
  • *****
  • Posts: 18524
  • Here stood a man who saw the Elbe and jumped it.
Re: non-GUI "mainForm"
« Reply #5 on: April 28, 2020, 07:59:17 am »
@dbannon: for windows see my remark.
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

eljo

  • Sr. Member
  • ****
  • Posts: 468
Re: non-GUI "mainForm"
« Reply #6 on: April 28, 2020, 08:25:55 am »
yep, bytebites, indeed that does work.

I made a simple unit with one function that returns false, then in the main project file, I ask it should we continue, it says no and we call exit.  Thats pretty obvious I guess but never considered putting things like an 'if' statement in there !

Thanks.

@eljo, see my sig ? 
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?
If you are starting from the Linux command line, its likely you have a console, (but maybe one no one is looking at it). Windows does also have a console but no one wants to use it, so write your output  with debugln, it can be captured to a file. Mac, sigh, its all just just too hard to start what might be a GUI app from the console. Possible, but ...

Davo
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?

Thaddy

  • Hero Member
  • *****
  • Posts: 18524
  • Here stood a man who saw the Elbe and jumped it.
Re: non-GUI "mainForm"
« Reply #7 on: April 28, 2020, 09:05:55 am »
Does not matter.
It creates a console, but before it is shown it is immediately hidden and only shown if the Paramcount < 2, It is a quick solution.
Creating the console by hand and connect stdio etc requires a lot more code, but may be a better solution.
« Last Edit: April 28, 2020, 09:08:02 am by Thaddy »
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

dbannon

  • Hero Member
  • *****
  • Posts: 3614
    • tomboy-ng, a rewrite of the classic Tomboy
Re: non-GUI "mainForm"
« Reply #8 on: April 28, 2020, 09:37:44 am »
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 ?   
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.

Quote
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.

@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
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

eljo

  • Sr. Member
  • ****
  • Posts: 468
Re: non-GUI "mainForm"
« Reply #9 on: April 28, 2020, 08:20:08 pm »
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.

Quote
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.

dbannon

  • Hero Member
  • *****
  • Posts: 3614
    • tomboy-ng, a rewrite of the classic Tomboy
Re: non-GUI "mainForm"
« Reply #10 on: April 29, 2020, 01:54:45 am »
Well, I am quite happy with what I have now.

* Windows and Mac users don't want a console, so I pop up nicely formatted notes with help content.
* Linux users will fight to the death for their console and expect some help there if they ask. Easy done.
* My app does quite a lot more during startup that requires an exit, eg it makes sure its the only instance running. If there is another instance, bring it to foreground and exit. (particularly important on some Gnome3 distros that won't show the system tray.)  I now know how to do that without a flicker of a form appearing and disappearing. (thanks bytebits!)
* I always check for writeln()s towards the end of a release cycle.

Its all good !

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

 

TinyPortal © 2005-2018