Leaderboard

Access Violation is a generic error that is generated by the CPU itself when a code execution causes the CPU to access a memory address that the virtual memory manager does not recognize as being assigned to the current process. Often it is a NULL pointer that is referenced, but any badly initialized pointer can be the culprit. It simply means that something got corrupted in the application memory, but there is no way to determine how it happened from the access violation exception information alone.

This. For sure. I’ve been falling back to the MV/MVC architecture quite a bit recently. It. Just. Works. Some applications don’t even need a controller, hence the MV only option. I try to use either form when I can. Key point is the model doesn’t know anything about the views. It’s just an interface to which the views can get data. Used properly, none of the views need to know about other views, as far as they’re concerned it’s just itself and the model. This is how I like to see it happen: the model is some singleton resource, typically a data value reference. I try to keep the model passive. No actors or loops. If your model needs to do something in a loop, you’re already thinking about views that attach to the model. The model is the data interface and nothing more. The model will expose one or more subjects to which any number of views can subscribe. When a subject is changed the subscribers to that subject are notified of the change with some contextual information. For example, my model may have an ActiveItem property which can be altered. Some of my views care what this ActiveItem is so they subscribe as an observer to the property. When the ActiveItem is changed, they will be notified about it and be told directly via the notification what the new ActiveItem is. For some views this is all the information they need. Others may use the contextual data from the notification to further interrogate the model. It’s a nice mix of broadcasting small copies of contextual data by value, while large state information remains singular behind a shared resource. Each view only subscribes to what it needs and only copies what it needs to act. When I first started doing this I used to hard-code the notification mechanism, but found myself often creating brainless loops where the sole responsibility was to go translate one transport mechanism to another (convert a queue to a user event, for example). When going about this, do yourself a favor and abstract the subject/observer interface. The subject shouldn't care if the transport mechanism is a notifier, queue, user event, or some derived construct. Make the subject take an abstract class, and have the observer decide how it would best like to receive that notification. Is my observer an Actor? Fine, it will supply a concrete observer class that packages the notification into a message and shoots it off. Maybe my observer is a primitive UI loop? Fine, it will supply an observer that packages the notification into a user event. Maybe my observer is a remote object so we use a class which pushes notification over TCP/IP. You can change all this without any modification to the model or other views which already use the model.