[fpc-pascal] FpDebug hands-on: AnsiStrings

Joost van der Sluis joost at cnoc.nl
Thu May 21 17:29:09 CEST 2020

Op 20-05-2020 om 20:48 schreef Martin Frb:
> Ok, here are some of my ideas/hopes/dreams/wishes for the IDE....
> They are all "ideas only", with on knowledge of when/if they may be done.

Ok, clear. Thanks again for the info. I think we can conclude that most 
parts are there. It only needs some polishing. Except for the threading 
and smoothness of the debugging-experience in Lazarus. There we have 
some work to do...

Now, a hands-on example. We can discuss the theory later on again.

I've added codepage-support for ansistrings, compiled with -gw3. This is 
done in the TFpValueDwarfV3FreePascalString class, which does the heavy 
work regarding the formatting of strings. Although there is also some 
code in TFpDebugDebugger.EvaluateExpression and probably other places 
that change the formatting of string-values.

So I've made my change in TFpValueDwarfV3FreePascalString, but I don't 
know if this is the right place. After all, it is about formatting, and 
this class is related to the Dwarf-debug info. On the other hand. I do 
understand why this logic in implemented here. This is *the* place where 
all the relevant information is present.

But that the design is problematic can be seen in a comment in the file:

   // TODO: XXXXX Dynamic max limit

This seems an easy task, but it is not. TFpValueDwarfV3FreePascalString 
is not bound to the GUI or does not have formatting-settings. But it is 
the place where the formatting takes place! But adding a 
formatting-setting (like a max-length for strings) at this location 
would be really strange.

I see two solutions: Besides the AsString property we could add a 
GetAsString procedure with some parameters on how to format the string. 
Maybe the easiest at this moment, and this morning I though it was a 
good idea. (Note that I want to add more stuff, like function to 
retrieve the code-page, and the raw-data)

But then again, maybe the other solution, to split this formatting-logic 
into another class might be better...

I'll try if I can split the logic. If doable, that might be better.

(Still a lot of theory, though)



More information about the fpc-pascal mailing list