Hi guys,

Attached I send a project to reproduce the error. To reproduce the error, adds in "cgitest.lpr" the directive:

{$DEFINE SOLVES_ERROR}

On Ubuntu-10.10 I receive this error:

-------
Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, webmaster at localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log. Apache/2.2.16 (Ubuntu) Server at localhost Port 80 -------

In Windows (7) works normally.

How can I fix this?

PS. I'll need to use the unit Interfaces.

*----*
*Lazarus 0.9.29 r28168 FPC 2.5.1 i386-win32-win32/win64* *Lazarus 0.9.29 r27752 FPC 2.4.0 i386-linux-gtk 2 (beta)*

Thanks. ;)

Oops...

2010/11/19 silvioprog

[...]. To reproduce the error, adds in "cgitest.lpr" the directive:

{.$DEFINE SOLVES_ERROR}

Well, you can not use it in a CGI application.
Interfaces is for GUI support. A CGI by definition has no GUI.

It makes no sense to use it. Why would you need that ?

Michael.

Hi Michael, ;)

2010/11/19

Well, you can not use it in a CGI application. Interfaces is for GUI support. A CGI by definition has no GUI.

But in Windows works perfectly, the error is only in Linux (Ubuntu). :(

It makes no sense to use it. Why would you need that ?

Hm..., I need of Interfaces to use my new function (LSStreamToBase64Str [ http://code.google.com/p/lazsolutions/source/browse/trunk/Core/LSUtils.pas#546]). For a better explanation, see the simple project in attached (rename from " LSStreamToBase64Str_CGITeste.zip_" to "LSStreamToBase64Str_CGITeste.zip"). If possible, test the TestWithLRS demo.

Thanks Michael. :T

Michael.

That's just a coincidence. Don't use unit interfaces in non GUI applications.

I've looked at that method. It does not rely on any visual code, so I'd suggest you to move those methods that don't use any GUI related code (e.g. dialogs, etc) to another unit where only units from RTL and FCL are included. This unit can then be used within your CGI application without problems.

Regards,
Sven

I've looked at your unit again:

The only functions that rely on GUI seem to be LSOpenDialog and LSGetWorkAreaRect. You should move those to a LSGUIUtils unit (or however you want to name it) and remove the units Classes, Dialogs, ExtDlgs and Forms from the uses clause of LSUtils.

Another note on one of your functions:
You are aware that LSCurrentUserName will return the user who COMPILED the unit, not the one that is running the application? If you want to get the environment variable at runtime you should use GetEnvironmentVariable (for documentation see here: http://www.freepascal.org/docs-html/rtl/sysutils/getenvironmentvariable.html ). You also don't need to use the "%...%" when using that function.

Regards,
Sven

2010/11/20 Sven Barth

That's just a coincidence. Don't use unit interfaces in non GUI applications.

Hm..., the default code of a new Web Module is (File | New... | Web Module):

-------
program Project1;
{$mode objfpc}{$H+}
uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  *Interfaces*, // this includes the LCL widgetset
  Forms, Unit1;
{$R *.res}
begin
  Application.Initialize;
  Application.CreateForm(TFPWebModule1, FPWebModule1);
  Application.Run;
end.
-------

Then is not possible use the Graphics unit in CGI module? D:

Regards, Sven

And now I know why I don't use the IDE support for my CGI application... In that case maybe Michael should continue the discussion as he's one of the Free Pascal CGI gurus ^^

I'd say it's discouraged. You should use fpImage to do graphics in a non-visual application.

Regards,
Sven

No, you cannot.

A CGI program has no GUI, and the Graphics unit is only useful for GUI.

I suspect the main program file is generated by the lazcgi package. If you are using the lazcgi package, remove it. It is outdated and generates incorrect code. (although I have local fixes lying around that fix precisely your problem)

Use the lazweb package instead. It creates the correct program file and contains much more functionality than lazcgi.

Michael.

That is 100% correct.

Michael.

2010/11/20 Sven Barth

Wow, this is a very good idea. I will create a LSDialogs unit. Thanks for the great idea. :)

Thanks again for your help, I applied the fix in SVN:

http://code.google.com/p/lazsolutions/source/detail?r=171#

I'll try to solve the problem with Interfaces unit... ;)

Regards, Sven

Guys, partially resolved:

(...)
procedure TMainFPWebModule.TFPWebActions0Request(Sender: TObject;
  ARequest: TRequest; AResponse: TResponse; var Handled: Boolean);
var
  VLazarusResourceStream: TLazarusResourceStream;
begin
  VLazarusResourceStream := TLazarusResourceStream.Create('Image', 'PNG');
  try
    AResponse.Content := CustomTemplate(
      'LSCaptcha', '<img src="data:image/png;base64,' +
      LSStreamToBase64Str(TStream(VLazarusResourceStream)) + '">');
  finally
    VLazarusResourceStream.Free;
  end;
end;
(...)

Is there a way to I test if the current project is a CGI module? For example:

-------
unit LSUtils;
{$I lazsolutions.inc}
interface

uses
{$IFDEF MSWINDOWS}
DynLibs, Windows, JwaTlHelp32,
{$ENDIF}
{$IFNDEF CGIAPP} // Or CONSOLE?
Dialogs, ExtDlgs,
{$ENDIF}
LSConsts, LSMessages, SysUtils, Classes, ...
-------

Hi Sven, Michael and all. :)

After update ( http://code.google.com/p/lazsolutions/source/detail?r=172# ) in LazSolutions the CGI test worked perfectly. New simple project to test in attached.

Thanks guys, now my project works perfectly \o/. Thanks again.

For example to use the streaming mechanisms (lfm, resources)?

Compile for the widgetset 'nogui', it's made exactly for this purpose.

Joost.

You can perfectly use them without the interfaces unit. I do it all the time.

Compile for the widgetset 'nogui', it's made exactly for this purpose.

I don't know who ever thought of that widgetset, but I suspect his brain was taking a short holiday at the time. It serves no purpose whatsoever.

Michael.

I've looked into it again, why this was done. And it is for example impossible to use an .lrs file without the lResources unit. Now this is not needed anymore so this might have solved the problem.

Well, without the .lrs files I still have one problem when I omit lResources from the project. I always get an exception 'resource not found' for every datamodule, webmodule or webpage in an application. But thereafter it works. I discovered that this is in debug-mode only. The exception is catched in a try-except block.

Joost.

I know that you need the lresources unit.
What I am saying is that you can just include the lresources unit, there is no need for the interfaces unit.

I do it in all my projects. And they all use the 'old' lazarus resources, they all use the 'lresources' unit, none uses the interfaces unit.

Michael.

Note: The units Forms and Controls require the interfaces unit. The Application.CreateForm is from the unit Forms.

Mattias

Correct. But:
1. Web applications have their own application object.
2. Web applications have no use for CreateForm(). They don't have forms. All modules are created dynamically.

If someone codes forms.application.createform() in a web or even console app, then he is of course coding something totally wrong :-)

Michael.

And how about DATA modules?

Joost

Well, just use

  Procedure TCustomWebApplication.CreateForm(AClass : TComponentClass; out Reference);
Or
   TDataModule.Create(Whatever);

I use them all the time.

In each case, TWebModule is a descendent of TDataModule, so there is no essential difference whatever.

The trick is that the lresources unit sets a hook for InitInheritedComponent in the classes unit in it's initialization routine:

procedure InternalInit;
begin
   LazarusResources := TLResourceList.Create;
   // This is where the magic happens...
   RegisterInitComponentHandler(TComponent, @InitResourceComponent);
   PropertiesToSkip := TPropertiesToSkip.Create;
end;

InitInheritedComponent uses this hook to start the streaming system and InitInheritedComponent is called in TDatamodule.Create()

Application.Createform does nothing special, in essence it does

   Reference:=AClass.Create(Self);

So all that is needed for streaming is to include lresources. No more, no less.

Conclusion: no need for the 'nogui' widgetset to use streaming.

(my personal conclusion: dump the nogui widgetset, it serves no purpose except encourage wrong programming. But that's up to the lazarus devels to decide.)

Michael.

Michael Van Canneyt wrote

?Procedure TCustomWebApplication.CreateForm(AClass : TComponentClass; out Reference);

And in essence, that method should really be renamed, as it can create any TComponent instance - it doesn't really relate to TForm (or any forms) in general. The same goes for LCL's Application.CreateForm() - but the latter will probably stay for that annoying "delphi compatibility" thing. But the TCustomWebApplication is not a Delphi clone (as far as I know), so why stick to the crappy method name? Name is something more appropriate.

(my personal conclusion: dump the nogui widgetset, it serves no purpose except ?encourage wrong programming.

I fully agree. It points developers in the wrong direction.

It is done so because then the Lazarus IDE doesn't have to be told what this method is when auto-creating forms or data modules.

If each TApplication instance used it's own name, then the IDE would need to know what kind of project it is and how the method to auto-create forms is called (and what arguments it accepts) when modifying the project file. That's just cumbersome.

So there is a reason for this besides Delphi compatibility. But of course I think a name like 'TApplication.CreateInstance()' would have been more appropriate.

Michael.

why can't there be console mode text only forms?? there used to be but i don't think we called them "forms" back in the day ;)

Unfortunately interfaces also implements non-GUI stuff like TTimer and inter-Thread messages, that indeed could be useful in (fast) CGI applications.

There _could_ be implementations of "interfaces" (WidgetTypes) that provide this (I did some work on that with limited success some time ago).

AFAIK, the FPGUI WidgetType is on a more promising way to help here, that I was.

Moreover there _could_ be a fast-CGI Widget Type that in fact implements a remote GUI via http (enhancing or similar to ExtPascal), but I suppose a lot of work would be needed to create this even with very limited compatibility with the existing full blown WidgetTypes for Linux, Windows, and Mac.

-Michael

Michael Van Canneyt wrote

I don't know who ever thought of that widgetset, but I suspect his brain was taking a short holiday at the time. It serves no purpose whatsoever.

Unfortunately this is true.

To make it useful for CGI and embedded programs running on small (ARM-Linux) devices without X, I once tried to extend this Widget Type to support things like TTimer and inter Thread Messages, but with very limited success. AFAIK, the FPGUI Widget Tye is on it's way to allow for this in the near future, by simply not using any GUI controls.

-Michael

waldo kitty wrote

why can't there be console mode text only forms?? there used to be but i don't think we called them "forms" back in the day ;)

The FPC distribution contains a nice TUI library.

-Michael

Op 2010-11-21 19:02, Michael Van Canneyt het geskryf:

It is done so because then the Lazarus IDE doesn't have to be told what this method is when auto-creating forms or data modules.

Limitations of one IDE (out of many) should not drive the API of Free Pascal Compiler libraries and classes. That's just bad practice and plain silly. Fix the IDE in question, or use one of many design patterns to solve the problem. Factory Class, Factory Method, Simple Registry etc etc... You're excuse is not a good one Michael. ;-)

Regards,
- Graeme -

ahhhh... that sounds like the trick... but i guess we don't call it a widget set like the others, eh?

Ah, but I'm not giving excuses. I just give the reasons why it is the way it is. Cultural background, so to speak, as in
"Cultural Learnings of Kazakhstan for Make Benefit Glorious Nation of America"

Michael.

waldo kitty wrote

ahhhh... that sounds like the trick... but i guess we don't call it a widget set like the others, eh?

Right, as it's not a part of the LCL and completely of Lazarus.

-Michael

waldo kitty wrote

ahhhHAaaa... that makes sense in a way... why not use it in the LCL or lazarus and make a widget set with it?

That would be great indeed, but Widget Type are complex beasts and unfortunately they do not adhere to a common hierarchical structure but due to their being created one by one "on demand" suffer from their historical heritage, especially as I suppose the Windows Widget set has been created first and same is the most "propriety" interface of all of them.

A complete restructuring of all Widget Types seems to bee too much work and risk to be considered viable.

something that would be like or take the place of the nogui one?

Not really, IMHO, a completely "headless" (no user interface) Widget Set that allows for stuff like TTimer and Inter Process Event Queues is viable, for embedded projects, too.

maybe even call it textGUI or some such?

The technical Term is TUI ("Text User Interface"). You also could use TurboVision, as same is the base of what is provided with FPC

something that offers many of the same features as graphical GUIs but in text mode?? ;)

Fell free to create this Widget Type. (Even though IMHO a restructuring of the Widget Type Interfaces to introduce a decent hierarchy as a container for all of them would be make creating new Widget Types a lot easier) I'd be happy to test it :).

To start, I would take a look at FPGUI, as this Widget Type also does not use external Widgets (like the Windows, KDE, Mac etc. Widget Types) but creates it's own Widgets in Pascal code.

-Michael

P.S.:
A decent hierarchy for Widget Type Interfaces might look like this:

- dummy (no functionality, just making projects compilable (this is what NoGUI does)
- introducing exception handling (AFAIK, this is what the CGI Widget does)
- introducing TTimer and an inter thread events queue (this would best done in FPC, but I fear they will not do so)
- introduce Widget set and a binding to a user interface either of
- create a Text based Widget set and link to input/output stream for text (your idea)
- create a GUI Widget Set and link to "X" (FPGui)
- link to the KDE Widget Set implementation
- link to the QT Widget Set implementation
- link to the OSX Widget Set implementation
- link to the Windows Widget Set implementation
- link to FastCGI (with or without allowing for a HTML widget set such as EXTJS) (just a dream :) )
- link to a remote Widget set connected via a byte stream (such as TCP/IP) and implemented as a Lazarus Program running on a remote PC (just another dream :) )
- ...

have fun :)
-Michael

Michael Schnell wrote

- link to a remote Widget set connected via a byte stream (such as TCP/IP) and implemented as a Lazarus Program running on a remote PC (just another dream :) )

The experimental MSEifi does this for MSEgui.

Martin

Martin Schreiber wrote

The experimental MSEifi does this for MSEgui.

This beasty started my dreaming ..... :-)

-Michael