https://bugs.kde.org/show_bug.cgi?id=514151
--- Comment #5 from Brendon Higgins <[email protected]> --- (In reply to Friedrich W. H. Kossebau from comment #3) > What about using "65536", so the limit + 1? With literal "65536", I get the crash. "65535" does not crash. If I return the value through a function, though, it does not crash - it seems to simply limit the value to a maximum of 65535 in that case. (In reply to Friedrich W. H. Kossebau from comment #4) > On your actual request, seems the initial code I drafted works for a first > start (with no more crash in the way), my sample file gets the enddata: > uint32 properly matching the very FF FF FF FF bytes I placed there (as by > your example) :) Let's see if I can harden the logic around that, so things > will not break otherwise. That sounds great! > For the user experience, I could imagine that there would be a last entry in > the array listing which points out explicitly that there are further array > items, just not listed due to resource restrictions. Would you have any > ideas/wishes how such a final entry should look like, any info you would > expect to see? Even something as simple as an ellipsis "..." would be great. More elaborate could be "%d more entries (%d bytes) not shown...", or something along those lines. I can't imagine what else you might add that would be useful in the general case. > Also considering to make the "warning" symbol also show the related warning > in a tooltip, was not obvious to me directly that one has to search the > actual warning in the script console window. Any related ideas/wishes here > also? The array's tooltip already displays some information, and I don't know if adding a tooltip to the warning symbol itself might compete with that? I generally agree, though: if I haven't been using Okteta like this for a while, it takes me some time before I eventually realize the Script console has more information for when some structure is upset. A tooltip pointing the user to "check the script console for more details", or something along those lines, would be a good addition. > ((For the future also wonder if array entries for overlarge arrays could be > just estimated on-the-fly with a cache... but well, porting to a > Qt6-compatible JavaScript engine is #1 task for now)) I personally think the next step here would be to make the "maximum array entries to read" value user adjustable. Another option could be that the user could press the "..." entry at the end of what's displayed in order to reveal further hidden entries. But for my purposes, simply correcting the offset of the next field (as it sounds like you've done) would solve the main nuisance. -- You are receiving this mail because: You are watching all bug changes.
