A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I was able to solve it using MVC. It was quite logical, really. The behaviours I was putting in the forms simply didn't belong in a view. After futzing around for a while, I broke out the behaviours properly, and surpsise - it works. Here is the spike solution that I nutted out: http://users.bigpond.net.au/geoffbennett/ if you want to have a look.
Looks good Geoff! The only limitation I see in the UI is that the Save and Close buttons from PersonForm are fixed in position for any derived Form. This may restrict your UI layout options if you need more UI controls for additional data entry.
Monday, August 22, 2005
Thanks Brandon. The form is only a mock up. The actual UI I'm folding this into looks a lot more like Outlook. It has a save button on a toolbar at the top. The form I stuck together there is only to demonstrate that the visual inheritance works. :)
Here's the work-in-progress screen shot, http://users.bigpond.net.au/geoffbennett/mm.gif if you want to take a look at it.
The drop-down button thingies aren't finished yet. They work, but I need to display some defaults in them instead of the "Select >" text.
Visual Inheritance is to forms what implementation inheritance is to objects.
Ie, you can create a base form, like a list maintenance form, then inherit other forms from that. They get the controls and layout from the base form, along with any behaviours you have programmed in.
In my case, I created a base form that handled edit of "Name" records (read: contact), along with their address and contact information. Then, whenever I need another screen for editing entities based on the Name class, I inherit from this form and get all the special stuff automagically.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz