Global data storage structure, undo, et al

I created my app years ago when I didn’t really understand anything about programming and as such built it around a single main window (without thinking of dual screen setups or multiple documents open at the same time) and a single main listbox control in that window that stored all of the data.

I also used an old undo class that is tied to each parent window and the controls within them. This all still works but seriously limits the program’s scope of features and usability.

I would like to now make it more flexible by creating a global “virtual” data storage structure to store all of the user’s data and interface interactions in a session, so I can have multiple windows open, all referencing the same storage system with an undo system based on the user action, associated data, control and parent window etc.

Can anyone give me advice on how to best achieve:

a) a global storage structure
b) an undo system to interact with said structure
c) multiple documents open (accessing the storage structure) and switching between them in a memory efficient way


Hi Denise, I’m eager to see what responses you get, and hope I can offer a tidbit of help myself. This is a large bundle of questions by the way! :slight_smile:

I’d love to start with #A, “a global storage structure”. Can you tell me what you’re storing? Are these individual documents (like a MS Word.doc) or a collection of data - like ‘user name’ and ‘email address’? Perhaps you can paint a better picture of what your app does and more detail of what you’re hoping to store/retrieve.


Thanks for your response. The data structure needs to store everything about the user’s session.

So this includes text and style data for word processing stuff, image data, document/project details and notes, custom tags related to specified text, revision changes per user/author with time and date stamps, and all user interaction as per undo system.

The undo stuff would be cleared on app or session close but all the other data would be saved in a project file etc.

The project file is not the issue, it’s transferring all the data storage from the listbox on a window to a virtual structure independent of a window etc.

I’m really surprised nobody has commented on this with some suggestions since I had assumed it’s the first thing every developer has to consider before planning and building an app…how to store the data! Unless you’re obviously an idiot like me who just jumped in and started designing the interface and worked my way backwards!

So I’m thinking I need to draw some kind of diagram and plan the structure maybe? Perhaps start with a session module and each session module has properties and an array of project classes? And each project class has properties and other class arrays?

So for instance, I could create a new class to replicate the structure of the listbox I am trying to replace and each class property then holds what would have been the row/cell data…like a database but more flexible.

Does that sound like the right kind of starting point?

The question is too generic. Yes, you need to draw a diagram and plan the structure.

Every situation needs a different solution. In an older version of my app the settings (and there are a lot of them) were in the plist. This severely restricted what I could do in my app. A newer version uses an 8 table SQLite database. Designing that now makes bug fixing and adding new features so much more simple.

Do you know about MVC - model - view - controller? The windows should be largely independent of what your app does. If the user clicks on a button in a window the functionality isn’t implemented in the window but is delegated to the model which is responsible for executing the functionality in the correct class or group of classes. If you now change the window you simply need to re-route everything instead of designing everything new.

1 Like

Thanks Beatrix. Yes, that all makes sense.

I do know a little about MVC and have created a couple of basic ASP.NET MVC apps for my websites. This is why I know that moving forward I have to (in many ways) start from the ground up again in planning the next release so I can separate the data from within the main window listbox control (and multiple global modules) and then access it from a bird’s eye view and send it to the UI wherever I want.

I think I’ll need to plan the diagram first and once that makes sense try and link an undo system to it and then a multiple document/project system to that etc.

Got a feeling this is going to be a 2 year job so I’m gonna need a lot of coffee…and patience!

1 Like

I’m not certain how to send you coffee via the Forum, but there’s an enormous supply of patient people here :slight_smile:

1 Like