Forum > Debugger
FpDebug Watches window feature request
440bx:
Hello,
It would be very nice if the "Page size" value was limited to something reasonable, for instance 100 because if a large number is mistakenly typed in the page size field, it causes Lazarus to spend quite a bit of time to populate the (unreasonably large) page.
Refer to the attached screenshot. The value 985 was supposed to be in the "index box" not the "page size" box. This caused Lazarus to spend close to 2 minutes to make a 985 element page which is rarely if ever practical.
small detail but, it would be nice to have that protection because some lists may be hundreds of thousands of items and mistakenly typing a number that large in the page size field would likely require terminating Lazarus.
Comments welcome.
Martin_fr:
I can see the problem. Especially with an array of "some structure or composed value".
Fetching a thousand integer would be faster. And then one could want them on one page to scroll through them.
Also I want to add search/filters. (like in the inspect window). And that only works with values that have been loaded for display.
More important is the ability to abort. The values are already loaded in a thread (with fpdebug). So, if the number was decreased while they are still loading, then they should be stopped. (they aren't yet).
440bx:
Hello Martin,
Since I have an attachment in the first post, I'm going to use it to state another "wish" about the Watches window.
When FpDebug encounters a DebugBreak() in the code, it breaks as it should and, "closes"/collapses all the lists and records that have been expanded. e.g, in the previous snapshot, the AddressMap record is "closed" (the fields are no longer shown) and the AddressMap^.AM_INFO array is also "closed" (the elements are no longer shown.) It would be really nice if it didn't close/collapse the records and lists, i.e, ideally, upon hitting a breakpoint, the view (fields/records/lists shown) would not change in the watches window (of course, their values would/should change as required but not the layout of the view)
I hope the above is understandable.
Thank you.
Martin_fr:
It should only collapse entries, if the sub items don't exist at the current location. e.g if you had "c" as structure, but now it something else...
I think it should even stay open if the fields (field names) change.
It may collapse if an array isn't long enough any more... Not sure.
That is based on the top stack frame. (as that will be active when you enter pause)
E.g.
* if I am in a method of TForm1 and have "self" expanded, and I step through the code, then it stays expanded.
* The same, if within the expanded "self" I have further expanded subwatches (like FFormHandlers, or FIcon)
* I've also tried with an "array of TForm1"
If it collapse for you, even though the values are there, then I need a bug report with an example to reproduce.
If you mean, they collapse because there is no data at the current location, but you would either
- like them to show "error" on each line (which won't work for an array, because it needs at least the length)
- re-expand when data becomes available (continue run/step OR changing stack frame)
In that case please add a feature request (because my list is filling up, and I can't keep all the forum threads open as reminder)
As for the feature part. That may be a while, it probably will have to wait until I solve the entire "how to store the metadata / like display-format".
E.g., currently locals don't have individual display formats, because they come and go all the time (stepping into changes the list, etc, but internally even just stepping recreates the list). If the list is changed/ recreated, then currently that looses all the metadata...
That affects at least the ability to restore "expanded" for nested items. Because currently that state is stored on an item that might have been deleted.
Martin_fr:
Also keep in mind if you want
--- Quote ---If you mean, they collapse because there is no data at the current location, but you would either
- like them to show "error" on each line (which won't work for an array, because it needs at least the length)
--- End quote ---
That causes an other issue.
Let's say "foo" is an array. And expanded. And if the array wasn't there, the IDE would even remember the last "length" so it could show "dummy error entries".
However any of the following could happen.
==> You step into something, that has a variable of the same name "foo", but different data.
* The array had the entries 100..110 shown. But it now (temporary) shrinks to 20 entries. Then it may no make sense to show error entries for 100..110.
And if "bounds are enforced" then that is not possible. (There is another topic on that)
* It was an array of structures in the caller, and now is an array of integer (or an array of array).
Then what about nested entries that used to be expanded?
- If the new array is "of integer" there is no expanded state. There is no way to have an integer expanded with dummy error entries.
Even restoring such expanding states later is tricky, because even if later there is an array that could expand those sub-items, it may not be the same as before.
- If the array changed to an "array of array" should it then keep the sub-arrays expanded, to match which sub-structure were expanded before?
* Similar, if "foo" is an array in the caller, but a structure in the callee => keep it expanded? (not sure it currently may even do that).
But it certainly becomes tricky which sub-items to re-expand when it changes back to an array (step out). Even if the previous set of indexes was remembered, is it still applicable, did the step out return to the array to which that applied (instead of step out, it could be "run to break")
I have to solve some of that anyway for locals... I have to see where I end up with that.
Navigation
[0] Message Index
[#] Next page