[fpc-pascal] FpDebug hands-on: AnsiStrings

[Joost van der Sluis]

Op 21-05-2020 om 17:29 schreef Joost van der Sluis:
> 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)
> 
> Regards,
> 
> Joost.
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal