I’m trying to implement this structure for use with my tool I’m making. I would like to organize all the data that the program uses via data registration. I’ve been told that a std::map would be a good way to go on this one. But I’ve never uses a std::map. I’ve read about them, but I don’t think I need to deal with all this overhead just for an object-variable registration system. Basically, my plan is this, when the program I’m making requests an object be created, it is allocated and registered. All the registration is managed wit hone data structure. So this means that each child window is my MDI application can access data from different documents. This probably wouldn’t happen because one document doesn’t contain any information about what another document has. Once a document is destroyed, each object that it created and registered is also destroyed. So I may change the data registry from being one global instance to one local instance per-document. I would like my data registered so other components may have access to this data with out having to directly deal with the document architecture. Instead, an event is posted (in some form or another) that requests operations to be executed on some data. The document architecture would be the sender and the components or tools with in the application would be the receiver. The register is invoked for a reference that will be passed to the component by the document. This way, I don’t have to worry about using accessory methods of the document. I use the information received by the register to access and manipulate the data it’s self. The register plays the middle man. The document creates and registers the data objects with the register. When ever a request is made for the data to be manipulated, the document requests the object from the registry and passes this information along with flag or message identifier depicting the operation to be carried out on this data. While the application’s editing components receive this message and manipulate the data. The components are aware of what data to be manipulated from the information received through the message. The document is aware of what objects need to be manipulated from requesting the information from the registry. If the requested object is not present, then the operation can’t be carried out. Other wise the information about the objects size, physical memory location and identities are returned to the document. I’m having problems implementing data registration system this on my own. My theory is to use a linked list that contains special nodes. The nodes have special members that describe the variable being registered is and where it is located to in memory. My node looks like this: I only use a single linked list because I will only be traversing the list one when I search for an item. The dwID and lpszName parameters refer to special identities that are used when searching for an item.

Sounds like a fairly well thought-out design. I'd suggest grabbing some large pieces of paper and start sketching.

The main problems I’m having are the complexity. I hoped that I would be able to handle this architecture through a regular data structure, say linked-list. What I’m really worried about is the document and components cooperating. I guess I need to find where the most likely errors would occur and protect against them.

My architecture is laid out into several groups: Document, Register, and Component. The document group deals with the GUI aspects as well as registering and transferring information. The register group primarily deals with allocating / deleting and registering data objects. The component group handles the manipulating of all the data. This group is the only group that has any thing “real” to do this data manipulation. The other two are just merrily data presentation and organization.

The data the documents uses is allocated and registered. It is fine that the document creates and registers objects through the methods. But what about viewing the data? If I use a comb box, then the data for specific things are kept with in its list. The same would also apply to other controls such as trees and list boxes. I seems very foolish to me to use the information left in those controls as a means to access data from the register through the document.

So a steady stream needs to be kept between all three groups. I was contemplating about adding another peace to the architecture that all three groups communicate through. In other words, I need a small inner software network or message processing system. But that doesn’t change much from what I already have. What I’m really trying to accomplish with the document group to do is not let them have any clue to what is being stored or retrieved. The document’s can not have any data members pointing to registered variables.

This is where I’m stumped! How will the document group work with data that it doesn’t know exists. The document can create variables and register variables but it will contain not instances of them in its implementation. So my best solution is to organize the registered data objects. When ever an object is registered, it must have a name and identifier. This sets it apart from other objects of the same type in the registry. Next, when the document request information from the register, it must provide the data object type (the identifier) and the name. I think the phrase-“The blind leading the blind” suits this very well.

My main problem is: How will the document know what information to request from the register? Once I figure this out, I believe I will have quite the application architecture that could be easily extended to include much, much more functionality. Such as, the support for user defined plug-ins and components.


EDIT: I think I should change the lpObjPtr to a template instead

If the data objects are registered local for each document then perhaps I could use a special registration for each GUI components data. Pretty much, it’s just like a state machine. The document provides the first initial transaction. This transaction is then sent to the register that reports information back to the document. The document then sends the information received to the component.

I guess what I really need to do is classify data with components and document interfaces. For example: a dialog or set of controls is used to represent the data being manipulated. The dialog is a part of the document group, so it requests information to be loaded into it’s display. I could use this information to aid in the processing of the data. When an interface such as a dialog or set of controls requests data from the register, I could make a list of every data transaction received by the dialog. It is the dialogs responsibility to send the information receive the components to be manipulated. Just as I said before.

So If I keep a record of all the data transactions, then all a document interface would have to do is request data, set flags for manipulating it and send it to the components. Man, this is getting out of hand. I feel like I’m going no where whit this because I can’t figure it out. I know I can figure this out and I will!

I think I got his figured out. The behavior I’m trying to imitate is something very similar to LightWave. LightWave uses a type of object registration. The objects that are in question are the objects being manipulation are the objects that are selected. If an operation is to be performed, it is performed on the selected objects. If no objects are selected, the all selectable objects are affected. If a document interface is requesting a data object that is not present, then the operation fails. LightWave uses a message box or read only edit box to show these message to the user depending on the warning mode it is in

So in order for the application to perform task between the document, registry, and component interfaces there must be a middle man. The middle man is the objects that are going to be manipulated. The objects selected are placed in a special area of the registry or hey are marked with a flag specifying (this object is being manipulated). Each type an object is selected a selected object count variable is updated accordingly to the number of objects selected. A value of zero represents no objects selected and there for, all objects are affected by the components procedures. So the document interface will request information from the register about objects. The register returns the information about the selected objects. If a document interface is used and the data objects it manipulates do not exist, an error is returns-object(s) do not exits.

So that is the answer I was looking for! I knew I would be able to figure this out. Now I just need to develop a good sturdy framework. I think all the registered objects should be derived from an abstract base object or template. This way, it will be easy for me to code the fundamental data objects that are manipulated. All I would have to do is derive from the base class and encapsulate all the functionality I need for those objects. When the document interface request information about data objects, it receives a pointer to the first object being selected or -1 for signaling no objects are selected and NULL if no objects of that type exist.

Data Object Registry System Design

By Matthew R. Erdman


Document / Registration / Component Interfaces:
The data object registry system works with a fundamental type known as the CRegObject. The CRegObject is a base class that other elements are derived from in the environment. In order for an object to be registered, it must be a child class of the CRegObject class.

The CRegObject contains private data members that detail the objects state, type, and identity. There may be more then one object of the same type registered, for instance: an array of vertices. Each vertex would have a type vertex and have a unique identity. A common identity is the index number of where the object lies in the array. The state of the object depicts weather the object has focus or not. Only objects with focus can be manipulated through the components tools. If no objects have focus, then all objects are affected by the components tools.

Each time an object is created with the registry, its type, identity and state are initially set. The objects type is set to the type of object being instantiated where as the identity would be the index number of an array of objects the same type as this one. The object is initially instantiated with focus.

When the document interface request that an operation be carried out on some data, it request information from the register about the type of data that will be manipulated. If the data exists, a pointer to the first occurrence of where the data lies with focus begins in the array. The document interface prepares the data for editing by flagging the operations to be executed. Then the data is sent to the component interface where it is translated and send to the proper procedures. Each component manipulates the data objects in a particular manner. It is the document interface’s responsibility to send the information on what type of manipulating should occur.

The document interface and the component interface both act similar with the register. They both request information on data objects that are to be manipulated. The component interface is the only interface that has any real direct access to the data objects. As you can see, the registry is like big warehouse that stores items of all sorts. The document interface is like a manager of that warehouse that asks information about the current items in stock and weather to distress (remove) any items. The component interface is what uses these items for some benefit. Keep in mind, neither interface can work with data objects that do not exists, so a solution is needed to handle this situation.

In a situation where the date objects being requested does not exist, and error is sent back to the caller. For this information, there needs to be at least three different return values for a call to the register. The register must notify the caller of the following circumstances: The type of object doesn’t exist, List of objects in focus, and No objects in focus (affects all objects in the array). All of these states must be handled properly by both the document and component interface.

Data Operations State Machine:
When the document transaction occurs between the document and registry, data is sent to the components for manipulating. The component responsible for manipulating the data is selected or enabled by the user. A component such as scaling, translating, or rotating is enabled by the user. A component must be enabled in order for be used. A component is enabled by a document interface event. This even occurs when the user typically clicks a button to enable the feature the component provides. When the data transactions occur, the data received by the register from the document is sent to this component. The component then evaluates the data and performs the requested operations. The component evaluates the data received so that the data being manipulated is clearly the data that should be manipulated. An example of this would be a component that creates polygons. There document does sent information about the vertices to the component, but the component only creates three point polygons. If the document sends less then or more then three vertices, then the component must evaluate the data to ensure proper execution editing. In the first case, the component would flag an error because at least three or more vertices are required to create a polygon.

Only one component may be enabled at one time depending on its purpose. If a vertex editing component (translation in this case) has already been selected and another component (rotation) has been selected, the translation component is disabled via a call to GetEnabledComponent()->Disable(). This happens to unsure that no two components are manipulating the same data at the same time. Undesired or unexpected results could occur if this were to be aloud.

I think what all this boils down to is a database. I need a database that handles multiple sets of data. The document and component interfaces work with the database. The document interface has read-only access to the database, where as the components have read and write access to the database. All the data sets will probably be double-linked list.

The only real burden is performing the transactions between all of them. A lot of the errors that could occur could be avoided by simple using the selection process I spoke of.

I’m sorry if I made things sound overly complex. I have a habit of doing that. I guess I was just trying to explain all the details of what I’m doing, while avoiding the simplicity of what I was describing and trying to accomplish.