Eh. This is a FCL bug. The freepascal website has a bugtracker.

Mattias

Title: TProcess: Could not create pipe

Entered by: Tom Lisjac

If poUsePipes is set as an option in TProcess, a \"Could not create pipe\" exception is thrown after several hundred calls. Removing poUsePipes or commenting out the CreateStreams and 3 fileclose statements in TProcess.execute makes the problem go away... along with access to the streams. I\'ve tried but haven\'t had any success fixing this.

The following code will reproduce the problem with a TProcess, button and edit on the form:

procedure TForm1.Button1CLICK(Sender: TObject);
var i:Integer;
begin
  With Process1 do
    Begin
      commandline:=\'ls\';
      options:=[pousepipes,ponoconsole];
      For I:=1 to 50000 do
        Begin
          edit1.text:=inttostr(i);
          active:=true;
          WaitonExit;
        end
    End
end;

Title: TDatamodule OnCreate never fires

Entered by: Tom Lisjac

Title: TDatamodule OnCreate never fires

Oops... bumped return before I finished typing the description.

The OnCreate event doesn't fire no matter what the state of OldCreateOrder. Creating the DM executes the TDataModule.Create constructor but OldCreateOrder test is always false even if set true in the property editor.

Title: .lpi is not a historic file

Entered by: mapelo

freepascal pre1.08
Linux

Description:

1- Create a new proyect (application).
2- Create two units called, for example, unit1 (for form1) and unit2 (no form). 3.- Save de proyect (call it proyect1) and exit.

Now, open Lazarus and Load the proyect1:
1.- Remove from proyect (Proyect->Remove form proyect) the unit2.pas 2.- Close the unit2 from Lazarus Editor
2.- Save the proyect1.

The bug: you can see into proyect1.lpi, because Lazarus do not delete the reference for the unit2. There is no problem, because the proyect run OK, but if you are programing a big application, the .lpi shows all the unit you deleted. The .lpi is a historic file????

El Jueves, 10 de Julio de 2003 13:13, escribi�:

I can add items from a FormCREATE event to the RadioGroup, but it's not possible from a Button1CLICK event, for example. This is a new bug, because I remember that this worked right.

Title: bug in TRadiogroup

Entered by: mapelo

if you create a Radiogroup1 into a form, then
Radiogroup1.Items.Add(\'anything\');

does not work (no error, but no insert item)

Title: DataModule doubleclick

Entered by: Dominik Zablotny

Accidental doubleclick on datamodule view (designer) gives a message
\"TComponentInterface.GetDesigner DataModule1 Owner = nil\" I\'ts annoing because \"cancel\" makes lazarus halt.

Doesn't the fpc allow for different call types?

For example in C programs (at least with Borlands) you can use the pascal modifier and it will make the stack work as in a pascal program. I had thought that was the standard though I may be mistaken.

Because the callee clears the stack. This is unlike C, where the caller knows how much is pushed on the stack, and removes exactly this amount. in FPC, the caller expects a certain amount on the stack, and removes this amount from the stack, irrespective of whether this amount was indeed pushed or not.

Of course not, since the stack is messed up.
The exact error will depend on the particular code.

The way I see it is that during design time, NO callbacks may be set. This also means that you must
- After form load, replace all filled in event handlers with nil, and keep a record of this.
- In the object inspector, show the 'fake' record which you saved.
- When creating new events, put them in fake records.
- Before form saving, fill all callbacks again
- after form saving clear them again.

The best way of doing it IMHO is to make descendents of the TReader/TWriter which do this automatically, and which also keep the list of 'fake' records.

Michael.

You can't.

Before destroying your instances, all methods should simply be set to nil. This is OK as long as it happens after the form file was written.

Michael.

Yes, and therefore we can't set/unset events for reading/writing.

I'm busy at the moment. I will have time for that in a month. I hope lazarus will then also work again with fpc 1.1.

Mattias

>That DM and the empty example I submitted What example?

The steps to recreate the problem that I described in the bug report.

Does this mean, you don't get the AV, when closing a designer form?

Yes, in addition to exiting Lazarus, any attempt to close the datamodule in the IDE also causes the AV.

I worked up the minimal example in the hopes that it would make the AV easy to reproduce. I didn't consider the blank event handlers to be significant because the original problem was seen in a datamodule that didn't have any empty procedures. The unit is tiny... I'll be happy to send it to you if you'd like to take a

Title: lcl units not delphi compatible

Entered by: Peter

There is no GraphType unit in Delphi.
Please move GraphType functions to
Graphics unit. Otherwise, you have to
write:

uses
{$IFDEF FPC}
GraphType,
{$ENDIF}
Graphics;

Then you mean: You don't see a way to do this easily. It will only be impossible, when a processor does not allow to execute code in data mem.

Right. But NO really means NO. If an event is set at any time, it can be called and destroy the stack.

Ok.
There are enough other good reasons to improve TReader/TWriter (better error handling, interactive reading). But Borland wrote TReader/TWriter in a very closed way. Not enough virtual methods and it uses a lot of private variables. Of course we can use the workarounds you mentioned, but it would be much nicer, to open TReader/TWriter for extensions.

Mattias

Title: TButton is declared in StdCtrls not Buttons since Delphi 6

Entered by: Peter

Title: const clCream is missing

Entered by: Peter

clCream = TColor($00F0FBFF);

is new since D7

cryst wrote

Doesn't the fpc allow for different call types?

It does, but methods are done using pascal calling convention. They are handled separately from 'normal' calls.

Michael.

What example?

both run fine... but both cause AV's if they are open in the IDE when shutting Lazarus down.

Does this mean, you don't get the AV, when closing a designer form?

Mattias

Yes, but implementing such things is very bad coding IMHO.

Normally not, as the compiler should do type cheking on assignment statements. It's only because this 'TMethod' record is used that the type checking is lost.

I'm all for that. Feel free to propose/implement improvements.

Michael.

Title: Datamodule generates AV on Lazarus exit

Entered by: Tom Lisjac

When a datamodule is renamed, OldCreateOrder is set and OnCreate and OnDestroy events exist, Lazarus will AV upon exit with 1.0.10. Here are the steps to reproduce:

Bring up Lazarus in a new project.
Add a datamodule with File | New | Datamodule
With Property editor:
Rename the datamodule to dmt
Set OldCreationOrder to True
Create empty OnCreate and OnDestroy event handlers Exiting Lazarus (saving or not) generates an AV

This problem appeared after upgrading to 1.0.10 in a datamodule that had been working fine with 1.0.7.

Title: Foward class reference disables RTTI in property editor

Entered by: Tom Lisjac

Declaring a forward class reference for a component masks access to it in the property editor after it is installed. The component runs fine if manually initialized at runtime but the property editor is completely blank when viewing it in the IDE at design time. An example is attached that reproduces the problem.

A workaround that restores design time access is to remove the forward reference, declare generic pointers and typecast them where needed.

unit fwdtest;
interface
uses
  SysUtils, Classes, Graphics, Controls, Forms, Dialogs;
type
  TMain = class;
  TMainXprops = class(TPersistent)
  private
    fParent:TMain;
    finteger:integer;
    fString: String;
  published
    property Parent :TMain read fParent write fParent;
    property AnInteger:Integer read finteger write finteger;
    property AString:String read fString write fString;
  end;
  TMain = class(TComponent)
  private
    fy:TMainXProps;
  Public
    Constructor Create(AOwner:TComponent); Override;
    Destructor Destroy; Override;
  published
    property testprop:TMainXProps read fy write fy;
  end;
procedure Register;
implementation
procedure Register;
begin
  RegisterComponents(\'Misc\', [TMain]);
end;

{ TMain }

constructor TMain.Create(AOwner: TComponent);
begin
  inherited;
  fy:=TMainXProps.Create;
end;
destructor TMain.Destroy;
begin
  fy.free;
  inherited;
end;
end.

That means, it really creates new classes and procedures are empty and do nothing. The current trick is to copy an empty procedure.

I see what you're saying but I'm wondering if that's the problem we're seeing here. The original datamodule had a TTimer on it and code in both OnCreate and OnDestroy. That DM and the empty example I submitted both run fine... but both cause AV's if they are open in the IDE when shutting Lazarus down.

-Tom

Now, there you found a difficult thing. I always wonder, when it will appear. The IDE creates datamodule/forms descendents on the fly. That means, it really creates new classes and procedures
are empty and do nothing. The current trick is to copy an empty procedure. I was always sure, that this will give us trouble, as soon as the caller checks the stack or uses some special calling convention. Now you find an example:

try
  AnEvent(Self);
except
end;

When the 'except' frees the exception frame, it runs into trouble (internal error).
I have commented the try..except in the LCL, so this error is hidden. One correct solution is to create better "empty procedures". This means an empty procedure, with the right length of parameters. I'm not sure how to do this for all kinds of calling conventions and processors. Another solution is to simulate procedures. That means the procedures are not really set. But this requires changing TReader/TWriter to handle fake events and the RTTI will be incomplete.
I prefer the first solution.

Maybe a fpc guru can give me a hint.

Mattias

Why that?

Why do you think, the problem is only the destructor? Maybe this helps:
When the IDE creates an event (reading a form or user creates a new event) it needs a TMethod record. That means the Self pointer "Data" and the procedure address "Code". Because the FCL and the RTTI uses the Code to identify a procedure, every event needs a unique procedure. The IDE uses a dirty trick and allocates a few bytes and copies the code from an empty method.
Because the empty method has no parameters, it is, strictly speaking, only compatible to events without parameters. In fact it is something like this:

  MyDataModule.AnNotifyEvent:=TNotifyEvent(@MyDataModule.SimpleProc);

A simple

AnNotifyEvent(Self)

works (at least on i386). But a

try
  AnNotifyEvent(Self);
except
end;

does not work.

Mattias

I think both have some logic (TBUtton IMO is a pretty standard control).

In every new version of Delphi, Borland has moved some code from one unit to another. IMO, if we self don't have a reason for it, we shouldn't move. In both cases you are not compatible with a version of Delphi.

If ppl. want to share code between Delphi and Lazarus they have to use IFDEFs. The same way if one wants to share code between D6 and D7

Marc

Not yet.
Any ideas how this should be done and/or what we need for it?

Mattias

Title: Update procedure from TForm is missing

Entered by: tom

{$IFNDEF FPC}
  Form.Update;
{$ENDIF}

Title: There is no Action property in TToolButton

Entered by: tom

{$IFNDEF FPC}
  ToolButton1.Action := actMyAction;
{$ENDIF}
property Action: TBasicAction;

Dnia pon 21. lipca 2003 18:29, napisał:

Title: There is no TPrinterSetupDialog

Really ? ;)

BTW is the unified printing support in future plans for Lazarus?

Title: There is no TPageControl, TTabSheet

Entered by: tom

{$IFNDEF FPC}
PageControl1: TPageControl;
TabSheet1: TTabSheet;
{$ENDIF}

Not yet. Any ideas how this should be done and/or what we need for it?

The best would be like in Delphi.
In Windows the native way of course. In posix we need TCanvas descendant that generate postscript file. There's something simmillar in libgnomeprint
- http://developer.gnome.org/arch/imaging/printing.html, but it seems to be specific to gnome-canvas. The printing system choice is secondary issue. Anyway, it won't be easy.

Title: There is no Tracking property in TScrollbox

Entered by: tom

{$IFNDEF FPC}
  ScrollBox1.HorzScrollBar.Tracking:=true;
{$ENDIF}

Title: There is no TPrinterSetupDialog

Entered by: tom

{$IFNDEF FPC}
    PrinterSetupDialog1: TPrinterSetupDialog;
{$ENDIF}

If I remember correct, Michal Bukovjan splitted it up. This split breaks some circles.
Maybe some of the types can be moved to graphics.pp.

Mattias

Title: TButton is declared in StdCtrls not Buttons since Delphi 6

Why that?
It seems more logical in buttons.pp. What do others think?

Mattias

Title: There is no SizeGrip property in TStatusbar

Entered by: tom

{$IFNDEF FPC}
  StatusBar1.SizeGrip := true;
{$ENDIF}

Title: There is no AutoComplete property in TComboBox

Entered by: tom

{$IFNDEF FPC}
ComboBox1.AutoComplete := false;
{$ENDIF}

Today I will commit a TCustomCanvas abstract implementation in the FCL. The idea (discussed with Matthias Gaertner) is to descend from this various canvases. One descdendent will be the LCL canvas. Another one (which will be committed as well) is a TImageCanvas, which draws on a bitmap in memory (which can subsequently be saved).

A TPostScriptCanvas would then be also one of the descendents. As a TWindowsCanvas etc.

Michael.

> Title: TButton is declared in StdCtrls not Buttons since Delphi 6 Why that? It seems more logical in buttons.pp. What do others think?

It is more logical in buttons but this does come up when converting existing code. To preserve backward compatibility, an ifdef is required... but it's only a minor inconvenience.

-Tom

Title: Deleted menu bug

Entered by: samuel

Lazarus (0.9.0, RedHat 8) crashes with \"Acces violation\" if you open the menu editor for a menu, and delete the menu component, and you then click somewhere in the menu editor window. Everything else in the IDE works fine for me.

Title: Display option doesn\'t work

Entered by: Jesus Reyes A.

The option: Run->Run Parameters...->Local->Display doesn\'t work (lazarus v0.9.0 beta/linux/mandrake 9.0)

Don't think so. But somewhere the DISPLAY variable is lost. Maybe you want to find out yourself:
The environment variables are given to the debugger in debugmanager.pas line 1338:
Project1.RunParameterOptions.AssignEnvironmentTo(FDebugger.Environment); You can add a writeln(FDebugger.Environment.Text); to see the variables. If you follow the AssignEnvironmentTo with "find declaration" you will see, that there is not much code in there. It fetches the current env vars and replaces the overrides.

The debugger creates a TProcess and assigns the variables to it in debugger/cmdlinedebugger.pp line 180.

Just add a few writelns to find out, where the DISPLAY variable is lost.

Mattias

--- Mattias Gaertner escribi�: > On Thu,
31 Jul 2003 13:32:12 -0400

if I do:

$>export DISPLAY=quimica:0.0
$>./test1

I get the output of test1 in quimica, also using gdb, setting set env DISPLAY=quimica:0 works for me. But it seems that, the corresponding checkbox in the dialog box doesn't do anything here. I tried to override the DISPLAY value in run->run parameters..->enviroment->user overrides also without effect.

Jesus Reyes A.

_________________________________________________________ Do You Yahoo!?
La mejor conexi�n a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

It works for me.
Can you give more details?

Mattias

This is the same. The display groupbox is just a shortcut for setting the variable in the user overrides. The IDE sets the environment variables and starts gdb. Maybe your gdb resets the DISPLAY variable. Can you do

$>export DISPLAY=quimica:0.0
$>gdb ./test1
(gdb) run

?

Mattias

--- Mattias Gaertner escribi�: > On Thu,
31 Jul 2003 14:17:12 -0500 (CDT)

It worked fine, I see the output of test1 in quimica, both with gdb and gdb53 (which is what I use in the IDE). could it be that the IDE is reading this from cached values?.

Jesus Reyes A.

_________________________________________________________ Do You Yahoo!?
La mejor conexi�n a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx