Customer wants multi state form (View\edit all\edit part)

We have a customer solution written in another language that I am working on a conversion plan for.

The customer is accustomed to a muli-state form as commonly seen in data entry applications. For example a form may contain several groupings of data as described below.

Customer Review Screen:
Name\Address
Contact Information (email, phone, fax, mobile, etc...)

When the customer review screen is initially loaded it displays the data in "read-only" mode. Then based off of the keystrokes or buttons used the customer can choose to go into edit mode for either the name\address or contact information sections.

If the data was only to be via text boxes this would be an easy task. However, there are many other controls in use in this screen that do not have a read only attribute.

Setting the parts to disabled is not an option because it severely affects the readability of the controls on the form.

What would be your suggestions for managing this in vb.net 2010.

I had considered putting an extra text box on the form outside the bounds of the displayable area that I would force focus to if the form is not in an edit mode, then use control arrays to manage which parts are editable in certain situations. However, on paper I was having issues with a way to properly manage the loss of focus to a part, or the loss of focus to another form.

Not looking to have it coded for me or anything like that, just wanting to get other people's opinions and theories of the best way to manage these types of screens.

tia.

What controls are you using? Most have some way of setting the control to read only mode.

Quote:

---

Originally Posted by wakawaka

What controls are you using? Most have some way of setting the control to read only mode.

---

Combo boxes (Drop Down List Style Primarily), Radio & Check Boxes, Masked & Regular text boxes. Those would be the primary ones that I will be using on 85%+ of the forms in question.

Well, TextBoxes have a ReadOnly property so that's them sorted. Checkboxes you can use as ThreeState and set to indeterminate. Radio Buttons set to unchecked and Comboboxes simply ignore selections.

Having said that, I really don't see any practical difference between a read only dialog where certain entries cause editing to be possible and a screen where everything is editable at all times. In both cases you have to take certain actions to put yourself in editing mode for a particular control and can only edit one 'area' at a time. That is the very nature of OOP, after all. Fair enuff if you have one form/page for reading information and a separate one for input/editing but for a single, all-purpose screen I just don't see what is to be gained.

Back in my VB6 days I would use LABELS (that looked like textboxes) to represent all the TEXT and move a hidden textbox onto that label for editing purposes. So in effect each piece of DATA is in read-only mode by default.

I allowed for a textbox or a combobox to be moved onto the label.

This also allowed for editing of msflexgrid's - something that wasn't available anyway.

Painful code to write in VB6 a decade ago...

Just an idea...

Quote:

---

Originally Posted by dunfiddlin

Having said that, I really don't see any practical difference between a read only dialog where certain entries cause editing to be possible and a screen where everything is editable at all times. In both cases you have to take certain actions to put yourself in editing mode for a particular control and can only edit one 'area' at a time. That is the very nature of OOP, after all. Fair enuff if you have one form/page for reading information and a separate one for input/editing but for a single, all-purpose screen I just don't see what is to be gained.

---

In this situation the foundation behind the application was originally from the CA-Clipper days. During that time it was common place to let the client review the information, then have to take an extra step to edit parts of that information. This was to ensure a user is aware that they are editing data as well as what was edited specifically.

In the sector that this application runs it is a key part of the program to ensure that when the user hits "save" the amount of possibly erroneously modified data is minimized.

I had considered have a "view" only form an having sub forms that contain only the data to be edited, however the downside to that was the necessity to modify multiple forms when the data requested changes. (i.e. adding a new field).

In the end that may just be the nature of the beast in this situation.

Another option, I guess, would be to created inherited controls with custom "read only" properties to handle the state changes.

Thank you for your advice on the subject. There are many ways one can tackle this request, which is why I was asking for ideas as to how individuals would make this implementation if they were tasked with it.

How about putting up panels - see-through - over the data entry fields - so that clicking on the element is not possible. Must be some kind of toolbox item that will work that way - actually I think I've used it in some app before...

If you could trap the click on these ui elements you could even tell the user to click MODIFY first (or whatever button you have for that).

That is a quite interesting idea. But I can't think of any control that would allow that. I will take a look at that later tonight and see what I can find. Thank you for your reply.

Lots of great interesting input. Thanks to everyone.

Here's a link on getting a transparent panel

http://www.fsmpi.uni-bayreuth.de/~du...n-net/108.html

Also - I wonder if after your form paints with the initial load of data - if you could in fact take a picture of it and draw that in a picture box - and basically put up a fake "form" of data while the user is in read-only mode...