Thread: Best way to approach building a document based on a series of check box selections?

Hello forum,

I did a search and couldn't find anything that seemed to address this issue. Hopefully someone can help.

I'm trying to build a program that would present the user (well...me) with a rather large list of various check boxes (and combo boxes, etc...but for sake of the question I'll limit it to check boxes) and the selections would not only need to be stored in some way so they could be reloaded, but also they would need to have the "data" used to build sentences.

For example, part of the form would have a checkbox list like:
Emotional Issues -
Emotion 1, Emotion 2...Emotion 40

Then, at the end of the form I would be able to save client, load client, or generate report. When doing the generate it would output something like:
"Client's first name reported having emotional disturbance in areas of 'Emotion 1', 'Emotion 4', and 'Emotion 12'."

There, of course, would be probably several hundred check boxes, combo boxes, etc. throughout this program building a rather complex "report" when it's all said and done. So where I am stumped in on the methodology or approach that would be best for getting, storing, retrieving, and outputting this information.

What do you all think?

Storing the data would be done in files on the hard drive or other storage medium. The files could be simple text files, more complex files that contain whole objects (like a patient's entire record), or relational data base files. A combination of all 3 is possible, and maybe there are other options I haven't learned myself. Which is "the best way" may not matter, since you're just learning, and I'm not sure anyone could say. The best way might include the most complex approach, and that wouldn't be a reasonable recommendation for a beginner, but all of the approaches I mentioned are reasonably self-taught, depending on how much time you have.

Creating the user interface and programming it to do what you want is likely more challenging than storing and retrieving the data, and we can't be sure of your readiness to tackle that part of it. I don't recommend you start with GUI programming at all but build a solid foundation of basic programming elements. If motivated, it won't take long. Without that solid foundation, you may follow the path of many eager but unready programmers who take on more than they can and leave disappointed and frustrated.

Once you're confident in programming basics that are common to all languages and then have some familiarity with OOP, I recommend you start with very simple GUI projects, say a couple components on a page, and explore getting those to work in a stepped approach from entering data, storing and retrieving data, and then generating a report from the entered/stored data. Using these very simple projects, explore the data storage and retrieval options I mentioned above to learn them and have that perspective from which to determine which you think will be helpful.

Along that journey, I think you'll develop an appreciation for and your own opinion of "the best way," and then when you're ready to tackle the project you have in mind, you'll be asking us more about programming your project than designing it.

What guide are you using for your study?

Originally Posted by GregBrannon

Storing the data would be done in files on the hard drive or other storage medium. The files could be simple text files, more complex files that contain whole objects (like a patient's entire record), or relational data base files. A combination of all 3 is possible, and maybe there are other options I haven't learned myself. Which is "the best way" may not matter, since you're just learning, and I'm not sure anyone could say. The best way might include the most complex approach, and that wouldn't be a reasonable recommendation for a beginner, but all of the approaches I mentioned are reasonably self-taught, depending on how much time you have.

Along that journey, I think you'll develop an appreciation for and your own opinion of "the best way," and then when you're ready to tackle the project you have in mind, you'll be asking us more about programming your project than designing it.

What guide are you using for your study?

Hi Greg,
Thank you for the reply. I understand what you are saying. I guess I was looking not so much for "coding" but more OOP programming logic. For example, when working with massive check box lists, it is better to use a multi-dimensional array to store the state of each check box so as to not make an individual variable for each one since that would get cumbersome and problematic. (I'm kind of just making this up right now...I barely know what a multi-dimensional array is beyond the one in Star Trek Voyager.

I'm confident I can figure out the coding if I can wrap my brain around the logic behind it.

Currently I'm using a combination of Head First Java the book and the video tutorials on TheNewBoston.org to learn/relearn. I took a C programming class in 1992 and Programming Fundamentals class in 1991. That knowledge is more or less gone. I also read the C# and Java in Easy Steps books a few years ago and in 2006 I took a beginner Java Programming class as an elective. In 2008 I even wrote a relatively competent program in C# to administer, score and interpret the NEO-PI-R psychological measure. However, I looked at that code the other day and I have no idea what I did or how I did it. So, if we take a neuropsychological view, all that information is still stored in my gray matter somewhere, but accessing that is a bit...well, a challenge. In many ways I feel like I'm starting over AGAIN (said with exasperation, not shouting). The syntax of Java...not hard. It's like learning a foreign language in many ways. I don't think that will be a major stumbling block for me. It really is just the logic of how to put it together in a way that is efficient and makes sense.

Hopefully that makes more sense as to what I'm asking. Any guidance would be appreciated of course.

. . . is better to use a multi-dimensional array to store the state of each check box . . .

No. Storing data in parallel arrays is not OOP and not manageable or easily maintained for data of any size.

In an OOP paradigm, objects are characterized by the data/properties/attributes specified by variables in that object's instance. The hundred or so checkbox values may be stored in instance variables for each object, perhaps in collections of some kind grouped logically in smaller numbers. Keep the collections simple so that they can be easily accessed for storage and retrieval of their contents.

IMO, understanding what OOP is, what it can do for you on a project like this, and what you need to know and do to take advantage of OOP are what you should be focusing on while you recover basic language skills and tools. Keep studying, reconnecting those neurons, considering what you may do with the recovered skills on this new project, and the design will become more clear with fluency and confidence. (Remember looking at that old code as a foreign language from a different lifetime when writing the new code and COMMENT the new code.) You'll pick it back up rather quickly. Code efficiency and clarity will come with practice, confidence, and use of consistent coding practices. Practice, practice, practice.

Originally Posted by GregBrannon

Practice, practice, practice.

I ended up having to hire someone to do it. Luckily he didn't charge much to make the basic shell that I could build on. On the other hand, I did find a great video training series on Object Oriented Programming from AppDev which is helping me understand the concepts behind OOP which I hope will make learning an OOP language like Java easier. I also ordered the 24 Hour Java 7 book since it seems to cover GUI's a little better than Head First Java.

Just thought I would post this for others on the teach yourself route who might be interested in these options.