Title: View forms of a closed unit file doesn\'t work

Entered by: Tony Maro

When you attempt to select a form to view and the particular unit associated with the form is not open, the form (and unit) fails to appear. You must select View Unit and choose the unit, and the form will appear.

Title: OI created events sometimes end up on wrong form

Entered by: Tony Maro

This may be related to the \"unpublished\" event issue I listed earlier, because I just noticed that\'s when it happens as well...

When using the OI to create (or sometimes just click the button to edit) a new event for an object, sometimes it will create the event both in the proper unit AND in another unit.

I\'ve seen this happen several times, but like some other things I can\'t guess as to when or why it will happen.

For instance: I just noticed my FrmEnterWithdrawal and my FrmEnterDep did the following:

{ in FrmEnterWIthdrawal\'s unit: }
procedure TFrmEnterWithdrawal.FrmEnterWithdrawalCREATE(Sender: TObject);
{ in FrmEnterDep\'s unit: }
procedure TFrmEnterDep.FrmEnterWithdrawalCREATE(Sender: TObject);

It even creates the reference in the forms type definition to match the mismatched routine.

I noticed it this time because after it happened, the TFrmEnterWithdrawal.OnCreate event existed, but the OI showed \"UNPUBLISHED\" instead of the routine name.

I hope this helps...

Title: Removing autocreate forms doesn\'t work right

Entered by: Tony Maro

When telling a project to not autocreate forms I found the following:

Project has several forms
Remove all but first and last from autocreate list using project options Click OK

Result = last form in list is duplicated in the lpr project.

Then, I removed the duplicate line from the lpr file.

Reopened the project options, tried to move forms BACK to be created and Lazarus died with:

Access violation
TCONTROLSELECTION__GETITEMS line 1190

Fixed.

Design forms now set csDesigning before creation. I hope all creation code reacts correct.

Mattias

Title: UNPUBLISHED event associations

Entered by: Tony Maro

Occasionally, editing events on one form will cause the last focused control on another form to lose the association with an event. When this happens on a button\'s ONCLICK event for instance, the button will no longer work, no errors are generated, but the property editor shows \"UNPUBLISHED\" for the designated function that is called when the ONCLICK event is fired. This has happened to me on multiple occasions and I\'m positive it\'s not a slip of the mouse or keyboard on my part.

fixed

Mattias

Title: Changing name of new form corrupts things

Entered by: Tony Maro

Sometimes - about 40% of the time - when I create a new form, then go to the property editor and change the name to something else, it results in something like this:

Chose FILE + NEW FORM

Went to property editor and changed name to \"FrmEnterWithdrawal\".

The property editor shows things correctly, but here\'s what the form\'s unit shows:

type
  TFrmEnterWithdrawalTFrmEnterWithdrawal = class(TForm)
  private
    { private declarations }
  public
    { public declarations }
  end;
var
  FrmEnterWithdrawalFrmEnterWithdrawal: TFrmEnterWithdrawalTFrmEnterWithdrawal;

(No I didn\'t stutter)
Sometimes it will do this 8 times in a row. Other times I can\'t reproduce it.

The edit components on the OI are now refreshed if other IDE parts are changing properties.

Mattias

Title: Moving controls with focused TOP property

Entered by: Tony Maro

If you drop a text box on a form, then select the \"TOP\" property in the property editor it doesn\'t matter where you move the control, as soon as the control in the form looses focus, it snaps back to the last position.

Suggested fix: Perhaps have property editor detect when the form designer is selected again and have it lose focus on the currently edited property at that time.

Title: Editor Options - Display tab shows \"COMBOBOX\" as value

Entered by: Tony Maro

The editor options \"Display\" tab has two combobox \"gutter width\" and \"right margin\" that default to \"combobox\" in the text if never set.

Title: Border style affects form while in design mode

Entered by: Tony Maro

When in design mode, forms should not try to display the dialog border mode (when it does I can\'t move it), nor should they prevent resizing if the border mode prevents it. Checks should be put in place to determine if the form is in design mode and always show it as bsSingle if so.

Title: Tab Page visible property not working

Entered by: Tony Maro

May be related to the now fixed scrambled menus bug when items are created in ONCREATE rather than ONSHOW .  When other components are created in the ONCREATE method (not the tab or page controls), my tab page refuses to go invisible, when defined as visible:=false at both design time  that moving creation of controls to ONSHOW fixes the problem.

Fixed.

Mattias

Title: Find window hangs Lazarus

Entered by: Tony Maro

This has been happening only since the modal dialogs were being played with... I think.

I constantly use CTRL-F to pop up the find window and start typing without looking at the screen. Often the FIND window will appear behind the other lazarus windows, but worse is the 1 in 10 or so chance that it never appears. Since it\'s modal (I assume) none of the other Lazarus windows will accept input, so I can\'t save and close when this happens. My only option is to kill the lazarus process. I\'m not sure if the entire application is actually hung, or if it thinks the FIND dialog is waiting for input. Lazarus windows do still repaint themselves. Find shows in the list of available windows in my window manager, but it\'s not visible on the screen. Moving the other lazarus windows proves that it\'s not just hiding behind them.

Fixed.

Have to check this...

Mattias

I was not yet able to reproduce it, but I added some more checks and output. When it happens next time, plz send me the terminal output.

Mattias

Title: poOwnerFormCenter results in form shown in designed location

Entered by: Tony Maro

poOwnerFormCenter always results (GTK) in the form showing in the designed location. poMainFormCenter does function correctly.

May be related. Can I mark this one too?

Mattias

Can I mark this as fixed?

Mattias

Mattias Gaertner wrote

> Title: Changing name of new form corrupts things Can I mark this as fixed?

Well, did you ever fix it? ;-) Actually, I haven't been able to reproduce this in a while, but I haven't added many forms either...

I'd say yes.

-Tony

Yes. It hasn't happened again since your patch. Thanks!

-Tony

The TNoteBook page selecting is the only hack in the gtk interface. There should be some funcitons to do this in general in the LCL/designer. But since it is the only component till now, I'm not sure how these functions should look like.

Mattias

Well, you never specified how to reproduce it, so I can't tell if my changes fix it. You reported several bugs of this type (all related to multi form editing). So I added some more checks and asked you to tell me when it happen again. This was nearly two weeks ago, so I hope they are fixed.

Actually, I haven't been able to reproduce this in a while, but I haven't added many forms either... I'd say yes.

:)

Mattias

Can I mark this as fixed?

Mattias

Title: Setting top tab in designer doesn\'t recognize change

Entered by: Tony Maro

With TNotebook, if you pick a different tab in the designer and then save and/or make the app without other changes, it will not register that you have changed which tab is on top.

If you however make that change, then move around another control on the form or something, it will recognize the change and store it. It\'s as if changing the active tab doesn\'t trigger lazarus to realize that the form resource must be updated.

I may have answered this earlier while in Winblows (I get so confused on little sleep,) but yes this one seems to have stopped and so has the "Unpublished" - and I probably would have noticed if this continued considering the volume of development I've been doing.

Thanks,
Tony

No, you are correct. I wasn't Paying Attention or I would have realized this. These Routines should all Initialize the Result to SIMPLEREGION. They were right to begin with, so I assume I screwed them up somewhere along the lines. Probably before I even comitted them.. The fact that the result was uninitialized is the only reason it worked! Ah well I believe it is fixed now. But you should probably test it out for yourself, just in case.

Andrew

Title: Unitialised variables and memory leak

Entered by: Jeroen van Iddekinge

1) In TGtkObject.InitStockItems the function CreateBrushIndirect is called. logbrush.lbStyle is set to bs_null , but logbrush.lbColor is not set and is therefor unitialised. lbColor should be set because it is used in CreateBrushIndirect in a call to GetGDIolorRef

2) TGtkObject.FillScreenFont, memory leak
XFreeFontNames(theFonts) should be added.

3) TGtkObject.SelectClipRgn.
The first lines of this routine is:

if not isValidDc(DC) then
  Result := Error;
if Result  Error then

This should be something like:

Error := 0
if not IsValidDc(DC) then
    Result := Error;
if Result  Error then

I think Jeroen ment Result=0 instead of Error=0.

Result is uninitialized.

Marc

whoops. looks like you may be right. So..

Fixed.

Andrew

_________________________________________________________________ Unlimited Internet access for only $21.95/month.� Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp

Fixed.

Mattias

Fixed.

Mattias

Sorry if this message is repeated.
...

I think this would be a problem anyway because Error was declared as Error = 0; in lcltype.pp
so Result:=0 is the same as Result:=Error. DC is always treated as Invalid and Result Error is false.

This happen to be a problem in some other routines.... ExtSelectClipRGN, ExcludeClipRect, getClipBox, getClipRGN, SelectClipRGN, IntersectClipRect. At least I can confirm this with getClipBox
But I could be wrong....

Regards.

Jesus Reyes A.

_________________________________________________________ Do You Yahoo!?
La emoci�n e intensidad del deporte en Yahoo! Deportes. http://deportes.yahoo.com.mx

I believe that all three points have been Fixed. If there still appears to a problem let me know, otherwise can/should this bug be marked fixed?

Andrew

On Mon, 2002-10-28 at 15:39
Jeroen van Iddekinge wrote:

Title: Unitialised variables and memory leak

Title: Changing column width in ObjectInspector is not possible

Entered by: Martin Smat

Ii is not possible to change the column width in ObjectInspector when some property value is active. Tray this:
1. Run Lazarus
2. Select a property value in ObjectInspector (the background changes from gray to white)
3. Now try to change the column width with the line between property names and their values.

CreateBrushIndirect should not be calling to get the color for a null brush. This is known, and I have a minor fix I will be commiting soon to redesign Brush's to act like Pens, aka If IsNullBrush then ... else ...

2) TGtkObject.FillScreenFont, memory leak XFreeFontNames(theFonts) should be added.

Fixed.

This is not a bug, ERROR is a Win32 defined const, which is declared elsewhere.

Andrew