Adding a struct type with editor

[jahorta]

This is an attempt to introduce a new struct type. This type would allow the user to define a block of memory using a list of entries with any type. Then the struct would automatically be created when assigned to a memory watch. This includes a number of new features to accomplish this:

• A struct definition class (StructDef) which holds the definition of a struct.

  • This contains a name, length, and list of fields

• A struct field definition class (FieldDef) which holds the field information.

  • The offset within the struct. These are generated based on the size of the fields before it.
  • the field's size within the struct
  • a MemWatchEntry defining the type of the field.
    • All current types are supported, including structs and pointers to structs. For these last two, the inter-struct references are stored in case of name or field changes.
    • The only restrictions are that there can be no cyclic references to structs as it would make it impossible to determine the size of the struct. Pointers to structs do not have this restriction.
    • When editing the entry of a struct field, The DlgAddWatchEntry class ignores the address and preview.
  • Struct fields are currently checked for validity by making sure they do not overlap each other.

• A struct editor widget as a separate window to organize and edit struct definitions.

  • Tree-style organization to allow grouping of structs.
  • Struct definitions are identified using a "Namespace" created from combining group names and the struct name.
  • Struct definitions can be edited using the context menu. When editing a struct, its fields will appear in a tableview on the right. Since struct offsets are currently generated from the field definitions, the user can enter padding fields to get a field to the correct offset.
  • When editing a struct, a copy is made to edit. If a change has been made to a struct, the save button will be enabled. The state of this button is used to determine whether there are any unsaved changes on the current struct.

• The ability to select a struct in the DlgAddWatchEntry for memory watches.

  • A list of names is currently passed to the DlgAddWatchEntry to select from and a simple combo box is shown to the user to select a struct from.

• The automatic creation and deletion of memory watches using struct definitions as a template.

  • When a mem watch node has a struct type entry, if its definition is known it will get a placeholder watch node as a child.
  • If the node is expanded, the placeholder node will be deleted and the fields of the struct definition will be copied as new child nodes under the struct node.
  • If a node is collapsed, the child nodes will be removed and a placeholder node will be added again.

• Saving and loading the struct tree to/from the settings on application start and close.

• Saving and loading any currently used struct definitions to/from a memory watch file.

  • When loading from a file, any namespace collisions are presented to the user to resolve. If a new name is needed, it currently just auto-generates one.

This is a draft pull request while I do some testing, bug fixing, and refactoring, but has most of the features fully implemented, so I wanted some feedback. I am open to any feedback, but am wondering about a few design choices in particular:

• In the mem watcher, structs are expandable, so if a struct type with a known struct definition is found it will be given a "placeholder" child to allow the user to expand the struct. At the moment, the fields of the struct will be created on expansion and deleted on collapsing of the struct.

  1. I think the creation on expansion is necessary because the struct can handle pointers to its own type and in a situation where you have a doubly linked list you would have infinite generation if you try to generate everything since the next and previous pointers would form cycles.
  2. I am not sure if the deletion of the field entries on collapse of a node is necessary, or even good. The reason for this was that the hidden entries would take up memory and processing power on update that is not visible to the user which may eventually lead to problems, but the amount of memory that is taken by each entry is so small that I don't really see it being a problem. Also, since fields of a struct are deleted at the moment, expansion of any struct fields is lost, so the user would need to re-expand any nodes that they had open previously.

• I added an icon to identify structs in the mem watcher.

  1. Is this easy to see?
  2. Should there also be an icon for fields of a struct since they are not as flexible as a normal watch entry?

• Struct fields are currently checked to make sure that they do not overlap. This is not strictly necessary, and there is a case to be made for fields that may overlap (Unions, bitfields, etc.).

  1. Should the user be allowed to overlap struct fields?
  2. Should there be a checkbox for this?

[dreamsyntax]

This feature sounds great. Ill be trying some builds of this in the interim. Review is huge so it may be a while, even after you've fully completed it.

[dreamsyntax]

Hey there, I know this is WIP so I'm not expecting action on this, but when its closer to being finished, the commits will have to be sorted out:

[jahorta]

Definitely, I'll rebase the commits into a single commit before review.

[cristian64]

Definitely, I'll rebase the commits into a single commit before review.

...but notice that a single commit would be unwieldy from a code review point of view.

[jahorta]

Okay. I'm still pretty new to pull requests, how should I organize the commits so that they are easier to review?

[dreamsyntax]

For now just focus on your feature and when its done we can rediscuss. Its already an unmanageable amount of commits, so easiest scenario is squashing post completion