Unit Dialogs not available in "Program" project ty

[CCRDude]

There are a lot of instances where a pseudo-command line tool is helpful; one that does not have its own main window, but uses functions like InputQuery, ShowMessage, MessageDlg etc. to communicate with the user, thus being a mix of command line with GUI from API calls (at least on Windows).

See the following example:

Code: [Select]

program HelloNamed;

{$IFDEF FPC}{$MODE objfpc}{$H+}{$ENDIF FPC}

uses Classes, Dialogs;

var sName: string;
begin
   sName := 'Unknown';
   InputQuery('Name', 'Please enter your name:', sName);
   ShowMessage('Hello ' + sName);
end.

This compiles quite well on Delphi, since unit Dialogs isn't tied to the TApplication framework there.
On Lazarus, one has to add a dependency to LCL to the project, and when running it, receives the following error messages:

[FORMS.PP] ExceptionOccurred
  Sender=EAccessViolation
  Exception=Access violation
  Stack trace:
  $00429BBC  REQUESTINPUT,  line 433 of ./include/lclintf.inc
  $00420C61  INPUTQUERY,  line 283 of ./include/messagedialogs.inc
  $00420C90  INPUTQUERY,  line 288 of ./include/messagedialogs.inc
  $00401549  main,  line 11 of HelloNamed.lpr
TApplication.HandleException Access violation
  Stack trace:
  $00429BBC  REQUESTINPUT,  line 433 of ./include/lclintf.inc
  $00420C61  INPUTQUERY,  line 283 of ./include/messagedialogs.inc
  $00420C90  INPUTQUERY,  line 288 of ./include/messagedialogs.inc
  $00401549  main,  line 11 of HelloNamed.lpr
[FORMS.PP] ExceptionOccurred

One has to add units Interfaces and Forms to the uses part, and Application.Initialize as the first line.

Quite an unnecessary dependency for Dialogs imho... maybe Dialogs would be better of without the need for Forms and TApplication, as it is in Delphi?

[Vincent Snijders]

No, Delphi can talk directy to the winapi gui layer, Lazarus cannot because it doesn't know what that layer is, it cannot assume that yoiu can call winapi functions to show these dialogs.

So you need to add it explicitly by using the interfaces unit. It might be possible to do this (in the future) without using TApplication.

[CCRDude]

Yes, I assumed that the widgetset question was responsible for this, that's why I tried it this way

What I thought was that adding a dependency on the LCL to the project manager should be sufficient to let it know that it should pick the proper widgetset etc... there's probably some unit initialization in there where the general initialization which is not just required by TApplication, but more global, would fit into better?
Sorry, I know, this is open source, I should take more time to look into the actual code and make a concrete suggestion

Background: I'm writing a learning book for Pascal, and for that prefer FreePascal/Lazarus as example, contrary to Delphi. And describing the necessity to initialize object X that you'll never use again to use Y doesn't really fit the scheme of logic, makes a simple example unnecessarily (imho) complicated and forces me to add lengthy explanations of the differences, that's all

[Marc]

You're running an application, so in fact, you use TApplication :-)

That this works for Delphi is nice, but only as an example. You wouldn't code a real life application this way, would you ?

[CCRDude]

Well, Lazarus seems to know both "programs" "and applications".

For me the difference was that "applications" have message queues, while "programs" are just "linear" code execution. Or say object oriented vs. straightforward code (both descriptions are just rough classifications of course). The first is perfect for GUI, the second perfect for command line.

Actually, there are a few things where such an approach (as from the demo) is useful. Take a look at Microsofts codesign.exe, for example. All it needs is a password input. Implementing all the application surroundings like a message loop is unnecessary there, but the window is an advantage over a command line input since it simplifies copy'n'paste of the password.

Next, I myself have a bunch of small utilities that for example just update a special file with new information, run by the task scheduler. Its straight-forward really, a "program", but in case of a problem, I want to display an error dialog (while the console output would always be piped into a log file, for example). I absolutely don't need a message loop running (or at least initialized) somewhere in the background for such simple tasks (sorry for abstracting TApplication to a mere message loop here ).

So, yes, I have a bunch of real life console "programs" that combine command line with a MessageBox for special situations.

I guess the keyword was that "I don't need the loop" ... while the WinAPI allows these simple dialogs to be "stand-alone", those other widgetsets probably wouldn't? Graphical dialogs on a Linux console program sound a bit... well... different from the Windows approach of course.

[Marc]

IMO console programs should stick to the console, and use no widget input whatsoever. That MS has such apps is IMO bad. Imagine you are on a remote terminal connection (even windows supports this) and you want to run such "console" app

If you want such app, you can always use the Windows unit.

[CCRDude]

Well... but honestly... which person who knows his way around a console would actually use a Microsoft Windows server? For things I really want to run on the console, I use FPC on a RedHat or Debian box, or on my Mac (still need to write a blog article on that... a simple fpc app of not even 200 lines allowed me to recover a deleted file that three expensive recovery tools were not able to recover, I was so glad to have fpc on that machine!).

signcode.exe is actually very useful this way; as I said, logging of results is important sometimes, and this way, I can call signcode.exe from within my applications and redirect the output into my log. I wouldn't be able to do that with a pure GUI application, but I also wouldn't be able to let the user enter the key password in a pure console application (at least I would have to implement a very complicated input redirection which would have to handle any special situation of the app).

What I would agree on is that such applications really should have command line parameters that would allow to bypass the UI interface; in case of the signcode.exe example some parameter to specify the password on the console directly, to avoid the input box if you just have the console as you described. Hmmm. Well, if signcode.exe would have such a clp, it might actually have been much easier, you've got kind of a point there (though then, malware could steal the password since the command line is part of the processs, so a non-clp attempt would still have benefits... even if MS didn't think about this when implementing it this way ).

Regarding the Windows unit... using MessageBox seems to be a good alternative, that's true (if that works on other Linux as well ;p ). Any equivalent for InputQuery in there?

[felipemdc]

if you set apptype to console, write your app as usual (of course you need Interfaces unit), and add some WriteLns on necessary places, you can have a efficient logging method.

In this case it´s not a console app that pops a message box, but rather a gui app that writes debug info to the console. Like most linux apps do.

[Marc]

There is no such messagebox under linux (other than using one in gtk, but then you also need a application loop)
That's also why you need an application for LCL apps

[Cheb]

There *is* a solution for Linux. It is called xmessage. Basically, you start this program that displays the message box for you, then wait it to finish. As a downside, it doesn't support utf-8, so you need to convert, for example, Russian text to one of 8-bit supported code pages.

AFAIK, xmessage is included into any Linux distribution, even into MacOS X.

See an example below.

Code: [Select]


uses ... process
...
   procedure UnixMessageBox(u: WideString);
   var
     MP: TProcess;
     t: text;
   begin
     Try
       AssignFile(t, '/tmp/myMessage-0078.txt');
       Rewrite(t);
       WriteLn(t, WideToCp1251(u)); //here goes the locale hack ...
       CloseFile(t);
       MP:=TProcess.Create(nil);
       MP.CommandLine := 'xmessage -fn ''-*-*-*-*-*--*-*-*-*-*-*-*-cp1251'' -center -buttons Ok -file /tmp/myMessage-0078.txt';
       MP.Options := MP.Options + [poWaitOnExit];
       MP.Execute;
       MP.Free;
     Except
     End;
   end;  

Note that you can add any buttons you want (here it uses only Ok). The button number is returned as process' exit code.

[Marc]

Then you assume your console app is running on an xterm and not on a real console