How can anybody use Lazarus Trunk for anything!!!

I'm trying to create a test project for another bug I reported. But using Lazarus Trunk, I can't resize a TButton in the Form Desginer. Lazarus IDE is compiled with LCL-GTK2.

Yes, I'll report this in Mantis too, I just wanted to vent some frustration. The Lazarus project REALLY needs some sort of "quality control" or regression testing!

Graeme Geldenhuys wrote

I'm trying to create a test project for another bug I reported. But using Lazarus Trunk, I can't resize a TButton in the Form Desginer. Lazarus IDE is compiled with LCL-GTK2.

Reported in Mantis as:

http://bugs.freepascal.org/view.php?id=20189

Basically I can make the Button width smaller, but I can't enlarge the button width using the resize handles in the Form Designer.

I guess, this may still have slipped through.
I tried and I was able to reproduce it once. But even after restarting the IDE I can't reproduce it any more.

Mattias

I can resize it with the corner resizers. Never with the side resizers.

But that has been so since ages.

Michael.

In big corportations they have people which only test software quality all day (I'm one of those), so it is pretty easy to find all revisions which broke things, even when the reproduction is as low as 10%, because you are working all day on that, and a large project may have even 10 QA Engineers ...

In Lazarus we have zero Quality Assurance Engineers, so in reality everyone using trunk is a Lazarus QA ;)

Having said that, in the last few weeks I have experienced some random issues using Lazarus trunk:

* Random(?) Access Violations - Got in both Gtk2 and Carbon
* Jumps sometimes for no reason to another code editor tab - Got in both Gtk2 and Carbon

All issues happen only sometimes, maybe a memory corruption?

Randomly I get Graeme's issue, but I think that it has been like that for quite a while and it is Gtk2 specific.

I can resize it with the corner resizers. Never with the side resizers.

I just tested here and it doesn't seam to be like that. Sometimes only the corners works, sometimes everything works, something only the sides works.

It also isn't related to new components dropped.

I hear this the first time.
Can you try the outer edge of the side resizers?
Probably it is important where you start grabbing.

Mattias

Mattias Gaertner wrote

I hear this the first time. Can you try the outer edge of the side resizers? Probably it is important where you start grabbing.

I can reproduce with rev32010 so the issue is not new.

And you just scored a Bingo. I just tested, if you put the mouse in the middle of the button, then move it to one of the grabbers, it will refuse to resize.

If you approach the grabber from outside the control, it works!

You are right. It seems so.
If I start spot in the middle of the resizers, it fails. If grab the edge of the resizer it works.

Judging by your remark you know what causes it. That's half the solution :-)

Michael.

Confirmed after some more tests, but it depends: if I move far enough to the outer edge of the resizer, it will resize. Looks like with the mouse inside or on the button boundsrect, the resize doesn't register. Only when crossing the boundsrect, it has effect.

Michael.

Well, I know that the only difference between a side and a corner grabber is the amount of space outside the selected control. The grabbers are no widgets, they are just painted. The same is enlarging and shrinking: shrinking moves the mouse over the selected control. So, it probably has to do with the mouse grabbing under gtk2 at design time. When starting the drag on a button sometimes the mouse move events only work inside the button or at design time all mouse events are delegated to the designer I guess it is a bug in the gtk2 interface.
But even with this knowledge I can hardly reproduce it here. So as Felipe wrote: It will be hard to find the revision that broke it.

It would be nice if users who can reproduce it more often can help us here and find the revision.

I hope Michael is wrong and the bug was not always there.

Mattias

Mattias Gaertner wrote

Can you try the outer edge of the side resizers? Probably it is important where you start grabbing.

That requires fine mouse skills (smile), but I think you are on to something. If I carefully position the mouse on the outer edges of the resize handles, then I can indeed resize the component. Placing the mouse pointer in the center or inner half of the resize handles, then I can't resize the component.

I found the revision, see the bug item.

I hope Michael is wrong and the bug was not always there.

It has existed for 5 months

Felipe Monteiro de Carvalho wrote

It has existed for 5 months

:-) I guess nobody uses LCL-GTK2 then?

Interesting thread [?]

I use GTK2 but not from SVN. Too many changes made me stick with 0.9.30 for now.

2011/9/8 Frank Church

Or perhaps no-one resizes buttons? I use it daily and haven't noticed...

Henry

Fixed. Please test with r 32231.

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110908/2dea35fb/attachment-0001.html>

Alexsander Rosa wrote

I use GTK2 but not from SVN. Too many changes made me stick with 0.9.30 for now.

+1

I've tried Lazarus Trunk today (I do this once in a while). Just in a few minutes I discovered quite a few bugs. I persisted for the remained of the day, but now I gave up. Just to much is broken. Back to 0.9.30.1 I go.

Henry Vermaak wrote

Or perhaps no-one resizes buttons? I use it daily and haven't noticed...

In that case you clearly having been resizing ANY components for the last 5 months. :-) The bug was not just with TButton, but resizing components in general. I initially noticed it on TButton, so reported it as such.

Strange, I can resize listboxes and panels without any problems here. Buttons do have the same problem for me, though.

Henry

Henry Vermaak wrote

Strange, I can resize listboxes and panels without any problems here. Buttons do have the same problem for me, though.

I the same problem [as with TButton] with a TDateEdit component.

Well. I use trunk on GTK2 daily.

I found 1 bug some time ago, and it was fixed after 1 or 2 hours.

For me, there is only 1 really annoying bug, and that is that the Z-Order is totally messed up whenever a new window is shown or I switch from another App to Lazarus (issue 18823).

Other than that, I think trunk Lazarus works and progresses just fine.

Michael.

Well I do and I noticed, but since my machine is very slow, I just thought it was a combination of me handling the mouse and my system being slow, so that I would grab on the wrong place as a result.

Bart

<michael.vancan wrote

Well. I use trunk on GTK2 daily.

Consider yourself lucky. ;-)

Granted, many of the bugs are LCL or Form Designer related. Both things I don't use.

But a big show-stopper for me now is the new debugging hints slowness. I tried to disable all the new "auto cast" features that Martin recently added. To no avail, they seem to stay active no matter what, and due to that, debugging hints over objects now take around 5-10 seconds to display. We still have no clue as to what is causing this slowdown. Also, it displays such a lot of information in the hint window now, the hint window is to big to fit my screen. And any "usable" information is now obfuscated by the volumes of data output.

What exactly do you mean "stay active" ?

If I uncheck "automatic type-cast for objects", then I definetely get the old hint (no type cast). I also watched the gdb commands => none of the typecast related commands were sent.

- Are the commands still send, if you disable the option?
- Is just the slowness remaining ?

If it is just the slowness, then the issue certainly lies elsewhere.

Also from your other mails:

Graeme Geldenhuys wrote

I see the following line appear instantly when I hover the mouse over Sender in the code... Then the delay, then the lots of text output. <-data-evaluate-expression TfpgButton(TfpgButton(Sender))^>

The 2nd email referred to executing by hand in gdb. Except for the difference between "p" and "-data-evaluate-expression" it (the 2nd) would mean that gdb can execute them quickly.

But the 1st indicates, that the delay is between lazarus sending the command, and receiving the result. Meaning either gdb, or the communication channel (pipe).

You were watching the "debug output window", So maybe this is updated delayed.
Maybe you can recompile with the following defines: DBG_VERBOSE
and optional DBGMI_QUEUE_DEBUG

Then start lazarus from console, gdb communications (long lines shortened in the middle) and some other info will be printed. the communications will be printed to console (immediately when received)

So this could help ensuring that it is either gdb or communication.

If it is communciations, then of course it could be how lazarus reads the pipes => but that code has not changed, so not likely.

Martin wrote

What exactly do you mean "stay active" ?

See attached archive. There are three files. The two text files show the output captured from the Debug Output window.

test1.txt
- Show value hint while debugging is unchecked
- Automatic typecast for objects in unchecked

test2.txt
- Show value hint while debugging is checked
- Automatic typecast for objects in checked

The Report.html file shows the difference between them. Hardly any difference - not what I would have expected.

Also if "show value hint while debugging" is unchecked, shouldn't hint debugging be totally disabled?

Maybe I'm not understanding somethig hear. Is so, please explain, as I would really like to help where I can regarding Lazarus + Debugging.

- Are the commands still send, if you disable the option?

Yes

- Is just the slowness remaining ?

Slowless remains no matter what I have checked or unchecked. If I mouse over any class instance (eg: Listbox1, MyObject, Sender etc....) I have a 5-10 second delay before I see debug hint information.

The 2nd email referred to executing by hand in gdb. Except for the difference between "p" and "-data-evaluate-expression" it (the 2nd) would mean that gdb can execute them quickly.

Yes, executing the commands shown in Debug Output window, but directly inside GDB (not via Lazarus IDE), then the output of any of those commands are instant. So the slowdown is somewhere in Lazarus IDE.

But the 1st indicates, that the delay is between lazarus sending the command, and receiving the result. Meaning either gdb, or the communication channel (pipe).

It goes like this.
- I hover the mouse over Listbox1 in the source code.
- Debug Output window shows a command being sent to GDB
- 5-10 seconds latter I see the Debug Output window populated with lots of data
- 2-3 seconds later I see the Hint window appear in Lazarus source editor.

As I said, this now happens, no matter if the two checkbox options (listed above) are checked or not. This makes debugging unworkable in Lazarus Trunk (at least for me).

It's end of the day here, but I'll try this first thing tomorrow morning.

If it is communciations, then of course it could be how lazarus reads the pipes => but that code has not changed, so not likely.

I'll checkout an older version of Lazarus Trunk tomorrow and see if this slowdown is a recent issue, or something else that has gone unnoticed.

Thanks for your patience. :)

I just tested on an old fedora installation (VM same pc as my windows)

Indeed the long wait is there.
However, it is certainly not GDB, and not the pipe/communication either.

The wait-time occurs after gdb returned. And it also occurs, if the hint is triggered a 2nd time. In which case gdb isn't even involved, since a cache is used.

Switching the auto-cast off, and getting a small amount of data for the hint (just "<TObject> = {vptr xxx}" provides a fast hint to.

Getting the TForm1(Sender) as a watch is also very fast => so it is not likely that the issue is caused by any processing in gdbmidebugger.pas (or any of the debugger classes). If at all getting the value for a watch

So I got a big hint from codetols, by adding a large comment in front of the declaration of TForm, and then hinting for TForm
- If I add many lines => no problem
- If I add one very long line many 1000 char) then => ouch

bTW installing TurboPowerIProDsgn, and getting nicely formatted html hint => and the type-casted debug hint works all fine and fast (but be aware, the wrong mouse movement with that hint, and it crashes)

So the time must be lost, when a huge text is prepared for a hint (or more likely, since it doesn't happen on windows), the problem may be in the widgetsetcode for the hint on gtk2 (I haven't tested my gtk2 on win install)

No need for recompilng with the extra symbols, that I specified.

It isn;'t the debugger.

See my other mail.

Any hint in gtk2, that consists of a single very long line (that needs to be wrapped) has the same slowness

using html hints fixes that, but crashes elsewhere

In the first you evaluate Sender and Listbox1

In the 2nd you only evaluate Listbox1

only the 2nd has

The check if listbox1 needs typecasting => it doesn't need, it is already declared the same as it actually is.

So yes the files have little difference. Had you done Sender again, there might have been a diff.

Also if "show value hint while debugging" is unchecked, shouldn't hint debugging be totally disabled?

you are right, there seems some problem there.... it should

> - Are the commands still send, if you disable the option? Yes

No, but in your example it is hard to see

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110908/927a7c59/attachment.html>

This is was introduced just yesterday in response to a feature request.

-Fl?vio

reported:
http://bugs.freepascal.org/view.php?id=20196

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110908/2ceb4a73/attachment-0001.html>

Martin wrote

> > Also if "show value hint while debugging" is unchecked, shouldn't hint > > debugging be totally disabled? you are right, there seems some problem there.... it should

Reported as:

http://bugs.freepascal.org/view.php?id=20201

Regards,
- Graeme -

Martin wrote

bTW installing TurboPowerIProDsgn, and getting nicely formatted html hint => and the type-casted debug hint works all fine and fast (but be aware, the wrong mouse movement with that hint, and it crashes)

I'll try this, but the "and it crashes" doesn't boast a lot of confidence. ;-)

So the time must be lost, when a huge text is prepared for a hint (or ...

Excellent, thanks for help finding the cause of the slowness.

Regards,
- Graeme -

I did fix that last night...