I never thought about doing a line break character. Funny, I have used that same logic when coding in vbscript. The idea of the grouping I thought about, I just had the feeling it would um... klunky??? Use up alot of form retail space? I thought about just using two physical rows for every line of detail history, with a blank row between them. Still kicking that around in the back of my head. Chuckle, to make this even more complicated. I plan on allowing them to select what they wish to see in the detail history. So, this will be a dynamic build of the view with regard to what is shown and what isn't. I think I'm going to just play with the different ways, to see what appears to work best. Thank you for your feed back, it gives me more to think about. And try to see what looks the best. Dan

I am currently developing an application for displaying history/statistics of a persons bowling games. I also am very new to vb.net, but have coded in a number of languages through out my IT carrier. What I am looking for is a suggestion on how to display multiple lines in a list box type of control for every history event there is. Example> "Date Bowled" "Name of Place Bowled" "Name of League" "Game Number" "Score of Game" "Lane # Bowled On" "Oil Pattern on lane" "Oil condition on lane" "Ball Used" "Surface of Ball" What I listed above would be 2 lines of information for every game played. This is a history listing, so there would be 1 to many of this information displayed. I looked at examples of groups in list view, but I don't think that would do it. And I just am not proficient enough in the various controls you can use on a form to know which would be the best for this type of displaying information. Any and all help is always appreciated. Thank you in advance. Dan

I consider COBOL a strong language for the purpose it was developed for. Moving and manipulating large amounts of data on a main frame without a gui interface. It was never intended for any other purpose then that. We could get into the finer points of how coding could and should have been done. Personally, I have not found a language that is as friendly and flexible as COBOL is when it comes to tables and the defining of them. But, that could be ignorance on my part of not knowing all the finite of other languages as I use to know COBOL. With regard to the copy statement, as much as you think it is repeated lines of code. The reason I always considered it an asset and not a liability is for the simple fact that I could look in any given line of code of any program, and know that this file/database was defined the same way. That the variables being used were the same everywhere. They were standard. I also knew that if this included definition went through the code review, that the data definitions were done correctly whereas I can't always count on that when each coder defines his own. But, you are correct. They are repeated blocks of code. Which again you are correct, would require recompile if they ever changed. Again, I apologize for being so thin skinned. Dan

Most programmers I met today only work from specs. They don't know how to think for themselves. Doesn't matter what language. They don't want to learn the buisness logic which they are coding for. They just want to do as they are told without trying to understand why they are doing it. They don't understand what the end product or their peace of the end product is spouse to do, how can they provide a valid product. Bad coders are bad coders. No matter what language. Dan

That's undisputable! A boss of mine teached me Cobol with this words: "Cobol has four instructions: READ, WRITE, MOVE, IF. Or at least, these are the ones you're going to use" I felt a little worried... (more about my boss, though) He never used the power of COBOL then. There was even in the beginnings much more powerful statements then that. Perform to ultimate levels, tables to ultimate levels, case statement. Long before VB ever thought of them. I have no simpathy for repeated blocks of code that do exactly the same thing ("Mantainability, whatever the heck is it?") Not to speak about the compiler/interpreter bugs: I know that even MS.NET has even more bugs, but it's a much younger environment whem compared to Cobol ones. If that is how you code, then your coding skills are bad. I never used repeated blocks of code. You don't have to if you know how to do structured programming. Sorry, that is coding skill that cause's repeatable blocks of code. Not the language. And with your OO abilities in COBOL, which have been there for years. You have made no point at all in this statement. None. That's totally false: id depends on the operating system you're running the Cobol interpreter, it's not a language feature: Cobols for Windows actually use [crap] gui. You (and I, for that matters) may like it or not, but people is accustomed to use Windows or Macintosh or Linux/XWindows software, not Unix System V Release command line interface based software. Cobol wasn't developed for winblows. It was developed for main fraim computers that push large volumes of transactions and data. I wouldn't use COBOL on any server, that isn't it's strong point. And for you to even sugest that shows how little you actualy understand WHY it was developed. By the way, ever hear of a database? IMS, DB2? Who use's flat files? Except in some type of interface to populate a database. Again, your coding skills are not making a very impresable showing right now. Dan

There's nothing that can be expressed easily in Cobol, as far as I remember. You quite obviously have no ability for simple things that work do you. I never had a problem in COBOL, and I don't have problems in other the other languages that I picked up when I moved on to other jobs. Cobol is simple, its powerful, and it doesn't use crap gui's that waist cycle, bandwidth power. Get a life, quit being a jealous cry baby. Dan

Yes, like knowing how to process mass volume transactions efficiently without crippling an operating system that has more important things to worry about then having some pretty boy programming language waisting its resources. Dan