Re: [Lazarus] Startup environment: to Gui, or not to GUI?

2017-04-11 Thread Mark Morgan Lloyd via Lazarus 

On 11/04/17 16:00, Henry Vermaak via Lazarus wrote:

On Tue, Apr 11, 2017 at 01:34:35PM +, Mark Morgan Lloyd via Lazarus wrote:> Something like this does appear to work, tested on Linux 
only.> > function notGui(): boolean;> > var i: integer;> > begin>   i := IsaTty(Input);> {$ifdef ISGUI }>   exit 
false;> {$endif ISGUI }> {$ifdef NOGUI }>   exit true;> {$endif NOGUI }>   result := i <> 0> end { notGui } ;> > 
The explicit overrides might be needed during debugging, since the> involvement of gdb forces the program to think it's being run from a 
shell> session.
I'd recommend making the overrides command line parameters.  That wayyou do 
away with the ifdefs and a user can always override it if yourlogic somehow 
doesn't do the right thing.


I agree, --GUI and --TUI by choice (case-sensitive, no short form). But 
from the POV of getting a statement of what appeared to work and its 
limitations into the record I didn't want to introduce anything extraneous.



Looking back through older sources, I've had to jump through hoops-> reopening the 
input and using GetFileType() under Windows- to find out> whether stdin was piped. 
Fortunately I don't need that here.

The experience on Windows is pretty awful and I've seen some interestingtricks 
to get a program to do the right thing based on where it waslaunched from.  For 
example, Visual Studio's devenv.com vs. devenv.exe,using the fact that .com 
takes preference over .exe in the terminal tohandle the command line parameters 
and sending output to the terminalthat it was called from.


Regrettably, investigating that sort of thing in too much depth can get 
one flagged as a malware writer. A few days ago I saw something very odd 
happen as a result of some search terms I used when reading up about a 
particular comms protocol.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Opening file in editor window if it's loaded in another editor window

2017-04-11 Thread Jürgen Hestermann via Lazarus 

Am 2017-04-11 um 18:18 schrieb Mattias Gaertner via Lazarus:
> On Tue, 11 Apr 2017 17:39:13 +0200
> Jürgen Hestermann via Lazarus  wrote:
>> I have 2 editor windows ("Source Editor" and ""Source Editor (2)"
>> and have loaded "Unit1.pas" in both of these windows.
>> After I have now (inadvertently) closed "Unit1.pas" in "Source Editor"
>> I cannot load it again with "File Open".
>> It just happens nothing.

> It should focus the "Unit1.pas" in "Source Editor (2)".

No, it does just nothing.
Focus is on the IDE afterwards (not on an editor window).


> To open the unit a second time you have to use "Clone to other window".

Yepp, this works.
Although it took me a while to find out that this function
can only be found after a right click on the file name tab
(even though I already used it before but only once).
It seems not in the main menu somewhere, or is it?

I thought that "opening" a file while in an editor (windows)
should open the file in the current editor window
independently from other editor windows.

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Startup environment: to Gui, or not to GUI?

2017-04-11 Thread Henry Vermaak via Lazarus 
On Tue, Apr 11, 2017 at 01:34:35PM +, Mark Morgan Lloyd via Lazarus wrote:
> Something like this does appear to work, tested on Linux only.
> 
> function notGui(): boolean;
> 
> var i: integer;
> 
> begin
>   i := IsaTty(Input);
> {$ifdef ISGUI }
>   exit false;
> {$endif ISGUI }
> {$ifdef NOGUI }
>   exit true;
> {$endif NOGUI }
>   result := i <> 0
> end { notGui } ;
> 
> The explicit overrides might be needed during debugging, since the
> involvement of gdb forces the program to think it's being run from a shell
> session.

I'd recommend making the overrides command line parameters.  That way
you do away with the ifdefs and a user can always override it if your
logic somehow doesn't do the right thing.

> Looking back through older sources, I've had to jump through hoops-
> reopening the input and using GetFileType() under Windows- to find out
> whether stdin was piped. Fortunately I don't need that here.

The experience on Windows is pretty awful and I've seen some interesting
tricks to get a program to do the right thing based on where it was
launched from.  For example, Visual Studio's devenv.com vs. devenv.exe,
using the fact that .com takes preference over .exe in the terminal to
handle the command line parameters and sending output to the terminal
that it was called from.

Henry
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Opening file in editor window if it's loaded in another editor window

2017-04-11 Thread Jürgen Hestermann via Lazarus 

I have 2 editor windows ("Source Editor" and ""Source Editor (2)"
and have loaded "Unit1.pas" in both of these windows.
After I have now (inadvertently) closed "Unit1.pas" in "Source Editor"
I cannot load it again with "File Open".
It just happens nothing.

A known bug?

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Startup environment: to Gui, or not to GUI?

2017-04-11 Thread Mark Morgan Lloyd via Lazarus 

On 11/04/17 10:30, Mark Morgan Lloyd via Lazarus wrote:

On 11/04/17 10:00, Henry Vermaak via Lazarus wrote:> On Tue, Apr 11,
2017 at 09:15:16AM +, Mark Morgan Lloyd via Lazarus wrote:>
Apologies if this is an FAQ.> > Is there an orthodox way that a Lazarus
program can very early on look at> how it's been started and decide
whether it can usefully fall back to a text> mode, e.g. to display help
info on stdout rather than a messagebox?> isatty() is traditionally used
for this on POSIX operating systems.It's in unit termio.
Thanks Henry, I'll check. I know I've used it in the past when deciding
whether a program was actually being fed piped input etc.


Something like this does appear to work, tested on Linux only.

function notGui(): boolean;

var i: integer;

begin
  i := IsaTty(Input);
{$ifdef ISGUI }
  exit false;
{$endif ISGUI }
{$ifdef NOGUI }
  exit true;
{$endif NOGUI }
  result := i <> 0
end { notGui } ;

The explicit overrides might be needed during debugging, since the 
involvement of gdb forces the program to think it's being run from a 
shell session.


Looking back through older sources, I've had to jump through hoops- 
reopening the input and using GetFileType() under Windows- to find out 
whether stdin was piped. Fortunately I don't need that here.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Startup environment: to Gui, or not to GUI?

2017-04-11 Thread Mark Morgan Lloyd via Lazarus 

On 11/04/17 11:00, Tony Whyman via Lazarus wrote:

This question could be reformulated as "How do I dynamically determine
the correct GUI to use or whether to use the nogui interface."
My understanding is that Lazarus programs usually do this at link time
as a result of setting the LCL_PLATFORM environment variable.


Well, no, it couldn't :-)

What I'm doing is writing a  program using the Lazarus IDE and creating 
the project as "Application" so that I can easily add a full GUI later. 
I'm manually inserting code immediately after Application.Initialize to 
pick up command-line options (including --help and --version) which also 
gives me the ability to run the entire program from the command line if 
sufficient options/parameters have been supplied.


My experience in the past has been that this approach is reliable, and 
that it's also possible to raise a dialog for cases such as a program 
being run from the GUI but with a --version option.


I'm hoping to use this program as a testbed to run in three ways: 
non-interactively if sufficient options are supplied, with a GUI if no 
options are supplied, and /possibly/ using a TUI created by dialedit3b 
but this very much depends on whether the modifications required to get 
it working can be done in the limited time available.


What that will mean in practice is that irrespective of what widget set 
the program is compiled for it will also have the capability of running 
as a non-interactive (batch) utility. Call me old-school if you like but 
I find that useful.


http://free-pascal-general.1045716.n5.nabble.com/Free-Vision-etc-form-editor-td5727305.html

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Startup environment: to Gui, or not to GUI?

2017-04-11 Thread Alexey via Lazarus 

Hi

I use text out in CudaText GUI editor. Just call Writeln(.); and 
then Halt. Inside Form's OnCreate method.



On 11.04.2017 12:15, Mark Morgan Lloyd via Lazarus wrote:


Is there an orthodox way that a Lazarus program can very early on look 
at how it's been started and decide whether it can usefully fall back 
to a text mode


--
Regards,
Alexey

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Modifying the "File -> New Unit" template

2017-04-11 Thread Mattias Gaertner via Lazarus 
On Tue, 11 Apr 2017 12:02:05 +0100
Graeme Geldenhuys via Lazarus  wrote:

>[...]
> I want to change that so the default has difference uses clauses,
> defines the text encoding of the source file etc. Where does the above
> code come from? Hard-coded?

Yes, components/ideintf/projectintf.pas TFileDescPascalUnit
It creates the code from various IDE options and packages can define
their descendants to replace whole or parts. 

> eg:
>   MSEide has a ‘templates’ folder where all such auto-generated code is
>   defined. Nothing is hard-coded in the MSEide executable. From your
>   answer I assume Lazarus doesn’t do anything like this, and instead
>   hard-codes such default unit templates. :-/

It should be easy to add a "user unit" template, that loads the source
from a file and replaces some macros. 

Mattias
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Modifying the "File -> New Unit" template

2017-04-11 Thread Graeme Geldenhuys via Lazarus 
On 2017-04-11 11:46, Mattias Gaertner via Lazarus wrote:
> Right click in the IDE coolbar on the "New unit" button to select
> another template.

I meant I want to modify the code that Lazarus IDE gives once I click
“File -> New Unit”. I don't want a completely different template. eg:
this is the default I see now...


unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils;

implementation

end.
===

I want to change that so the default has difference uses clauses,
defines the text encoding of the source file etc. Where does the above
code come from? Hard-coded?

eg:
  MSEide has a ‘templates’ folder where all such auto-generated code is
  defined. Nothing is hard-coded in the MSEide executable. From your
  answer I assume Lazarus doesn’t do anything like this, and instead
  hard-codes such default unit templates. :-/


> A package can register other templates.

I'll wait on your reply before I delve into this.


Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Modifying the "File -> New Unit" template

2017-04-11 Thread Mattias Gaertner via Lazarus 
On Tue, 11 Apr 2017 11:22:01 +0100
Graeme Geldenhuys via Lazarus  wrote:

> Hi,
> 
> Is there a way to modify the standard “file -> new unit” code template
> that is used? Or is what we see hard-coded into the Lazarus IDE executable?

Right click in the IDE coolbar on the "New unit" button to select
another template.
A package can register other templates.

Mattias

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Modifying the "File -> New Unit" template

2017-04-11 Thread Graeme Geldenhuys via Lazarus 
Hi,

Is there a way to modify the standard “file -> new unit” code template
that is used? Or is what we see hard-coded into the Lazarus IDE executable?

I'm using Lazarus 1.7 r52715 FPC 2.6.4 x86_64-linux-gtk 2

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Startup environment: to Gui, or not to GUI?

2017-04-11 Thread Mark Morgan Lloyd via Lazarus 

On 11/04/17 10:00, Henry Vermaak via Lazarus wrote:

On Tue, Apr 11, 2017 at 09:15:16AM +, Mark Morgan Lloyd via Lazarus wrote:> Apologies 
if this is an FAQ.> > Is there an orthodox way that a Lazarus program can very early on 
look at> how it's been started and decide whether it can usefully fall back to a text> 
mode, e.g. to display help info on stdout rather than a messagebox?
isatty() is traditionally used for this on POSIX operating systems.It's in unit 
termio.


Thanks Henry, I'll check. I know I've used it in the past when deciding 
whether a program was actually being fed piped input etc.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Startup environment: to Gui, or not to GUI?

2017-04-11 Thread Graeme Geldenhuys via Lazarus 
On 2017-04-11 10:15, Mark Morgan Lloyd via Lazarus wrote:
> Is there an orthodox way that a Lazarus program can very early on look 
> at how it's been started and decide whether it can usefully fall back to 
> a text mode, e.g. to display help info on stdout rather than a messagebox?

In the past I've used a start-up script (unix) or a start-up console app
(unix & windows) to detect the environment, then launch the correct
binary executable. At the time I didn't know what this the "correct" way
of doing this, but I looked for things like x11 in the process list, or
looked at the environment variables (eg: DISPLAY). Under Windows I
simply you always know a GUI exists, but you can still test to see if
stdout is available or now (eg: I have windows GUI apps that output help
to a console or ShowMessage() dialog.).

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Startup environment: to Gui, or not to GUI?

2017-04-11 Thread Henry Vermaak via Lazarus 
On Tue, Apr 11, 2017 at 09:15:16AM +, Mark Morgan Lloyd via Lazarus wrote:
> Apologies if this is an FAQ.
> 
> Is there an orthodox way that a Lazarus program can very early on look at
> how it's been started and decide whether it can usefully fall back to a text
> mode, e.g. to display help info on stdout rather than a messagebox?

isatty() is traditionally used for this on POSIX operating systems.
It's in unit termio.

Henry
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Startup environment: to Gui, or not to GUI?

2017-04-11 Thread Mark Morgan Lloyd via Lazarus 

Apologies if this is an FAQ.

Is there an orthodox way that a Lazarus program can very early on look 
at how it's been started and decide whether it can usefully fall back to 
a text mode, e.g. to display help info on stdout rather than a messagebox?


I'm tinkering with something (a media test program for SDCards etc.) 
which I'd like to either run as a conventional console program, or using 
a GUI. I've previously written stuff where operation was entirely 
dependant on command-line options, but haven't tried making the decision 
completely automatically.


Current operating environment is KDE on Debian on an RPi.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus