tags:

views:

7

answers:

0

In my application, I have a large structure of many objects and children. I'm designing a set of property sheets that you can open to inspect a specific object (and it's base classes) so you can modify them directly.

What's the best strategy for populating these dialogs? The current design is to test the current object on dialog open, and init the expected property sheets for the objects that you wish to inspect. In each property sheet's WM_INITDIALOG, it has specific code to get/set each member variable.

The potential problem I see here is that everything is hard coded in a single source file that could potentially get quite large. I'm considering offloading the dialog population to each individual object, but I wonder if tying UI code into our back-end object code is a wise idea. Future maintainers would instead need to visit several different objects living in several different source files instead of a single source file.

Any best practices that I can benefit from here? I'm not sure where to start. I'm fine with continuing with the current design, but since I'm in the position to rearchitect how these dialogs interact with our objects, I'd like to make the right choice here.