Behrooz, Thanks for posting.
There is always more than one way to do things, so when anyone tells you one way, it is likely not the only way. YOU must decide which of all of these is "best". My first suggestion would be to understand some things about your project, calling them *Requirements*, and write them down. Starting from the top, ask (and answer) yourself questions about the process (task), looking for things that would mess things up if you made assumptions. For example: - Will the file always be in the same place? - Will the file always be just as you showed it, with the *fields* or rows in the exact order you show? - What *precisely* does "*extract those parts to another program*" mean? - In what way(s) do you want to check your program's progress? - Is your program going to be a "console" program, or visual, with what VS calls *forms*) (always hated that term)? - Does your program need to verify, or *prove* that it grabbed, and submitted, the right data? - What other criteria are there? For example, will a file with *lots* of rows like the above in it need to be processed? Give these, and others you think of, a bit of time, writing them all down as organized as you can, top to bottom. From *Requirements* come * Specifications*. Specifications are sometimes called "speeds & feeds". This is just a fancy way of saying that you are defining how fast, what version, language, operating system, etc. the program will operate as/with. This kind of thing looks like the answers to questions like: - What OS do each of the programs run on? - What programming language requirements are there? - What input file types will be used? How will my main program gather those files? - What to do with the output? - Do I write a logging facility to monitor my program's progress? Where would it write to? What would it write? - What requirements do I have with regard to connectivity? Will the other program be on another computer? How do I access that computer? - Will firewalls be a problem? - If this is a pilot or PoC, will the production system be identical to the staging one? If not, how? - ...and all the other questions that will put a fine focus on what your program will need to do, and look like, when complete. The next thing (in my universe) is *Design*. You'll probably recall someone in the past talking about "Pseudo Code", and this is where you'd usually write that (nothing but block diagrams with arrows!). I won't bore you further, but I've already written a lot on this process, which works just as well for software I write as it does for Projects and other tasks. You can find that here<http://blog.atcp.us/2008/10/01/pats-5-ds-well-6-really-of-engagements/#more-511> . Hope that at least gets you started. If you want a quick & dirty answer instead: just load the file as elements of an array. pat :) -- You received this message because you are subscribed to the Google Groups "DotNetDevelopment, VB.NET, C# .NET, ADO.NET, ASP.NET, XML, XML Web Services,.NET Remoting" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dotnetdevelopment?hl=en?hl=en or visit the group website at http://megasolutions.net
