Hello!

First of all, thanks for all the work you put into this awesome debugger.

The only thing I am missing is a quick way to watch the contents of my arrays. I use super simple array/string structs that consist of a size and a data pointer. Of course, doing a watch like "array.data, array.size" works, but if I want to see something like an array of arrays it gets really cumbersome.

Hopefully it can be added without adding much complexity.

Thanks a lot!

We would need some way to describe to Remedy how a type coming from a particular module would map to an array type (i.e., what field is used for data and what field specifies the element count). Will need to think about how the UI would look for this but, like you said, would definitely be doable.

Thanks for the suggestion!

I can think of a simple way to do this with regex. You could make a rule for all types whose name match a given expression, and then have another one for what the format would be.

Example for arrays:

• Name exp: "Array<.*>" or "Array_.*"
• Watch exp: "(1).data, (1).size"

Strings:

• Name exp: "String"
• Watch exp: "(1).base, str (1).size"

Group (1) here would be the expression that was originally in the watch.

This could easily be combined with the new structure of arrays format for awesome results.

Maybe not even regex, just wildstar to match type names and some way of referring to the watch expression (__exp?) when replacing, might be enough.

I think this would be a good enough replacement for natvis in my day to day debugging.

Hi I just wanted to upvote this feature. Ideally I'd like to have a file in my project like this (e.g. in the same directory as the .exe) describing how to locate the data pointer and size for each struct. Just base pointer and size (and maybe end pointer) support would improve display of common containers like std::vector and std::string (and custom variants) enormously.

Lot of folks have asked for natvis support which would cover this, I believe. Another solution proposed by Casey can be found at https://github.com/x13pixels/remedybg-issues/issues/113

Natvis is kind of cumbersome to use (I've written a few for our internal custom types, like visualizing a MD5 as a string of 32 hex characters instead of 16 ASCII characters), but some large projects like the Unreal Engine (which is very painful to debug with Visual Studio because it tends to crash the debugger when tracing complicated expressions with many constructors, macros and templates...) come with natvis already for all the internal types defined by the engine.

If RemedyBG does not support natvis, that basically means having to rewrite all these.

If you manage to get your debugger able to survive a 30 minute session of tracing Unreal code, that would make it in a league by itself :)

Natvis would indeed cover this. I just figured it's a complex thing to support and was thinking of a simpler thing that would solve the problem :)

But yeah, albeit more complicated, natvis would be more powerful and, as pointed out above, makes it easier to use already existing stuff.

I also agree that natvis support (even partially) would be great, I already have a bunch of custom formatters for my types and many libraries come with natvis files.

Casey's solution would also be neat. I already have serializers for many of my types which I could plug directly into the debugger. Probably also still need something like natvis for containers though, because the debugger needs to be able to dynamically expand and scroll the elements, and they also have templated types so it would be hard to have a symbol in the .exe for every single type.

Relatedly, is support for an "Immediate Window" like in visual studio planned? It can be very helpful sometimes to just manually call serializer functions from the immediate window.