2011/1/15 Graeme Geldenhuys :

When 0.9.30 fixes branch is updated, please give use some time to re-test those changes before a release is made.

I think the time is now.

For people used to release candidates, consider the current 0.9.29 snapshots to be 0.9.30RC2.

Happy testing.

With kind regards,
Vincent

By 0.9.29 you mean fixes 0.9.30, right?

2011/2/16 Vincent Snijders

2011/2/16 Alexsander Rosa :

By 0.9.29 you mean fixes 0.9.30, right?

By 0.9.29 I mean a Lazarus 0.9.29 snapshot or update from the Lazarus Ubuntu testing repository. You can find the source of that snapshot in svn at http://svn.freepascal.org/svn/lazarus/branches/fixes_0_9_30/

Vincent

I just retrieved fixes_0_9_30 and got revision 29578. Is this the one to test?

Bo Berglund

2011/2/17 Bo Berglund :

> I just retrieved fixes_0_9_30 and got revision 29578. Is this the one to test?

Yes (or higher). The last change has been made in 29565: http://svn.freepascal.org/svn/logs/lazarus-fixes_0_9_30.log

Vincent

Op 2011-02-16 22:01, Vincent Snijders het geskryf:

I think the time is now.

Thanks Vincent, get another update now.

Regards,
- Graeme -

compilable and runnable on Windows 98SE.

Regards, Bernd.

Il 17/02/2011 10:52, Bernd Mueller ha scritto:

Work on Windows XP Professional service pack 2 and 3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sw_dept.vcf
Type: text/x-vcard
Size: 257 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110217/1cc744d6/attachment.vcf>

Some testing results regarding MainThreadEvents.

Done with Lazarus version 0.9.31 revision 29587, fpGUI revision as of 20110217, and FPC 2.5.1:

GTK2 GTK fpGUI
======= ======= =======
TThread.WaitFor OK OK OK

From a Thread
TThread.Synchronize (1) OK OK TThread.Queue ---------------------not implemented-----------
PostMessage OK (3) no function
PostThreadMessage ---------------------not implemented-----------
SendMessage (2) (4) no function
Dispatch (2) (4) (5) QueueAsyncCall (1) (3) (6)

From a Timer
TThread.Synchronize ---------------------impossible---------------- TThread.Queue ---------------------not implemented-----------
PostMessage OK OK no function
PostThreadMessage ---------------------not implemented-----------
SendMessage OK OK no function
Dispatch OK OK OK QueueAsyncCall OK OK (7)

(1) The scheduled Events only are handled in the Main Thread when GUI Events for the Form are handled (e.g. always, when a memo that gets the test output has the focus, which makes it seem to work correctly)

(2) Forbidden, but eventually works like TThread.Synchronize

(3) Similar to (1), but does not even seem to work if the memo has the focus

(4) Forbidden; Application Crashes

(5) Forbidden; works for some time, then The application closes without error message

(6) The scheduled Events only are handled in the Main Thread when the worker thread is terminated

(7) Very funny: In this test environment, the scheduled Events only are handled in the Main Thread when e.g a completely unrelated worker thread is created and then terminated

Hope this helps,

-Michael

2011/2/17 Michael Schnell :

Let me help you focusing your testing, so that it gives useful information about the quality of the 0.9.30 release compared to the last release 0.9.28.2.

* Use 0.9.29.
* Use fpc 2.4.2
* Use the default widget set, or alternatively the qt widgetset on linux.

If you find problems, try to find out if those problems occurred with lazarus 0.9.28.2 / fpc 2.2.4 too.
Then try to find out if they happen with lazarus 0.9.31 / fpc 2.4.2 too.

Thanks,
Vincent

Vincent Snijders wrote

* Use 0.9.29. * Use fpc 2.4.2

This happens with all recent versions I tested. It's very unlikely that it depends on the fpc version (unless fpc would finally implement TThread.Queue)

* Use the default widget set, or alternatively the qt widgetset on linux.

gtk2 is the default widget set, so I of course did that in the first place (see list). The other result can be used as a reference.

If gtk1 is not supported any more, of course the results for same can be ignored.

fpGUI is under development, so the results might be of interest for the fpGUI developers

I did not get anything compiled with qt ("cannot find -lQt4Pas")

I did not test with Windows.

I don't have a MAC (yet).

I don't have any ARM hardware (yet).

I'm not interested in WinCE.

I just used the most recent version I could get

If you find problems, try to find out if those problems occurred with lazarus 0.9.28.2 / fpc 2.2.4 too. Then try to find out if they happen with lazarus 0.9.31 / fpc 2.4.2 too.

I have no idea how I should do this, But I'd be happy to provide the testing project to anybody who wants to do the tests. It's just a simple testing project with no overhead.

-Michael

I'm using 9.30 for weeks on Linux (Ubuntu 10.10) 32 and 64 bits. It's working fine with my ERP, whose Lazarus version is being developed. The whole project (including D7/C++/SQL) has 286 KLOC (according StatSVN). Lazarus/D7 share a 90 KLOC persistence framework (with only a couple $IFDEF's).
The Lazarus tree (version 3) has 22 KLOC already.

2011/2/16 Vincent Snijders

2011/2/17 Michael Schnell :

Then I assume it won't work with older versions either and it is not relevant with the respect to testing 0.9.29 for the upcoming 0.9.30 release.

Vincent

Vincent Snijders wrote

Then I assume it won't work with older versions either

Supposedly you are right

and it is not relevant with the respect to testing 0.9.29 for the upcoming 0.9.30 release.

There are some bug reports in the fpc bug tracker. I This is why I did the testing project that makes it easy to verify (and maybe fix) this kind of bugs.

I recently updated issue 0013120 with the results of the program but that was with Lararus revision 29134 and lacking the results for gtk1.

If bugfixes are not intended for the new release, you of course can ignore this.

Maybe I should update the issue again.

-Michael

2011/2/17 Michael Schnell :

Bug fixes are for a new release, but not in the very last moments.

But in this case, there is not fix yet, is there?

Vincent

Vincent Snijders wrote

But in this case, there is not fix yet,

You are right, of course.

-Michael

Great work Vincent! I just added repo to my xubuntu installion and it is working very well. My project with over 80k lines of code and 67 forms compiled without problem and program is running as expected. Thank you for great work. I thing this release will be the best ever.

Petr

Dne 16.2.2011 21:01, Vincent Snijders napsal(a):

Now tested and found a minor bug in TLabel:
1. Put label on form
2. Set Alignment=taRightJustify and Autosize=true
3. Enter text and observe that the label is still anchored on its *left* hand side (expands to the right).

In Delphi labels that have taRightJustify will automatically expand/contract on the left side so the right edge is fixed. Very handy if the label is a descriptor for another visual control and can hold varying sized text (different languages for example).

I don't have a previous Lazarus version handy so I can't say if this is old...

What is the state of Anchors?
If it is set to akLeft, then the behavior is correct.

In Delphi labels that have taRightJustify will automatically expand/contract on the left side so the right edge is fixed.

Does the VCL automatically change the Anchors?

Mattias

The properties "Align" and "Alignment" serve different purposes.

In Delphi labels that have taRightJustify will automatically expand/contract on the left side so the right edge is fixed.

This IMO can be achived by Align=alRight. Automatic dependencies between Align and Alignment may cause other trouble, so that I'd leave it to the human designer to set both independently. (numbers, RTL/LTR reading...)

Lazarus offers more sophisticated anchoring than Delphi does.

Very handy if the label is a descriptor for another visual control and can hold varying sized text (different languages for example).

There exist more issues, e.g. right aligned text may be truncated at the right, when the Width is too small. This may be proprietary to Windows widgets (listview...), though.

DoDi

tested with turbo delphi.

No the anchor is not changed.
but the behaviour is consistent.

The Anchors are not used if size changes from autosize

A taLeftJustify in Turbo delphi always expands to the right, if caption changes (never mind akLeft, or akRigh_
A taRightJustify always expands to the left, if caption is changed

akLteft/akRight affect the labels movement if the parent container resizes.

-----
It doesn't seem a regression though, Lazarus 0.9.28 doesn't do the Delphi way neither

If the VCL AutoSize ignores parts of the other layout settings then for me this sounds "inconsistent".

What happens when you set Anchors to [akRight,akTop] in VCL?

Cross platform forms require a consistent layout engine.

Mattias

Well depends on consistent with what...

Delphi only looks at the anchors, if the parent changes. Delphi doesn't have anchorsides.

taLeftJustify => the left side of the label follows the anchor taLeftJustify, akLeft, => the "labels left" stays at a fixed distance to the "parents left"
taLeftJustify, akRight => the "labels left " stays at a fixed distance to the "parents Right"

taRightJustify => the right side of the label follows the anchor taRightJustify, akLeft, => the "labels Right" stays at a fixed distance to the "parents left"
taRightJustify, akRight => the "labels Right" stays at a fixed distance to the "parents Right"

Anyway, I only answered the question that was previously asked: WDD?

Of course with anchorsides (and explicit anchoring to other controls). this is different ......

In Delphi7 it works as follows on a fresh project form: Drop a TLabel and its default properties are
Autosize=true
Anchors= [akLeft, akTop]
Alignment=taLeftJustify

Write text into its Caption property and the left side is stationary, expansion is on the right.

Now change Alignment to taRightJustify
Write text and the right side stays stationary and expansion is to the left.

The other properties do not change.

Change Autosize to false and now the text aligns to the right but the label size does not change so if the text is too long the right hand end stays visible and the left end is pushed into invisibility.

Change autosize back to true and the label expands to the left to show the hidden text.

Although this is not an issue in the present snapshot of Lazarus, which I beleieved, it is nevertheless an annoying non-feature because I use labels a lot to the left of edit boxes to state their names and I want the name to end just in front of the editbox. In Delphi I just have to set the Alignment and it is ready.

In Lazarus this does not work unless I do some additional changes: akRight = true
akLeft=false (because it does not sense the change in akRight)

Only now does the label behave as wanted.

Hans-Peter Diettrich wrote

There exist more issues, e.g. right aligned text may be truncated at the right, when the Width is too small. This may be proprietary to Windows widgets (listview...), though.

In Delphi7 the right end of the taRightAligned text *always* stays visible, the left end is truncated (if the Autosize property is false).

IMO LCL AutoSize tries to be too clever. In fact an "inner" resize, required to e.g. adjust the required width of an label, should be separated from an "outer" resize/realign, forced by a resize of the container.

Extensions like AnchorSides and ChildSizing may look nice, but should be added only when really needed. Otherwise they can adversely affect requirements of specialized controls or containers. When a (text) Alignment has to be taken into account, this cannot be implemented in a common (TWinControl) class, because not all controls have such a property, in fact every control class can have its own properties that should steer their size and placement. When such an DoAutoSize method is virtual, every overridden implementation can add whatever additional layout information is required.

In the most useful model every control would have its own (configurable) layout manager, selectable from an (extensible) number of predefined layouts. In fact the DockManager already *is* such an *installable* layout manager...

I wonder how one can implement installable DockManagers, and at the same time insists in non-installable layout managers :-(

Cross platform forms require a consistent layout engine.

The form layout is always under control of the application, not affected by the you mean an consistent adjustment, required for changed language or theme, then I agree. But multiple themes are not a matter of platforms, and have to be handled by Delphi for Windows as well.

DoDi

Did you verify this behaviour, with all ComCtrls?

DoDi

That would contradict the rule that AutoSize:=true adapts to the
bounding box of the children.

DoAutoSize is virtual.

In the most useful model every control would have its own (configurable) layout manager, selectable from an (extensible) number of predefined layouts. In fact the DockManager already *is* such an *installable* layout manager...

A TDockmanager is somewhat more.
But I think a TLCLLayoutManager could be done similar to this. Maybe TDockManager should be made a descendant of a TLCLLayoutManager.

I hope so.

Mattias

I don't understand the question. I was talking about the TLabel only.

But to complete this => the labels "Left" property changes to reflect the new position

Testing with Delphi7:
Yes the Left property changes when the text is changed.

Not really. Every container can act as a DockSite, this is not a privilege or special feature of an DockManager. All methods involved in the *act* of docking can reside in the TDragDockObjects, as implemented in Delphi, instead of the currently used DragPerformers. Also the distinction between Controls[] and DockClients[] is nonsense, because only one of these collections can contain elements, at the same time (both properties could be rebased onto the same field).

But I think a TLCLLayoutManager could be done similar to this. Maybe TDockManager should be made a descendant of a TLCLLayoutManager.

Right. I already tried such an approach, and failed due to the existing dependencies between a general layout manager and the already introduced AnchorSides, ChildSizing etc. fields - these and all related methods should be moved into specialized layout managers.

A control only needs a reference to its layout manager, and eventually another (untyped) reference to layout data, created and used exclusively by that layout manager. Such a design would e.g. allow to transform the currently distributed AnchorSides into kind of that tree, that currently has to be built from scratch, whenever a site with (such) anchors is updated (during autosizing...).

DoDi