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@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
