Hi all:

I've tried to cast the argument 'Sender' from a call to an event procedure, but it didn't work. The event is triggered by a TSpeedButton push, and the code of the action call contain the sentence:

-- if Sender is TSpeedButton then
--      buttn:=TSpeedButton(Sender);

The code compile without raising error or warning, but at run-time Sender is not of TSpeedButton's type, like it is in Delphi.

What's the correct way to cast objects in FPC ?

Can anybody help me ? Thanks in advance.
I am using lazarus-0.9.28-2 on linux, 0.9.30 on XP, fpc-2.4.2 J.L.

How do you know that it is not TSpeedButton?
Please post more code.

What's the correct way to cast objects in FPC ?

The snippet's syntax is correct.

Mattias

Hi, Mattias, this is the code for that action:

procedure TAyDForm.ButtnBHExecute(Sender: TObject);
var buttn:TSpeedButton;
    indBtn: integer;
    CanChange: boolean;
begin
  if (Sender is TSpeedButton) then
    begin
    bttn:= TSpeedButton(Sender);
    indBtn:=-1;
    repeat
      inc(indBtn);
    until ((bttn.Name = NameButtonSheet[indBtn]) or (indBtn = 17));
    if(indBtn<=17) then
      begin
      CanChange:=true;
      with PageControl1 do
        ActivePage:=Pages[indBtn];
      end;
    end;
end;

The code inside the 'if Sender..' statement is never execute.

J.L.

....

Set a breakpoint, and when the execution stops at it evaluate (ctrl-f7 or watch window) the following
(^^PChar(Sender)^+3)^+1

It should give you the real classname

Hi Martin, thank you for your email;

The watch window says the value of Sender is:
0x8327251 'TAction' #148

What does this mean ?, it was a SpeedButton that triggered the action, but I received a TAction object.

Regards,
J.L.

Jose Luis wrote

What does this mean ?, it was a SpeedButton that triggered the action, but I received a TAction object.

The SpeedButton triggered the action (eg; acButton.Execute), the Action then triggered the event handler. Possible?

Does the SpeedButton in question have it's Action property set? If so, then the SpeedButton's OnClick event handler will not fire. The Action property takes precedence as far as I know.

Regards,
- Graeme -

[...] (^^PChar(Sender)^+3)^+1 It should give you the real classname

Can this be used in the debugger hint, when moving the mouse over 'Sender'?

Mattias

I guess you can use
if (Sender is TAction) and (TAction(Sender).ActionComponent is TSpeedbutton) then
begin

  Btn:=TSpeedButton(TAction(Sender).ActionComponent);

Mattias

It should work on all modern gdb, 32 and 64 bit. PChar is not guaranteed to be defined, but can be replaced by ^char

One problem is that the string is not 0 terminated, so you get trash at the ned => it is a shortstring. If shortstring is defined (the debugger knows internally) then Shortstring can be used.
Otherwhise the length should be (not tested): (^^^Byte(Sender)^+3)^^ Basically class name is the 3rd entry in the PVMT

It should probably be added to the debugger => e.g to GDBTypeInfo But I see no problem with putting it in the IDE code until then.

But I only want to evaluate it , if really requested => watches eval already takes long enough.

There is a flag that can be passed to GDBEvaluate, it could be used to trigger the info => ultimately type-info should keep a reference to GDB, so it can fetch info, on access (but then it neds a callback, since info may not be immediately avail...

Hi, Graeme, and thank you a lot, it works fine now !

As you say, the Action property of the SpeedButton had it's Action property set (by default?); setting up the Action to None resolve the precedence.

Best regard,
J.L.

Hi, Mattias, and thank you, it works fine !

Indeed, this help me to understand how I can use the Action property of an object.

Best regards,
J.L.

Done

Please see the following bug report:

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

Too much of a good thing can also be a bad thing. ;-)

How long did it take before? Can you get me the "Debug output" from your system, please [1]?

I have a 2.4GHZ "Intel Core 2 CPU 6600" (4 years old). On Windows (and I found that using gdb on Win is often slower than on for example Linux). Yet it takes between 1 and 2 secs, but true it took half a sec before..

Stabs or Dwarf? gdb 7.0 and up, has a bug in relations to stabs. which may add a tiny fraction of time (but really tiny only); as it has to resend ONE dgb-command, which returns the bug-triggered error

Only, usually TSender is declared as TObject (well in LCL code, that may not be true for your code).
Displaying a TObject is showing you the vptr only => or in other words, it's telling you if the variable is nil or none-nil. That's not too useful.

How fast (or slow) fills the watch window on you pc? (if you have several watches)?

------
About the size of the hint => that problem existed before (only not for this use case). You could already get hints for variables that were declared as TForm or similar.

and yes, obviously a more structured output would be better than the current "continues text" mess. But again that is an old problem. And the unstructured output; imho is still better than the VPTR info of TObject

------
[1]
debug output:
It will look like "TObject" Or whatever Sender is DECLARED in your case) is ask twice from gdb. It is not, the 2 ptype are different (and were both present before). They are needed because gdb make sno difference between PObject and TObject. In case of the hint that is minor, as the hint dereferences anyway (and did so before the latest change), but that code is used for other calls too.

Martin < wrote

How long did it take before? Can you get me the "Debug output" from your system, please [1]?

In Lazarus (stable), the tooltip info appears instantly (when the tooltip is supposed to trigger - after a 500ms hover) - no delay. Using Lazarus 0.9.30.1 r30567M FPC 2.4.5 x86_64-linux-gtk 2.

I'm not sure I understand what "debug output" you are looking for. I attached another screenshot showing the method signature, and what was displayed in the tooltip in Lazarus (stable).

The method in question is a simple button OnClick event handler. Sender is declared as TObject.

http://bugs.freepascal.org/file_download.php?file_id=14461&type=bug

Stabs or Dwarf? gdb 7.0 and up, has a bug in relations to stabs. which

I'm using Ubuntu 10.04 64-bit running gdb 7.1-ubuntu. FPC version 2.4.5 which I think defaults to Dwarf under 64-bit Linux.

How fast (or slow) fills the watch window on you pc? (if you have several watches)?

The Watches window information displays instantly for the Sender variable, but it only contains a single line of information. MUCH less than the tooltip hint.

See your report, I put in an option.

As i wrote, it takes a bit longer: not sure if it is gdb, or just the pipe used to get gdb's output into lazarus. (afaik on win, those pipes are slow, haven't speed tested them on linux)

I'm not sure I understand what "debug output" you are looking for. I attached another screenshot showing the method signature, and what was displayed in the tooltip in Lazarus (stable).

Menu: "View" > "Debug winows" > "debug output" (I advice to open, it before running your app, or it may take several seconds or loner to open (TMemeo doesn't deal that good with big content)

I was interested to see, if any unexpected data was requested. (Unfortunately it is not always easy to extract useful info from gdb. e.g "ptype" does not differ between TObject and PObject (you need an extra "ptype Foo^"))

Or maybe it is just the time the entire text for the big object needs to go over the pipe

BTW, if you get a hint for the global "Form1" variabl;e => how long does that take.
It should get the same info.

> Stabs or Dwarf? gdb 7.0 and up, has a bug in relations to stabs. which I'm using Ubuntu 10.04 64-bit running gdb 7.1-ubuntu. FPC version 2.4.5 which I think defaults to Dwarf under 64-bit Linux.

GDB 7.1 should be fine / dwarf too (dwarf is now preferred anyway)

BTW: if you got time => try running ./debugger/test/GDBMI/TestGDBMI.lpi I would be interested, how well it does on 64 bit linux. (if there are error, you can enable "write logs" and send them (fro the failed tests) -- though the xml output already contains basic info.

I meant if you ever have many values (e.g 10 watches) to evaluate.

then especially if they are classes, record, arrays (arrays aren't to well handled yet, just another gdb limit :( )

On my windows, I get an average of 3 watches evaluated per second. Containing simple types, basic classes and such as tstringlist. Using huge classes such as TForm(1) drops the speed a bit. (since the return a lot of text, for the amount of fields they have. (and ptype, includes all the procedures, can't help that)

Having said that, on my Lazarus I have a lot of debg-logging configured in the debugger, that certainly does NOT add to speed.

Martin wrote

As i wrote, it takes a bit longer: not sure if it is gdb, or just the pipe used to get gdb's output into lazarus. (afaik on win, those pipes are slow, haven't speed tested them on linux)

Could be, but I can't say I have really seen pipes being slow under Linux either. I have a few applications that use pipes to read data etc.. They all seem quite speedy.

Menu: "View" > "Debug winows" > "debug output" (I advice to open, it before running your app, or it may take several seconds or loner to open

I attached the full output in a archived text file.

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))^>

BTW, if you get a hint for the global "Form1" variabl;e => how long does that take. It should get the same info.

This took almost double as long to output in the Debug Window. I thought my IDE froze or something, then as soon as I wanted to kill Lazarus IDE, I saw the text dump in the Debug Output window. I include that output in the attached archive too.

BTW: if you got time => try running ./debugger/test/GDBMI/TestGDBMI.lpi I would be interested, how well it does on 64 bit linux. (if there are error, you can enable "write logs" and send them (fro the failed tests) -- though the xml output already contains basic info.

There seems to be lots of failures. I'll send you the xml and log files in a private message. It's too big to attach in a mailing list message.

then especially if they are classes, record, arrays (arrays aren't to well handled yet, just another gdb limit :( )

I'm working on that - though slower than I was hoping. I'm busy implementing a Object Pascal based debugger for FPC (a fork of duby with lots of code cleanup). Only reading the DWARF debug information that FPC outputs (I'm not interested in STABS). I'm a totally newbie when it comes to debuggers, so I had to do a lot of background reading before I could start. If I have something worth showing, I'll make the project public. Hopefully somebody like yourself, with good debugger experience or DWARF knowledge, will then be able to give me some pointers.

Just the other day I had to do some maintenance work on a old Delphi 7 project. I forgot how wonderful Delphi's debugging was! I didn't need to write a single log file or console output. The built-in IDE debugger just worked perfectly. It's loooooong over due that FPC has something similar. One cannot have a compiler without a debugger!

Ok the flow of commands is as expected => I do need to fic the double typecast => that should be a single typecast only

I don't know if that does upset gdb

It's the only gdb command that returns data => and according to you apparently the one that takes 7 seconds.

Looking at the amount of output, it doesn't look like it would take 7 secs on the pipe => so gdb itself seems to take some time

I'll mail when I fixed hte double cast => let's see if that reduces tiem

Makes sense, since the initial 2 ptype, now both must eval the large TForm1 => this points to pat of the issue being either gdb or the pipe.

As for using 2 so similar ptype. The current concept is to try and get the result as correct as possible (though within limits, gdb isn't suited for it)
I do have the idea of implementing a "quick and dirty" option, in the debugger setting of the laz-options. So one can switch to a quicker evel, but may have to enter some "^" one sefl to get correct result (otherwise a class may be seen as pointer to class or vice versa) Not sure when I get to that...

Will look at, thanks

Ah, i have a similar idea for Lazarus 9though no time at the moment)

I want to start with a hybrid. Lazarus directly reading debug info => saving all ptype requests to gdb, and also being able to read difference that gdb ignores (strings, object pointer ....)

Then in a 2nd step, adding directly reading the debug processes memory (and reducing gdb to controlling breakpoints and steps

3rd step obviously getting rid of gdb...

But as I said, time is not on my side....

The slowness is under 0.9.31 (unstable trunk). I simply tested the same project under 0.9.30.1 (stable) to see the difference. Obviously not having the auto type cast functionality made it much quicker. I don't keep older 0.9.31 builds around, so couldn't test the speed difference of say a month ago. But if you really wanted me to test that, I can compile a older Lazarus trunk to test.

No need for older lazarus trunk... comparing speed to 0.9.30.1 is fine

The tests where run on trunk, or fixes ?

Martin wrote

> <-data-evaluate-expression TfpgButton(TfpgButton(Sender))^> I do need to fic the double typecast => that should be a single typecast only

:-) I was going to ask you about that one. It did look rather odd.

Ah, i have a similar idea for Lazarus 9though no time at the moment) I want to start with a hybrid.

That is an interesting approach. :) I'm also limited to free time, but try and move forward with the project as I can. Slowly but surely. What took really long for me though, is learning about how debuggers work, and the basics of DWARF debug information. It was/is interesting to learn those things though. Hopefully something useful can come out of the efforts though.

Martin wrote

The tests where run on trunk, or fixes ?

Trunk.

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))^>

I fixed the double casts in trunk (and casts to self).

Not expecting much of a time diff (unless something strange in gdb)

Actually, if you upgrade your trunk, you test with the feature disabled.

option / Editor / completion and hints

Martin wrote

Actually, if you upgrade your trunk, you test with the feature disabled. option / Editor / completion and hints

Those two options where enabled by default on my system.

BTW:
Shouldn't those two checkbox option be located under the Debugger section of Environment Options dialog? That's the first place I looked for the "debugger" settings, then had to re-read your message to find out where you added those options.

I'll get another lazarus trunk update and retest.

probably.

unfortunately the first one was already there... And that means it is also stored in the editoroptions.xml file

moving them, means to get access to the file representing objects, cross the frames for diff options...
not sure, haven't looked at it in ages. back when I did, that used to be all but easy.

So I just left them for now.

Also other hints (none debug) are there, and they share the timing slidebar....

Isn't the environment options stored in some "settings object", and the UI Frames simply being a gui to those settings?

Also other hints (none debug) are there, and they share the timing slidebar....

Alternatively, maybe one of those "settings shortcuts" in the Debugger frame would then be appropriate. eg: like what was done in "Editor | General | Indent and Tabs". There is a blue clickable text that takes you elsewhere in the Environment Options dialog.

several objects, one per file

As I said I haven't looked atit in a while, it may be easy now. don't know

There are many other thinks regarding the option dialog that could be improved. It's a whole topic on it's own....