Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2013-05

TextHeight in Console App

35 messages · 12 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Edilson Vieira

Hi folks!

This is my second post. If this is not the correct list please let me know.

I am trying to compile a Delphi project with Lazarus.

The project is an Image Generation Program, a console program.

The error ocurr when I call the method TextHeight of the Canvas property of TBitmap.

The error message is (my translation):

'Project TextHeight raised exception "External SIGSEGV" in file '.\include\lclintf.inc' at line 184.'

Could someone help me?

Thanks in advance,

Edilson.

Here is a sample code that reproduces the error:

program TextHeightTest;
{$mode objfpc}{$H+}
uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes, SysUtils, CustApp, Graphics
  { you can add units after this };
type
  { TTextHeight }
  TTextHeight = class(TCustomApplication)
  protected
    procedure DoRun; override;
  public
    constructor Create(TheOwner: TComponent); override;
    destructor Destroy; override;
    procedure WriteHelp; virtual;
  end;

{ TTextHeight }

procedure TTextHeight.DoRun;
var
  ErrorMsg, x: String;
  bmp: TBitmap;
begin
  // quick check parameters
  ErrorMsg:=CheckOptions('h','help');
  if ErrorMsg'' then begin
    ShowException(Exception.Create(ErrorMsg));
    Terminate;
    Exit;
  end;
  // parse parameters
  if HasOption('h','help') then begin
    WriteHelp;
    Terminate;
    Exit;
  end;
  { add your program here }
  // Criando a imagem...
  bmp := TBitmap.Create;
  bmp.Canvas.Font.Name := 'Tahoma';
  bmp.Canvas.Font.Size := 20;
  bmp.Canvas.Font.Color := clBlue;
  bmp.Canvas.Font.Style := [fsBold, fsItalic];
  writeln('Textheight:');
  readln(x);
  writeln(IntToStr(bmp.Canvas.TextHeight('T')));
  readln(x);
  // stop program loop
  Terminate;
end;
constructor TTextHeight.Create(TheOwner: TComponent);
begin
  inherited Create(TheOwner);
  StopOnException:=True;
end;
destructor TTextHeight.Destroy;
begin
  inherited Destroy;
end;
procedure TTextHeight.WriteHelp;
begin
  { add your help code here }
  writeln('Usage: ',ExeName,' -h');
end;
var
  Application: TTextHeight;
begin
  Application:=TTextHeight.Create(nil);
  Application.Title:='Text Height';
  Application.Run;
  Application.Free;
end.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130514/8db6107e/attachment.html>

Reply by email

Edilson Vieira
to leledumbo

2013/5/14 leledumbo

Show quoted text 6 lines
> 'Project TextHeight raised exception "External SIGSEGV" in file '.\include\lclintf.inc' at line 184.' What's there? It's part of lcl, so look for the file in lcl folder.
function RawImage_QueryDescription(AFlags: TRawImageQueryFlags; var ADesc:
TRawImageDescription): Boolean;
begin
  *Result := WidgetSet.RawImage_QueryDescription(AFlags, ADesc);*
end;

The error ocurr at this line ( Result ...).

I have no idea how to solve it.

thx for replying!

Edilson.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130514/e36c5266/attachment.html>

Reply by email

Edilson Vieira
to Edilson Vieira

2013/5/14 Edilson Vieira

Show quoted text 24 lines
2013/5/14 leledumbo > > 'Project TextHeight raised exception "External SIGSEGV" in file > '.\include\lclintf.inc' at line 184.' > > What's there? It's part of lcl, so look for the file in lcl folder. > > function RawImage_QueryDescription(AFlags: TRawImageQueryFlags; var ADesc: TRawImageDescription): Boolean; begin *Result := WidgetSet.RawImage_QueryDescription(AFlags, ADesc);* end; The error ocurr at this line ( Result ...). I have no idea how to solve it. thx for replying! Edilson.

The parameter values are:

AFlags = [RIQFRGB, RIQFMASK]

ADesc =

<TRAWIMAGEDESCRIPTION> = {
FORMAT = RICFNONE,
WIDTH = 0,
HEIGHT = 0,
DEPTH = 0,
BITORDER = RIBOBITSINORDER,
BYTEORDER = RIBOLSBFIRST,
LINEORDER = RILOTOPTOBOTTOM,
LINEEND = RILETIGHT,
BITSPERPIXEL = 0,
REDPREC = 0,
REDSHIFT = 0,
GREENPREC = 0,
GREENSHIFT = 0,
BLUEPREC = 0,
BLUESHIFT = 0,
ALPHAPREC = 0,
ALPHASHIFT = 0,
MASKBITSPERPIXEL = 0,
MASKSHIFT = 0,
MASKLINEEND = RILETIGHT,
MASKBITORDER = RIBOBITSINORDER,
PALETTECOLORCOUNT = 0,
PALETTEBITSPERINDEX = 0,
PALETTESHIFT = 0,
PALETTELINEEND = RILETIGHT,
PALETTEBITORDER = RIBOBITSINORDER,
PALETTEBYTEORDER = RIBOLSBFIRST}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130514/fc4c7d22/attachment.html>

Reply by email

Graeme Geldenhuys
to Edilson Vieira: Hi folks! This is my second post. If this is not the correct list please let me know. I…
Edilson Vieira wrote
The project is an Image Generation Program, a console program. The error ocurr when I call the method TextHeight of the Canvas property of TBitmap.

You do realize that if you pull in the 'Graphics' unit of LCL, you don't have a console app any more, but a GUI app.

I don't really know what you app does, but I would instead use FPImage (from Free Pascal's FCL packages), and use freetype (also included with fcl-image code). This will mean your app is not LCL dependent, and a real console application.

Regards,
- Graeme -

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

Reply by email

Howard Page-Clark
to Graeme Geldenhuys
Graeme Geldenhuys wrote 13 lines
On 2013-05-14 14:07, Edilson Vieira wrote: > The project is an Image Generation Program, a console program. > > The error ocurr when I call the method TextHeight of the Canvas property of > TBitmap. You do realize that if you pull in the 'Graphics' unit of LCL, you don't have a console app any more, but a GUI app. I don't really know what you app does, but I would instead use FPImage (from Free Pascal's FCL packages), and use freetype (also included with fcl-image code). This will mean your app is not LCL dependent, and a real console application.

Or create a Lazarus GUI app and implement Form1's OnCreate handler thus:

procedure TForm1.FormCreate(Sender: TObject);
var bmp: TBitmap;
begin
   bmp := TBitmap.Create;
   try
      bmp.Canvas.Font.Name := 'Tahoma';
      bmp.Canvas.Font.Size := 20;
      bmp.Canvas.Font.Style := [fsBold, fsItalic];
      ShowMessageFmt('Text height is %d',[bmp.Canvas.TextHeight('T')]);
   finally
      bmp.Free;
   end;
end;

For a GUI app Lazarus sets up paths to LCL units such as Graphics (and its dependent units) correctly, and includes several such commonly used units in your uses clause automatically.
Console apps usually require you to manually include the units you use, and specify their paths explicitly.

Reply by email

leledumbo
to Edilson Vieira: 2013/5/14 leledumbo function RawImage_QueryDescription(AFlags: TRawImageQueryFlags; var…

OK, that means it tries to get something from current widgetset, which is nil for a console application. I guess LCLBase is the least thing you can use from LCL for a console app. You could follow Graeme's advice.

View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-TextHeight-in-Console-App-tp4031311p4031319.html Sent from the Free Pascal - Lazarus mailing list .

Reply by email

Edilson Vieira
to Graeme Geldenhuys: You do realize that if you pull in the 'Graphics' unit of LCL, you don't have a console…

2013/5/14 Graeme Geldenhuys

Show quoted text 15 lines
On 2013-05-14 14:07, Edilson Vieira wrote: > The project is an Image Generation Program, a console program. > > The error ocurr when I call the method TextHeight of the Canvas property of > TBitmap. You do realize that if you pull in the 'Graphics' unit of LCL, you don't have a console app any more, but a GUI app. I don't really know what you app does, but I would instead use FPImage (from Free Pascal's FCL packages), and use freetype (also included with fcl-image code). This will mean your app is not LCL dependent, and a real console application.

The original app reads data from a query and generates an image in a tabular format with layout/font/colors configured on the same database. Many images are generated daily so they run as batch processes on a server, that is why it were made as a console app, no need of interaction with users.

So I need to calculate the final size of the image based on such configurations.

You mean use FPImage instead of Graphics?

In this case what should I use instead of TBitmap (defined in Graphics unit) ?

tks for your attention.

Edilson.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130514/9bc23de8/attachment.html>

Reply by email

Graeme Geldenhuys
to Edilson Vieira
Edilson Vieira wrote 5 lines
You mean use FPImage instead of Graphics? In this case what should I use instead of TBitmap (defined in Graphics unit) ?

Yes, take a look at the code in <fpc>/packages/fcl-image/src/ and in more detail the fpimage, fpimgcanv units. You will probably replace TBitmap with TFPImageCanvas.

Also take a look at the <fpc>/packages/fcl-image/examples/ files for example of usage.

You can also use something like AggPas which is much faster than FPImage, and has a lot more graphics capabilities. It is also independent of GUI toolkits, so you can use it in a Console of CGI app for example. The API is a little harder to learn than FPImage though.

Regards,
- Graeme -

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

Reply by email

Edilson Vieira
to Graeme Geldenhuys

Tks Graeme.

However, I did not find TFPImageCanvas. I am using Lazarus 1.0.8 and fpc 2.6.2, a version problem perhaps?

Anyway, I think Howard's sugestion will be a less-effort solution to migrate the existing code.

Thank you guys!

Edilson.

2013/5/14 Graeme Geldenhuys

Show quoted text 22 lines
On 2013-05-14 15:50, Howard Page-Clark wrote: > Or create a Lazarus GUI app and implement Form1's OnCreate handler thus: The original poster wants to create a non-GUI application, so he can't use LCL. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130514/388957d1/attachment.html>

Reply by email

Graeme Geldenhuys
to Edilson Vieira
Edilson Vieira wrote
However, I did not find TFPImageCanvas. I am using Lazarus 1.0.8 and fpc 2.6.2, a version problem perhaps?

It comes standard with FPC since years ago. Simply add the 'fpimgcanv' unit to any uses clause, and it is ready to use. If you want to open the unit then simply Ctrl+Click on the unit name, and Lazarus IDE will open it for you. The statusbar will tell you the exact location of that unit.

Regards,
- Graeme -

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

Reply by email

Edilson Vieira
to Graeme Geldenhuys

Ok.

I think all I need is there with a little different aproach.

I will try some samples before deciding what to do.

Thanks again!

2013/5/14 Graeme Geldenhuys

Show quoted text 23 lines
On 2013-05-14 18:44, Edilson Vieira wrote: > > However, I did not find TFPImageCanvas. This might help too. http://wiki.freepascal.org/fcl-image Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130514/d850932b/attachment-0001.html>

Reply by email

Edilson Vieira
to Michael Schnell

2013/5/15 Michael Schnell

Show quoted text 8 lines
On 05/14/2013 04:50 PM, Howard Page-Clark wrote: > > Or create a Lazarus GUI app and implement Form1's OnCreate handler thus: > > Not all Targets an application might be intended to run on do provide a (supported) GUI API.

In the case I described it should be really a console App because there is no need of user interaction. So if I need to make a GUI App it would be waste of resource on the server.

I really do not understand why I can not make a console App that uses the Graphics unit because in Delphi there is no problem on that.

The use of fpimage and fpcanvas units really solves the problem, although I will have to use FreeType libraries, but it is ok. However, it will imply in considerable changes to the original code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130515/26aff29e/attachment.html>

Reply by email

Flávio Etrusco
to Edilson Vieira
Edilson Vieira wrote 17 lines
2013/5/15 Michael Schnell > > On 05/14/2013 04:50 PM, Howard Page-Clark wrote: >> >> >> Or create a Lazarus GUI app and implement Form1's OnCreate handler thus: >> > Not all Targets an application might be intended to run on do provide a > (supported) GUI API. In the case I described it should be really a console App because there is no need of user interaction. So if I need to make a GUI App it would be waste of resource on the server. I really do not understand why I can not make a console App that uses the Graphics unit because in Delphi there is no problem on that.

The "waste" is probably negligible in most situations, since using CGI is a waste in itself (not to mention running Windows). Using Graphics in Delphi will incur (cause) the same kind of overhead as using LCL/Interfaces in a Lazarus app.
(If you compile a Delphi application with no VCL dependencies you'll notice the big difference in executable size)

(...)

-Fl?vio

Reply by email

Anton Kavalenka
to Edilson Vieira: Hi folks! This is my second post. If this is not the correct list please let me know. I…
Edilson Vieira wrote 24 lines
Hi folks! This is my second post. If this is not the correct list please let me know. I am trying to compile a Delphi project with Lazarus. The project is an Image Generation Program, a console program. The error ocurr when I call the method TextHeight of the Canvas property of TBitmap. The error message is (my translation): 'Project TextHeight raised exception "External SIGSEGV" in file '.\include\lclintf.inc' at line 184.' Could someone help me? Thanks in advance, Edilson.

Al I wrong the NoGUI widgetset is intended for such tasks - CGI-like/console graphics processing?

regards,
Anton

Reply by email

Edilson Vieira
to Flávio Etrusco: On Wed, May 15, 2013 at 11:02 AM, Edilson Vieira The "waste" is probably negligible in…

2013/5/15 Fl?vio Etrusco

Show quoted text 25 lines
On Wed, May 15, 2013 at 11:02 AM, Edilson Vieira wrote: > 2013/5/15 Michael Schnell >> >> On 05/14/2013 04:50 PM, Howard Page-Clark wrote: >>> >>> >>> Or create a Lazarus GUI app and implement Form1's OnCreate handler thus: >>> >> Not all Targets an application might be intended to run on do provide a >> (supported) GUI API. > > > In the case I described it should be really a console App because there is > no need of user interaction. So if I need to make a GUI App it would be > waste of resource on the server. > > I really do not understand why I can not make a console App that uses the > Graphics unit because in Delphi there is no problem on that. The "waste" is probably negligible in most situations, since using CGI is a waste in itself (not to mention running Windows).

"Negligible" in one program execution maybe. But it makes difference when many executions and many programs take place. Beyond that, this is not a good programming practice.
But yes, I am considering this solution (a GUI App). I will have to make some performance tests to see it will be possible.

About running Windows, in this case, it is not my choice.

Using Graphics in Delphi will incur (cause) the same kind of overhead

as using LCL/Interfaces in a Lazarus app.

(If you compile a Delphi application with no VCL dependencies you'll

notice the big difference in executable size)

I really do not know how to do it in Delphi without the Graphics unit. Beyond that the program is up and running.

My point here is to port or not from Delphi do Lazarus. I have other applications to consider also.

Best regards,

Edilson.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130515/a48e3532/attachment.html>

Reply by email

Graeme Geldenhuys
to Edilson Vieira: 2013/5/15 Michael Schnell In the case I described it should be really a console App…
Edilson Vieira wrote
I really do not understand why I can not make a console App that uses the Graphics unit because in Delphi there is no problem on that.

In Windows it is not really noticeable, because ALL Windows installations have access to a GUI. You simply don't get Windows (even a server install) that doesn't have a GUI. For a server, that is really a waste of resources. Linux, FreeBSD etc are quite different, where a server install often [really] has no GUI at all (no X11 is installed).

So for "real" console apps, you don't have access to Clipboard, Graphics etc units - because they all depend on a GUI sub-system being available.

If you are only going to deploy your app on Windows, then you can indeed setup a LCL package dependency to your "console" app, include the Graphics unit and use TBitmap. But remember that your app might not have a user interface, bit in still depends on he GUI sub-system, so is not considered a true console application. Just don't expect that application to run under Linux or FreeBSD servers though.

This is nothing odd or strange, just things Windows developers often don't realize, because they only know one OS. There knowledge of cross-platform development is often lacking.

Regards,
- Graeme -

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

Reply by email

Edilson Vieira
to Graeme Geldenhuys: In Windows it is not really noticeable, because ALL Windows installations have access to…

2013/5/15 Graeme Geldenhuys

Show quoted text 25 lines
On 2013-05-15 15:02, Edilson Vieira wrote: > I really do not understand why I can not make a console App that uses the > Graphics unit because in Delphi there is no problem on that. In Windows it is not really noticeable, because ALL Windows installations have access to a GUI. You simply don't get Windows (even a server install) that doesn't have a GUI. For a server, that is really a waste of resources. Linux, FreeBSD etc are quite different, where a server install often [really] has no GUI at all (no X11 is installed). So for "real" console apps, you don't have access to Clipboard, Graphics etc units - because they all depend on a GUI sub-system being available. If you are only going to deploy your app on Windows, then you can indeed setup a LCL package dependency to your "console" app, include the Graphics unit and use TBitmap. But remember that your app might not have a user interface, bit in still depends on he GUI sub-system, so is not considered a true console application. Just don't expect that application to run under Linux or FreeBSD servers though. This is nothing odd or strange, just things Windows developers often don't realize, because they only know one OS. There knowledge of cross-platform development is often lacking.

You are right. I am looking forward to have such knowledge because I have the goal to make these apps code portable to, at least, Windows, Linux, MacOS and perhaps iOS also. It has been a very hard work and sometimes a think it is not possible at all! But I will keep trying. Lazarus/FPC has been so far the best promise I have at the moment.

Thanks for the info.

Regards,

Edilson.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130515/fa67fa69/attachment.html>

Reply by email

Michael Schnell
to Graeme Geldenhuys: The NoGUI widgetset is a terrible idea (work-around), and should be avoided if possible.…
Graeme Geldenhuys wrote
The NoGUI widgetset is a terrible idea (work-around), and should be avoided if possible.

You are right, but IMHO this is because it is not complete enough. Unfortunately noone knowledgeable enough seems to have the need to do "decent Object Pascal" programs that are supposed to run on boxes that don't provide a GUI API, and thus NoGUI is not yet enhanced to feature an event queue in order to provide "event based programming" and things like TTimer, TTHread.Synchronize, TTHread.Queue and QueueAsyncCall.

Or maybe they use mse for this, which provides all this out of the box. (Which proves that a "decent" NoGUI programming runtime library is possible ;-) )

-Michael

Reply by email

Flávio Etrusco
to Michael Schnell: You are right, but IMHO this is because it is not complete enough. Unfortunately noone…
Michael Schnell wrote 18 lines
On 05/15/2013 05:40 PM, Graeme Geldenhuys wrote: > > The NoGUI widgetset is a terrible idea (work-around), and should be > avoided if possible. You are right, but IMHO this is because it is not complete enough. Unfortunately noone knowledgeable enough seems to have the need to do "decent Object Pascal" programs that are supposed to run on boxes that don't provide a GUI API, and thus NoGUI is not yet enhanced to feature an event queue in order to provide "event based programming" and things like TTimer, TTHread.Synchronize, TTHread.Queue and QueueAsyncCall. Or maybe they use mse for this, which provides all this out of the box. (Which proves that a "decent" NoGUI programming runtime library is possible ;-) ) -Michael

IMHO YHO makes sense ;-)
Is it a design decision that "NoGUI does not do much more than satisfy some open externals when linking a Lazarus based project" or is it just lack of manpower?

-Fl?vio

Reply by email

Hans-Peter Diettrich
to Flávio Etrusco
Is it a design decision that "NoGUI does not do much more than satisfy some open externals when linking a Lazarus based project" or is it just lack of manpower?

AFAIR NoGui was invented for writing (Windows) services, which have to process messages, but do not provide any GUI. Dunno how such server applications work on other platforms.

When FPC provides the required elements (message queues, timers...), I see no need for another implementation in Lazarus, in detail one which implements a message queue different from the FPC implementation. But I may be wrong here, never wrote such applications myself for multiple platforms.

DoDi

Reply by email

Michael Schnell
to Flávio Etrusco: IMHO YHO makes sense ;-) Is it a design decision that "NoGUI does not do much more than…
Fl?vio Etrusco wrote
IMHO YHO makes sense ;-) Is it a design decision that "NoGUI does not do much more than satisfy some open externals when linking a Lazarus based project" or is it just lack of manpower?

In fact I once invested the better part of two weeks in trying to implement an "active NoGUI" WidgetType based on the means the (WidgetType implementations in the) LCL library provide and with a close look to the (working) implementation the mse RTL provides.

I failed, due to the very complex and obviously historically grown design of the LCL and the RTL (here there is no decent common code base for the work-alike stuff that is necessary in the different WidgetTypes and in the RTL (such as message queues) ). I finally decided that the only worthwhile effort would include a redesign of all WidgetType implementations and of the RTL in a way that a central object-based interface for the message queue(s) is provided in the RTL and used by all (existing and future) WidgetType implementations. This of course can't be done by my poor ignorant self, but needs the central "powers" as well in the fpc as in the Lazarus crews.

Thus (as I at that time was just doing a research and was not on the verge of actually doing a project on that behalf) I gave up. And right now the direction of the stuff I intended to design using Lazarus drastically changed and I don't use Lazarus at all (but ANSI C) for "custom" projects any more. I merely can provide some research results and testing programs, if asked for.

-Michael

Reply by email

Michael Schnell
to Hans-Peter Diettrich: AFAIR NoGui was invented for writing (Windows) services, which have to process messages,…
Hans-Peter Diettrich wrote
AFAIR NoGui was invented for writing (Windows) services, which have to process messages, but do not provide any GUI.

Really a bad idea. I would like to use TTimer and TThreads in a service, and of course I would like to do such stuff for multiple platforms. Of course a kind of "remote GUI" would be very helpful for services.

-Michael

Reply by email

Michael Van Canneyt
to Hans-Peter Diettrich: AFAIR NoGui was invented for writing (Windows) services, which have to process messages,…
Hans-Peter Diettrich wrote 9 lines
Fl?vio Etrusco schrieb: > Is it a design decision that "NoGUI does not do much more than satisfy > some open externals when linking a Lazarus based project" or is it > just lack of manpower? AFAIR NoGui was invented for writing (Windows) services, which have to process messages, but do not provide any GUI. Dunno how such server applications work on other platforms.

No. Windows service applications (daemonapp) work without LCL and noGUI.

The reason for noGUI is to allow applications that somehow use one of the basic LCL units (graphics, with TFont and Canvas support) to compile.

Michael.

Reply by email

Vincent Snijders
to Michael Van Canneyt

2013/5/16 Michael Van Canneyt

Show quoted text 5 lines
The reason for noGUI is to allow applications that somehow use one of the basic LCL units (graphics, with TFont and Canvas support) to compile.

In what unit was mrOk defined? That was the identifier needed...

Vincent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130516/9e5e48d0/attachment.html>

Reply by email

Michael Van Canneyt
to Vincent Snijders
Vincent Snijders wrote 9 lines
2013/5/16 Michael Van Canneyt The reason for noGUI is to allow applications that somehow use one of the basic LCL units (graphics, with TFont and Canvas support) to compile. ? In what unit was mrOk defined? That was the identifier needed...

I think that is controls ?

If this is the whole reason for noGUI, then an easier solution would have been to define all modalresults in a separate unit and make an alias in controls.

Michael.

Reply by email

Juha Manninen
to Michael Van Canneyt
Michael Van Canneyt wrote 6 lines
> In what unit was mrOk defined? That was the identifier needed... I think that is controls ? If this is the whole reason for noGUI, then an easier solution would have been to define all modalresults in a separate unit and make an alias in controls.

mrOk is only used by GUI dialogs. By definition it is useful only with GUI.

Juha

Reply by email

Juha Manninen
to Vincent Snijders
Vincent Snijders wrote
> mrOk is only used by GUI dialogs. By definition it is useful only with > GUI. Where is the GUI dialog in for example TFileDescPascalUnit.CheckOwner?

Ok, I didn't notice that one.
Either it should use some other type or then mrOk should be defined elsewhere indeed.

Juha

Reply by email