Help With Form Design and Large Text Boxes 1

[Auguy]

I'm looking for some advice on form design and the display of data. I have a record with 6-8 varchar fields that will contain anywhere from a few sentences to a few paragraphs of text. I could put each one in scrollable text box but that might limit the amount of text initially displayed because I would have to fit them all on one page. I could put each one on it's own tab page, but then you would only see one of the fields at a time. Also thought about using a grid with a large initial row size to display the text. Another option would be to have a sub form to display a larger version of the data field as the user clicks on the various fields. Just wondering how others have handled this type of issue.


Auguy
Sylvania/Toledo Ohio

 

[SgtJarrow]

What about putting them into a panel and setting the panel to be scrollable? The first few boxes may only be visible, but the whole area can be scrolled. You can even dock the panel in the form to give the impression that the whole form is scrollable.

What about putting them on the form with a shorter height, but if clicked on, the height of the control expands to see the whole text? This puts them all on the screen at once but you can see more details if needed.



=======================================
People think it must be fun to be a super genius, but they don't realize how hard it is to put up with all the idiots in the world. (Calvin from Calvin And Hobbs)

Robert L. Johnson III
CCNA, CCDA, MCSA, CNA, Net+, A+, CHDP
C#.NET Programmer

 

[Kliot]

How about having the 6-8 textboxes on the form displaying as much text as will fit and have your mousehover event display the tooltip with the full text of the textbox. This will give the user a quick view of all the textboxes and if they move the mouse over the textbox the full text will popup.

If the user wants to edit the text they can select the textbox and you can with code expand that textbox to a good working size to edit the text in, then you can downsize the textbox again when the user clicks outside of it.

 

[Auguy]

Thanks to both of you. I have played around with the panel idea before but didn't really finish it. Looks like I have some work to do.

Auguy
Sylvania/Toledo Ohio

 

[Auguy]

OK, the required data changed and now I need some more advice. This has also moved from a Windows to an ASP.net project. I now have 18-20 categories for each record with each category having anything from a few text or check boxes to a small checklist of items (5-10) with a column for a description and a column to enter a date or text. I like Robert’s idea of a scrolling panel to be able to see all of the data by scrolling, but not sure if that is the best approach with so many categories and having to scroll so much to see all of the data. I’m also not sure how to design the form for this layout, can I keep increasing the size of the form to accommodate all of the categories? I also thought about putting each category’s data into their own panel (or maybe a tab control) and having some sort of navigation control (menu?) on the left side of the page for the user to click to display the appropriate data. Would that be a good fit for the tab control on an ASP.net page? Maybe I need a different page for each one. As you can see, I need some help.

Auguy
Sylvania/Toledo Ohio

 

[SgtJarrow]

OK...maybe not the simpliest method...or maybe it is depending on your viewpoint, but here is what I would do.

I would look to create a custom UserControl for each of the different "categories". Each of these UserControls would have the necessary controls on it to display the information for that category. I would also create a corresponding class for each of the categories that contains all the fields for that category. The UserControl would have a public property that takes the class object and the Get for that property would use the passed object to fill in the appropriate fields/controls on the UserControl.

Then my ASP page would then determine which of the UserControls it needs to put on the page, instantiate the UserControl, instantiate the class object as appropriate and add that control to the page. Repeat as needed. Depending on how you want the page to look, you could also drop the UserControls onto a TabControl if you want that but you could stay with the same basic panel affect and just keep adding controls to the panel.

This approach is going to take A LOT more coding, but should provide you with a much more dynamic system for expansion as well as allow you to trouble shoot issues along the way as well.

And finally...If you are not aware ASP.NET coding is quite a bit different than Windows development. Be prepared to fight a bit with it until you learn the differences. be prepared for your development work to look all out of sorts on the screen during design time. You should (need) to leverage CSS for your layout and styling and not rely on the Visual Studio editor.

=======================================
People think it must be fun to be a super genius, but they don't realize how hard it is to put up with all the idiots in the world. (Calvin from Calvin And Hobbs)

Robert L. Johnson III
CCNA, CCDA, MCSA, CNA, Net+, A+, CHDP
C#.NET Programmer

 

[Auguy]

Thanks Robert. In the long haul I may use your suggestion. But I want to get something done to demo the project and then flush it out from there after final approval. Do you think I could use a tab control and put a panel on each tab to contain the necessary controls for each category and make the panels scrollable where needed?

Auguy
Sylvania/Toledo Ohio

 

[Auguy]

Another question if you don't mind. Because the data is so different from category to category, I'm trying to come up with a good table design. I could try and put all of this in one table but that would lead to some fields only being used by one or a few categories. I think the alternative is to have a table for each category and that doesn't sound like a lot of fun either.

Auguy
Sylvania/Toledo Ohio

 

[gpzcrasher]

You need a header and a detail table. The header contains all the data shared by all categories with a detail code ID. The detail table lists the data for each category that is unique.

--------------------------------
Rome did not create a great empire by having meetings, they did it by killing all those who opposed them.

 

[Auguy]

Yes I've done that a lot with things like an Invoice Header and Invoice Detail tables, But the kind of data I need to store are so widely different from category to category that I don't know if that will work. For example, I have some categories that have 5-10 items that need a date associated with them, another category needs several combobox selections, and another has both types of controls along with text boxes. Maybe you're right and I need to breakdown this data some more. Think I'll go over to the SQL forums and see what I can find.

Auguy
Sylvania/Toledo Ohio

 

[SgtJarrow]

You could most definitely just use the tab control, one tab for each category, add a panel to each tab and add the controls needed for each category to the appropriate panel. It will accomplish the same thing as the UserControl idea - it just won't be as scalable and you overall code will probably be a bit beefier.

In fact, I just completed a project proof-of-concept where I did just this. I built the whole page to display a large collection of data that did not include any UserControls. But the form looks like the requirements document states. I am currently awaiting approval on the form layout and once I have that, I will rework the page to use UserControls. The nice thing is that much of the code that is in the demo page can be used in the UserControls so you aren't really wasting time by doing your demo without them.

Now let's talk about your table design question... Personally, I would create a separate table for each of the different categories, include a unique identifier column in each table so you can match the records, and move on. While this results in more tables, it will help in a lot of different ways. One: if you need to refresh one category on your page, you can query the one table directly. This will result in faster returns and less to handle. Second: storage space - If you have one large table with x columns and you only fill y columns in a record, the unused columns will still result in used database space. It might not be much per record, but I think large and when you are talking a few million records, those empty columns can add up. Third: This ties into number two, because you indicate not all categories are used in all cases. So you will only need to populate the needed tables. Some tables might not have a record in them for each of your cases. This will also help to manage the size of your database. These suggestions seem to me to follow proper normalization rules. Some people might argue that it is easier to have one flat table and therefore only one small set of queries to read/write the records, but my answer to them is always scalability. How will you handle a new category?? Add more columns to your table? Instead, you should add a new table.

Of course, all these suggestions are based only on my personal experiences. Take that for what it is worth.

=======================================
People think it must be fun to be a super genius, but they don't realize how hard it is to put up with all the idiots in the world. (Calvin from Calvin And Hobbs)

Robert L. Johnson III
CCNA, CCDA, MCSA, CNA, Net+, A+, CHDP
C#.NET Programmer

 

[Auguy]

Thanks Robert, great food for thought.

Auguy
Sylvania/Toledo Ohio