Greg is right (hey, Greg!) about the combobox.  I use that to try to prompt the user into proper action.  For some reason, a blank combobox is usually left blank.

Bill

Thanks for the screenshot, it is much clear.  Now I see what you meant, believe or not I have done this kind of design in Visual FoxPro long, long time ago and I think I will follow the page tabs even though the relation of my child tables are not to the same parent table, but guess will look better than the plain ListView control and will give me a chance to incorporate any new data.

One question, how do you get the combobox to display the message [Select an Address] for NULL/empty values? 

Talk to you later,
Bill

Thanks a lot for the reply and the screenshot.

If you don't mind, could you please email me this screenshot since it did not come up nice in the forum so I can have a better look.

Also you are right about future expanding, this is something that will never end

I have struggled with similar UI presentation with my customer maintenance window.

I opted to utilize the tab control.  This allowed the most footprint for the window.  There are seven related chunks of data that I am displaying on each customer record (notes, addresses, contacts, quotes, orders, shipments and invoices).  That is a lot of data to squeeze into an itty-bitty living space.  There are far more than seven related tables, however.  Each tab may reference several other tables to get the data presented. 

In addition, I also use a modal window when adding a note, address, or contact.  The rest are view only, but a double-click on the appropriate line item (and with the proper authorization) will open a maintenance window for the object.

It is all quite fast.  Quite painless to put together.

The main reason that I bring this up is the possibility that your interface will grow.  For example, what if the user desired to see a list of dependents.  The way you have it structured, the addition will put you into a tailspin--where do you fit another group box in?  For a tab control...just add another tab and fill it in with the data that you need.

I am still working on the customer maintenance window.  Always will.  Users keep coming up with good ideas to implement.

HTH,
Bill

Larry Tucker (04/22/2008)

---

By "training issue", I meant training your users! (not your training   )  The "flat" presentation in your example is clean and may be easily understood by them once they've had enough training.

Well, I also need training

Once again, thanks for your input and I will show the final screenshot when ready, but before that some other posting may be needed from me.

By "training issue", I meant training your users! (not your training   )  The "flat" presentation in your example is clean and may be easily understood by them once they've had enough training.  

If this isn't enough for them to understand the parent -> child relationships, maybe there are some visual cues you could add to the form.  I don't know, maybe aligning the list boxes vertically (parent above the child) and indenting each child level a little.   Maybe some way to use a mini treeview on the page to manage the children.  Not sure.

Good luck

Larry

As you know in all projects there is one main form which is key to running the business   I am at that stage now with this project.  The good thing with all this new SF/.NET learning is that I had this application done at 70% in a Visual ProMatrix project.  In order to get into the SF learning process I decided to re-start the project in SF which will take me longer to finish but worth the time invested to learn SF.

The original form was created in VPM using the RelatedPages class with a Page Tab for each table.  I am not looking to re-create that type of form class in .NET, with the new tools available I would like my application and forms to look more fresh and modern and that is why I am looking for ideas.

I though of using a TreeView control, but frankly I could not find a way to accommodate that design in my mind and believe that a TreeView will look better with all the Insured Customers records and not just the one the user may want to work with, and since this is a new discconected concept with SQL2005 database, I don't think will be a good idea to load all customer records at once.

Honestly, I like both ideas In this case each ListView will open up a modal form with the detail data for each, and I will have to control the toolbar button state of each ListView based on the records in the parent BOs. It will not be easy, but at least with the new ListView enhancement in version 1.6.5.1 it will make this task a bit easier, of course only if I would have a mini MaintenanceForm I could use, then that would be much better "sorry Trent! I could not resist to ask for more"

Yes it is!!!! I am new to .NET & SF and it takes time to get comfortable with new technology, in VPM I was in my zone of comfort all the time with all the tools I needed for any project already here, now I am buying all kind of tools like icons, DevExpress, the Training class, etc. and all is in a fast pace, not to mention the $$$$$ invested.

I'll jump in with my 2 cents.  (I'm also pondering the same types of design / presentation issues).

I think your form looks good:  crisp and uncluttered. 

The challenge is how to represent the hierarchical nature of the related tables on a "flat" surface (single page).  On your example, I don't think there is a visual clue or indicator for the user to know this, (unless the green arrows are intended to stay in the final design).  It may not be clear that selecting a new record in one box completely refreshes all the child boxes, so the user may feel that something mysterious is happening or that data is disappearing. 

It seems the most common way to represent hierarchical structures is a tree view:  perhaps an "Explorer panel" type page with tree on the left and edit panels on the right.  But I've had users how haven't known how to expand levels or pan through a tree view, and thus have missed lower level items.

The other way I've done this in VFP/VPM was with a "related pages" form.   Here, you'd have 4 tabs, one for each table.  As the user clicks on each tab, it offers only the records subset by the previously selected parent (along with carrying the parent title or identifier over as a readonly field).  On each page, you can have either a grid or single page w/navigation.  The benefit of this is that the user gets some physical clue of "drilling down" into the child records by actually choosing the "deeper" tabs. 

One drawback of both the tree and related page approaches is that it is hard to see what is down in the child records. You don't see them all at once, without drilling down to them.

The only other way I can think of is progressively opening separate child forms, each limited to the records related to the previous parent.  I've tried this a bit in SF/.NET using a SF maintenance type form for the current level with separate fields for editing and having a grid visible showing the immediate related child records.   Selecting a child record in the grid then opens the same type of form, but this time at the child level with its grid showing the next child level (overall grandchild).  This works and feels consistent, but I'm not sure I like having multiple forms floating around trying to repesent the hierarchy. 

It may come down to which matters most to you:  clearly representing the hierarchical structure, or seeing data from all levels at once.  It also may be a training issue:  once someone is familiar with the hidden relationships between the boxes in your example, they may be comfortable with the processes going on behind the scenes that cause records to appear and disappear in one box based on something happening in another.

HTH.  Let us know what you come up with.

-- Larry