Hi,

I made a small patch for lazarus that allows to issue debugger commands in the Evaluate/Modify window. Commands are entered as an expression starting with a '>' character. For example evaluating '>x/20x $sp' will show you the 20 first values on the stack. When entering debug commands the result area is not cleared but the commands issued and their results are appended to the existing result, just as in a console gdb session. The same syntax can also be used in a watch expression when using the default style. The command will then be executed at every step or breakpoint hit and the result shown in the watch window. The one line output in the watch window limits of course what you can display.

If anybody is interested in this, I'll submit it to mantis.

Ludo

I was wondering, when I saw the log that you posted on mantis.... I saw breakpoints in the debugger code ....

Have you tried to compile the IDE with DBG_WITH_DEBUGGER_DEBUG defined?

It does exactly the above. It has been there a very long time.

It has also been decided, that this feature will only be available via this define.
Reason: This is mainly for people who wish to debug/experiment with the debugger. And it also requires knowledge of both: gdb and how the IDE deals with gdb.

If in this command window you execute statements, that run the exe ("-exec-continue" / "c") then the IDE looses sync, and your debug session is gone. Even if you change the stackframe or thread, you can get wrong results....
Fixing all this will only make the ide code more complex and harder to maintain.

Not sure of the use of that?
What data do you want to display?

Ludo Brands wrote

The one line output in the watch window limits of course what you can display.

You have seen the new feature in Laz 1.1 ?

Thanks to Darius Blaszijk there is a multi line view (2nd last tool buuton)

I was wondering, when I saw the log that you posted on mantis.... I saw breakpoints in the debugger code ....

I told you in the mantis update;)

No didn't know about that define. I didn't encounter anything like that and I actualy did search for somehting like that before starting to do any coding. Searching for the define in the files I opened in the IDE only brings up the conditional declaration of function GetDebugger: TDebugger;. So it seems I have been working in a completely different area of the code. Where would I enter teh debugger commands when using DBG_WITH_DEBUGGER_DEBUG?

I understand. It is very easy to shoot in your foot using the debugger directly.

I have had too many cases where I had to use the gdb command line to debug code. Reason why I wanted to do something about it. Examples:
- wrote a while ago a fpc program that had to do some stack walking. Hence the x/20x $sp example.
- searching in and displaying a particular memory area that is in pascal just a pointer. When tracing in assembler there are many cases where I would like to now the contents of the memory area pointed to by a register.
- tried to get to the VMT of a COM interface yesterday
- info fun with partial function names
- set a breakpoint at non fpc code (dll exported symbols for example)
- etc.

Non of this is to debug the debugger.

Ludo

Hadn't noticed it.
Perfect! It allows to watch bigger unnamed memory areas such as the stack or a data packet returned by a function with something like x/100x $eax

Ludo

did you include the debugger directory?

So it seems I have been working in a completely different area of the code. Where would I enter teh debugger commands when using DBG_WITH_DEBUGGER_DEBUG?

In the "Debug output" window. Where all the gdb stuff is.

http://imagebin.org/214731

memory dump of $pc^

- searching in and displaying a particular memory area that is in pascal just a pointer. When tracing in assembler there are many cases where I would like to now the contents of the memory area pointed to by a register.

see above

- tried to get to the VMT of a COM interface yesterday

You need to dig into FPC, to find the offset .

Not sure how to bes do in, as you need to get tthe interface from the objecht first, I guess?

Here is how the instance class name is gotten

-data-evaluate-expression (^^^char(self)^+3)^

the 2 inner ^^ are just pointer. There could be any type. Wouldn't need to be char.
The first address of the object points to the VMT, in the VMT the pointer to the name (shortstring) is the 3 entry

To try stuff like that, the "Evaluate/Modify" window is quite good too.

- info fun with partial function names

Not sure what you mean:
But you know the debug inspector (context menu on watches) shows the objects method (if they are avail)

- set a breakpoint at non fpc code (dll exported symbols for example)

We have address breakpoints, you can set them in the disassembler.

or "Add" > "Address BrkPoint" and enter address. Either context menu in breakpoint list, or main menu "Run"
http://wiki.lazarus.freepascal.org/IDE_Window:Breakpoints

There are watch point too, if your hardware supports it

- etc. Non of this is to debug the debugger.

Right, there are features in gdb, that the IDE does not yet support (e.g. attach/ detach)

Better to implement the features ....

But feel free to use that define

In the "Debug output" window. Where all the gdb stuff is.

Ok found it.

I rarely use the watch window and hadn't explored the memory dump style. Here is how x/40xw $sp is presented in my patched version:

x/40x $sp

0x396fe08: 0x00000000 0x00634750 0x03e87d10 0x03e87d10 0x396fe18: 0x00426ff0 0x000cee18 0x00079b68 0x00634750 0x396fe28: 0x00703444 0x0062deb4 0x0396fe60 0x0396fe0c 0x396fe38: 0x00426ee2 0x0396fe24 0x0396feb0 0x00000001 0x396fe48: 0x00000001 0x0396fe98 0x0396feb0 0x0053047c 0x396fe58: 0x000cee18 0x000cee18 0x0396fec0 0x00419e1e 0x396fe68: 0x00000000 0x0041c37c 0x0396fe58 0x0396fe98 0x396fe78: 0x00000001 0x00000000 0x00634750 0x00703444 0x396fe88: 0x0062deb4 0x0396fed8 0x0396fce8 0x0041c34e 0x396fe98: 0x00634750 0x00703444 0x0062deb4 0x0396fec0

The watch window (note also the little endianness making addresses even more difficult to read):
0396FE08: 00 00 00 00 50 47 63 00 10 7d e8 03 10 7d e8 03 f0 6f 42 00 18 ee 0c 00 68 9b 07 00 50 47 63 00 44 34 70 00 b4 de 62 00 60 fe 96 03 0c fe 96 03 e2 6e 42 00 24 fe 96 03 b0 fe 96 03 01 00 00 00 01 00 00 00 98 fe 96 03 b0 fe 96 03 7c 04 53 00 18 ee 0c 00 18 ee 0c 00 c0 fe 96 03 1e 9e 41 00 00 00 00 00 7c c3 41 00 58 fe 96 03 98 fe 96 03 01 00 00 00 00 00 00 00 50 47 63 00 44 34 70 00 b4 de 62 00 d8 fe 96 03 e8 fc 96 03 4e c3 41 00 50 47 63 00 44 34 70 00 b4 de 62 00 c0 fe 96 03 6c fe 96 03 ee 9d 41 00 98 fe 96 03 28 ff 96 03 01 00 00 00 18 ee 0c 00 d8 fe 96 03 d8 82 41 00 00 00 00 00 18 ee 0c 00 00 00 00 00 18 ee 0c 00 40 ff 96 03 a3 e7 41 00 00 00 00 00 b4 de 62 00 00 90 fd 7f 44 34 70 00 b4 de 62 00 20 ff 96 03 e0 fd 96 03 38 28 54 00 e8 fe 96 03 00 00 00 00

The debug output window:

<x/40x $sp>
&"x/40x $sp\n"
~"0x396fe08:\t0x00000000\t0x00634750\t0x03e87d10\t0x03e87d10\n" ~"0x396fe18:\t0x00426ff0\t0x000cee18\t0x00079b68\t0x00634750\n" ~"0x396fe28:\t0x00703444\t0x0062deb4\t0x0396fe60\t0x0396fe0c\n" ~"0x396fe38:\t0x00426ee2\t0x0396fe24\t0x0396feb0\t0x00000001\n" ~"0x396fe48:\t0x00000001\t0x0396fe98\t0x0396feb0\t0x0053047c\n" ~"0x396fe58:\t0x000cee18\t0x000cee18\t0x0396fec0\t0x00419e1e\n" ~"0x396fe68:\t0x00000000\t0x0041c37c\t0x0396fe58\t0x0396fe98\n" ~"0x396fe78:\t0x00000001\t0x00000000\t0x00634750\t0x00703444\n" ~"0x396fe88:\t0x0062deb4\t0x0396fed8\t0x0396fce8\t0x0041c34e\n" ~"0x396fe98:\t0x00634750\t0x00703444\t0x0062deb4\t0x0396fec0\n" ^done

> - tried to get to the VMT of a COM interface yesterday You need to dig into FPC, to find the offset .

But it is so much easier to look at the memory area the interface points to directly. The debugger returns also symbol information when there is some that gets lost in the evaluate or watch window. For example here is a short session for an interface to an object implemented in TAbstractEventSink:

x/8xw 0x03E781A4

0x3e781a4: 0x00067108 0x00629ae0 0x03e78178 0x00426ff0 0x3e781b4: 0x000cee18 0x00000000 0x00000000 0x00000000

x/8xw 0x00067108

0x67108: 0x007030b0 0x03e87e40 0x34a715a0 0x11d06587 0x67118: 0x20004a92 0x4dacc7af 0x00000001 0x03e78178

x/8xw 0x007030b0

0x7030b0 <VMT_$EVENTSINK_$$_TABSTRACTEVENTSINK>: 0x00000028 0xffffffd8 0x0062d9c0 0x00703118
0x7030c0 <VMT_$EVENTSINK_$$_TABSTRACTEVENTSINK+16>: 0x00000000 0x00000000 0x00000000 0x00703390

The <VMT_$EVENTSINK_$$_TABSTRACTEVENTSINK> is info that is lost when using the watch window. I think you could also agree that the watch window is not the most appropriate to do this exercise neither.

I meant the gdb 'info function' command with regex parameter to find the address of a function.

> - set a breakpoint at non fpc code (dll exported symbols for example) We have address breakpoints, you can set them in the disassembler.

But how to find the address of for example a dll exported symbol?

Example:

info function OpenURL

All functions matching regular expression \"OpenURL\":

Non-debugging symbols:
0x444a82ee IEFRAME!OpenURL
0x444a82ee OpenURL

Thanks. Now that I have made the patch I'll hang on to it. The debug output window throws in a lot of what lazarus is doing with the debugger and the useful information is easily scrolled away by new debug info (mouse hovering over a variable, a single step, ...). It also slows down stepping a lot.

Ludo

I am not arguing against you using your patch. And if you want to distribute it, then fine.

Adding it to the IDE is out of question though.
To many dangers, and people will complain when they loose their debug session, because they did the wrong thing.

Also I am pointing out what can be done by the IDE already. Though admittedly some of it needs to be improved.
And if added proper, then everyone can use it.

.....

Yes a proper viewer must be written for this.

So where do you get the address?
Btw, if you have the name, you can enter it as watch, and specify mem-dump

> x/8xw 0x03E781A4 0x3e781a4: 0x00067108 0x00629ae0 0x03e78178 0x00426ff0 0x3e781b4: 0x000cee18 0x00000000 0x00000000 0x00000000

despite the fact that currently mem dumps are really ugly, you can also enter the address into a watch ("0x3e781a4^"), and get the mem dump there.

So again, it boils down to having a proper mem viewer (well and removing the need for the ^ )

yes, that is missing. the ide doesnt look up addresses and tell you the name...

>> - info fun with partial function names >> I meant the gdb 'info function' command with regex parameter to find the address of a function.

ok.

I guess the address breakpoint could be extended to take symbol names too.

yes its a memo... memo is slow

Hi,

I think it would be much better, if it were a regular feature like in Ludo's patch:

* the define is difficult to find

* if you recompile Lazarus frequently, it often disappears.

* if you have a Lazarus without define, you can't enable it without recompiling and stopping the debugged application

* Lazarus will never have direct support for all possible gdb commands. If you have added them all, there will be new ones in gdb

* The output in the debug window is difficult to read

* Most commands people use won't break the debugging session, like info, x, ...

(and I just debugged an application that crashes if debugged and "set scheduler-locking on" is not set, with such a patch this option could be set, without restarting gdb)

* If debug commands were that dangerous, Lazarus could show a warning, when the feature is used the first time.

* You can write your own gdb python plugins and call them

* People using a programming language are not stupid and can figure out how to use gdb

Benito

That is because it is not supposed to be used.

Yes for the experienced users there are sometimes cases that would make it desire-able. For the novice it would be in the best case something they do not use. But it could easily cause them problems.

I already pointed out, how easy you can upset the IDE-to-gdb interface, if you issue the wrong command.

* if you recompile Lazarus frequently, it often disappears.

I recompile very frequently, and it never wet.
I always recompile from the Tools menu

And that is the problem.

This also means that if gdb access is possible, then it is impossible (even if attempted) for the IDE to monitor all the commands. Given that some commands have hidden features...
If added people will accidentally type the wrong command.

* The output in the debug window is difficult to read

Yes.

That window shouldn't even exist. Or move to IDE internals It is only useful, so people can sent the centent, if something went wrong

* Most commands people use won't break the debugging session, like info, x, ...

yep hit "c" instead of "x" (on most keyboards they are next to each other)

And Apple supplies are broken gdb. Some of those commands can do harm.

Feel free to provide it as an installable package.

Then it can be downloaded and installed

Benito van der Zander wrote

(and I just debugged an application that crashes if debugged and "set scheduler-locking on" is not set, with such a patch this option could be set, without restarting gdb)

Maybe we need an option.

Though one question:
I can see how you can (technically) change this while the debugger is running.
But isn't that to late. If your app crashes without that, and you already started the debugger. Then would it not crash?

Anyway if we have a list of such options, then they can be added as feature request.

Ok I read up a bit on it (I haven't yet debugged any threaded stuff in gdb). Seems that could be added to the thread window (as tool button or popup menu)

I already pointed out, how easy you can upset the IDE-to-gdb interface, if you issue the wrong command.

You said that, but I have never seen it happen.

Althought gdb crashes sometime randomly, even without running own commands.

And running arbitrary commands is not special, there are other things that upset gdb, just as well.

function TEST: integer;
begin
while true do ;
end;

Evaluate TEST() and the debugging is broken, until you call "reset debugger".

And that might happen with all evaluations, just as likely as if you run direct commands.

I recompile very frequently, and it never wet. I always recompile from the Tools menu

I use "svn update; make clean all"

* Lazarus will never have direct support for all possible gdb commands. If you have added them all, there will be new ones in gdb And that is the problem.

And allowing direct commands is the solution.

Just to dump the text output of gdb, it doesn't need to know the command

yep hit "c" instead of "x" (on most keyboards they are next to each other)

continue, step, next, stepi, nexti, stop, kill, quit

Those might not be all commands that are dangerous, but I doubt a novice will know the names of another ones.
And Lazarus can check for them and their abbreviations and call the corresponding interface function.

And Apple supplies are broken gdb. Some of those commands can do harm.

That's Apple's problem

Feel free to provide it as an installable package.

Can a plugin even send commands to the debugger, if that define is not set?

And then you have the package, a new Lazarus version appears, and it doesn't work anymore...

If the first breakpoint is hit, all threads are stopped anyways. Only single stepping causes a problem

Anyway if we have a list of such options, then they can be added as feature request.

They could.

But why maintain another list of options, if gdb already knows its options

But then, it is fair to say you are experienced with gdb. There are also lots of people starting on lazarus, who have not even heard of gdb.

I know. currently you can trigger function evaluation, even though nothing is ready to deal with.
I already have code, that parses expressions, and might in future prevent function calling.

And that might happen with all evaluations, just as likely as if you run direct commands.

Yes, or trying to modify an ansistring => boom

I didn't say that the debugger was perfect.
That is no reason to add more pitfalls.

Anyway, we both have our points. And it doesn't seem to change.

> > Feel free to provide it as an installable package. Can a plugin even send commands to the debugger, if that define is not set?

That part of the interface can be added permanently. The idea s to spilt the debugger and have packages.

Then an interface would be created.
But the relevant parts of the interface can be added and published as soon as someone provides them

Yes. I read up.

BTW what about "thread apply" in gdb?

Because it is more user friendly, than having to goggle gdb and type some commandline style stuff...

That is why I preferred to bring it up on the mailing list instead of posting the patch immediately on mantis.

Also I am pointing out what can be done by the IDE already. Though admittedly some of it needs to be improved. And if added proper, then everyone can use it.

I understand that making a gui for a debugger is not easy at all and it is difficult to please everybody. Things like the disassembly window, the source code window, watches are invaluable compared to what the command line gdb offers. However, trying to fit everything the command line can do in the straight jacket of the GUI is artificially clipping the power of the debugger. Weeding through arbitrary memory or some of the other usage examples I gave are not the standard usage for most users. So I wouldn't expect that any of it would be accomodated in a GUI and feel a little bit sorry that this exchange turned into a list of things the IDE can't do or needs improvement in. It just started as wanting to share a personal, small effort to combine the advantages of the GUI and the flexibility of the CLI.

A proper viewer would mean: all possible formats gdb supports + unit size + arbitrary data lengths + showing symbols gdb returns. Is that worth it?

In this case it was an object I instantiated myself and the interface pointers were returned from a call to queryinterface on the object and on its IUnknown.

Ugly is not a problem. Not being able to do a simple cut and paste of the address is what hurts. When looking at a chain of pointers like in the example, the downside of watches is also that or you create a watch for every pointer and you delete them all after use or you re-use the same watch but then you don't have any history in case you picked the wrong address in a table. In both cases a lot of clicking to simulate something that can be done easily when using cli commands.

Still need to know the exact spelling of the symbol. The same symbol can be uppercase or "original" case, sometimes depending on wheter you have debug info or not (exported symbol). Plus the name mangling for class methods. Example: procedure _FPC_WinMainCRTStartup;stdcall;public name '_WinMainCRTStartup'; is known to the debugger as _FPC_WINMAINCRTSTARTUP (stabs info available). I find myself using 'info function' frequently to find or disambiguate functions.

And I appreciate that you take the time to do that.

But this is not only about what gdb can or can not. There is a wide range of users. And a feature like this is suited for a very small group of them.
By comparison the dangers versus the benefits simply do not hold up. (It does measured by the standard' of the top 1%, but not for the rest)

Also (and that is why I mentioned the IDE parts) splitting this into :
- workaround for missing IDE feature (e.g. mem viewer, threads)
- features that are unlikely to have a frontend

How many are in the 2nd category. I know for you there are some. But for most users, this is not the case. If it was, then it would be a feature that needed a front end (due to demand)

If it is put in the IDE it will need maintenance. Like any feature of course. The fact that it needs maintenance an its own does not stop any feature.
But again, this can be expected to need lots of maintenance in comparison to the benefits (averaged over all users)

I do not know if I will have the time. But from whatever time I have, I'll set some apart to help you make a package interface. Then you can provide it as yours, and maintain it yourself.

For most people
- byte, word, dword , qword
- High/Low endian
- maybe bytes per line (8, 16, 32)
- maybe ascii or even utf8 representation

Not following: why can you not cut and paste? The new multiline view is a memo, it allows to select and copy

(there is a bug in trunk, that prevents keyboard from almost all toolwindows. But that is not part of this topic)

Well watches do have history and snapshots in the IDE.

The cli is not that comfortable (maybe gdb does provide that, but more work)

And for one off evaluation, there is the "evaluate" window

But thats beside the point? using a watch or the commandline => the question of needing the address or name is the same.

But then, it is fair to say you are experienced with gdb. There are also lots of people starting on lazarus, who have not even heard of gdb.

For those it can show a warning if they enter a command

And if having a debug windows, in which you can see the commands the IDE passes
to gdb, and then try your own, modified version of the commands, is an amazing way to learn to use gdb.

I already have code, that parses expressions, and might in future prevent function calling.

Really?

Then it becomes impossible to read complex properties, and you need a way to run direct commands
even more!

Anyway, we both have our points. And it doesn't seem to change.

Well, that is a point, I can agree with

BTW what about "thread apply" in gdb?

Single stepping seems to be always applied to all threads.

(which causes the problems in my case )

Because it is more user friendly, than having to goggle gdb and type some commandline style stuff...

User friendly as in "I have never seen a debugger before, but if I click that button, I can see what my program is doing"

But if you have some experience, it is not user friendly, if you can't do something, because the feature is simply not there, and have to stop the debugging session, and restart the program with the cli gdb.
Or if you always have to click that button, and can't automate it with a python script or by copying some gdb commands from clipboard.

gdb also has a great documentation with help, apropos or tab completion.

And if you don't find something, you can google for it. There are a lot more references about gdb commands than Lazarus buttons.

E.g. if you google for "gdb view memory" , every result describes the "x" command.
If you google for "Lazarus view memory", you find a memory game, the haunting memory of a derby, and star trek.
If you hadn't told me that you can view memory dumps in the watch window, I would have never guesses that.
(and someone who doesn't know pascal, c++ and gdb, would never guess that you need a trailing ^ at the address).

Well that is why we need a plugable interface. Then expert packages can be added.

All the things the GUI can't do or need improvements are just reasons to merge your patch (or a similar one) into Lazarus!

I will advocate again and again for it...

Things like the disassembly window,

Yes, the disassembly window is great and I don't know any gdb based debugger that has it that nice.
(except Insight years ago, but that is not maintained anymore, doesn't work with a new gdb and has become useless)

But it is a new features, and we had to wait years for it. With a direct interface, you could just have used "disassemble /rm ..." and use that as a workaround,
until the GUI is finished

(and it uses at&t syntax, is there any way to switch it to intel? for the cli there is...).

- workaround for missing IDE feature (e.g. mem viewer, threads)

But you don't know which IDE features are missing, until you need them. And then it is too late to implement them.

But it is a single feature that can be used for various things.

if it is implemented, it can replaces several other features only the 1% need,
and you save a lot of time, when you don't have to implement and maintain those!

The patch is 18 lines of new code. I have attached it. The difficulty was not writing the code but figure out where to put it. This mail exchange has taken more time and lines written than writing the patch (note that I don't mind). I'm perfectly happy sharing it this way. The users that would benefit from it would know how to apply a patch. Don't make a package interface for 18 lines of code, please.

This was about extending the address breakpoint to take symbol names. My point is that taking a symbol name assumes you know the symbol name, spelled correctly, or you provide a way to look it up: a front end to 'info function'. With all the exported symbols from windows dll's I wonder if the average user would be able to do whatsoever with such an interface. So the comment was in the same line as the previous ones: is this worth the effort?

Thanks, Ludo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb.diff
Type: application/octet-stream
Size: 1476 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120601/a2c5a100/attachment.obj>

Omg, it's much worse.

That loop continues to run within gdb, and doesn't stop, if you call "reset debugger".

In fact, it doesn't even stop, if you close Lazarus.

Now my laptop has been running at 100?C for 3 hours, I hope it hasn't been damaged...

Ludo Brands wrote

is this worth the effort?

Well that depends how many people benefit.
Though having said that, there is nothing wrong with a feature, even if there was just one person. SO long as in is no issue to others.

I might be persuade to put (part of (see below)) it i an appropriate IFDEF. No not an option.

1) this a 2 individual things.
keeping a scrolling history in the evaluate window can be done for all evaluates. May even be useful. Could have a checkbok in that window.

So that part is to be skipped. But a better version is welcome.

2)
Any reason to limit to wdDefault ?

Since you always set ddsValid you could have it in the main method body (where the "!" is handled ( a relict, that will go ....))

A few mails ago you were advertising to add even more pitfalls, that could have all side effects. And about the fact that things can happen you said: "You said that, but I have never seen it happen. " Well now you have seen it happen.

btw trailing quotes, with no further reply to it, are a form of over-quoting. I hope it hasn't damaged my network cable SCNR

No, I said I had never seen that, when calling my own commands, with the exception, that I saw it, when Lazarus was running its command.

Anyways, "reset debugger" is supposed to kill gdb.

btw trailing quotes, with no further reply to it, are a form of over-quoting. I hope it hasn't damaged my network cable SCNR

That's different, my laptop has never been that hot before, not even when playing computer games

It closes the process that runs gdb. That normally exits gdb. But apparently not always.

As you can see, another thing that needs to be improved.

Well I gave you a SCNR for the pun. Not meaning to downplay the problem you had. The rest was unrelated (I have no problems with a few extra lines, but I thought on that mail it was a bit much: 2 pages with 0 lines reply to it.)

That was my point. Adding a front-end to 'info function' is going to cause more confusion with first time users than solving problems. Enter something like CRT and your screen is flooded with symbols from the RPCRT4 dll. Enter dll, wait 30 seconds and get hundreds of ntddl and _$dll$user32$ entries. So this does not fall IMHO in the category of "So long as it is no issue to others".

I might be persuade to put (part of (see below)) it i an appropriate IFDEF. No not an option.

The patch is concentrated in 2 blocks in 2 files and is very unlikely to cause svn conflicts and will survive svn updates. I'm perfectly happy keeping it that way and am not trying to persuade you for anything. If you like some ideas you want to include in the standard version, so much better;)

What would a better version look like, other than the checkbox and perhaps a clear history button? Ctrl-A del works perfectly btw. A better visual differentiation between expression and result?

1) I didn't know the debugger code before starting this little patch. wdDefault is used in both evaluate and watch. And all the functions and variables needed are in scope of the function since they are used in the other "case" blocks. I noticed the main body and the handling of "!" but took the road of least resistance and put the code where all was available, guaranteed, without further investigation.
2) It is cleaner to have same level of functionality in the same place. Even if not limited to wdDefault I would have put the 'if' before the 'case'.
3) In hind sight, for the watch, I prefer getting an error message when selecting display options like mem dump, character, decimal on a cli command than ignoring them. A new watch is created with wdDefault and a user selects another display format if he wants another format. With cli commands he won't get another format and the error message will somehow ack that.

Thanks, Ludo

Well It would have a checkbox, to decide if history is kept, or if result replaces all.

Maybe insert
--------------
between results

Btw, what do you think about insert on top and scroll the down?

Then the error message needs implementing (well would need, if the code was added for everyone). And we would already have maintenance....

One of the reasons I do not like the location in, that the entire subroutine is subject to finding parent frames in nested subroutines. Only your code will never.

OK I'll propose a patch.

Btw, what do you think about insert on top and scroll the down?

Probably less disturbing for the users when showing classes or big records that exceed the window height. Append would show the bottom part while currently the upper part is shown. It matches also the order of the history list of expressions. Other than that probably a matter of taste. Linux users are used to look for recent events at the bottom of logs. Windows users look at the top of the event logs.
For cli commands, which will not be included, insert on top is very unnatural. So I'll probably propose a configurable top/bottom insert. Something like a 3 state button or combobox. Top insert, no history, bottom insert. No history state could serve as clear screen.

Ludo

Eric makes some good Delphi IO Components, COMPORT and IOPORT. These worked GREAT in Delphi 6, but I can't afford anything new since I retired, so I am trying Lazarus.

Has anyone successfully used Eric Z's stuff in Lazarus?

-- Bob A

No, you can't use it directly, you need minor changes, but there is many components can replace it.

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120602/63147874/attachment.html>