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)



fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org

Reply via email to