You took what was meant as a code fragment for demonstration purposes and put it to work without trying to understand it. First off, you have the variables "field3" and "field4" nowhere assigned, so chances are they don't hold what they are supposed to hold.

Second, i just found a typo in the code, which you also haven't noticed:

output=sprintf("%s %s / %s:", output, field1, field2)

should of course be

output=sprintf("%s %s / %s:", output, field2, field3)

but as it was just to show you the mechanism you could write that completely different anyways. I didn't care if the 10 blanks i put in if the two fields were empty are really correct, maybe it's more or less. The whole purpose of the if()-statement is: "if the one field AND the other field is empty, we put blanks at the end of the output string, otherwise the content of the first field, then a slash, then the second field". THIS was, what the code tried to show you. The blanks are just there to maintain the column format of the output. Possible output should like:

Code:

field1="A" or empty
field2="B" or empty

... A/B ...  // fields non-empty - print them with a "/" in between
...    ...  // fields empty - print an equal amount of spaces

So, go over your code again, remove any output which is just "passed through" (all the fields which are just read and written without any modification) and analyze the output of the stripped-down program. Find out, where the program produces the desired results and where it doesn't. Change it accordingly. Only when you have solved the tricky parts put in the other fields again, one by one. Let the program run in the different stages of development to see if it still works the way you want it to work.

By making little steps instead of giant leaps between runs you can always isolate occurring problems as they are introduced. If you write 10 lines and they do what the should, then add another 5 lines and the program doesn't do what it should any more you will *know* already that the problem is within the 5 lines last written.

There is an old roman proverb, "divide et impera" (set apart and rule). The same is true for programming. Nobody is able to analyze, write or conceive huge amounts of code at once, make them into small portions and study one after the other.

It is like solving the problem "build a house": don't try to build a house, try to build a wall first, as a house hast four walls and a roof. Don't even try to build a wall, try to reduce building the wall to solving the problem "lay one brick onto the other" - now, *this* is a manageable problem, which is easily solved, so "build a wall" is a long succession of "lay one brick onto the other"-problems. From there, develop the next step, say "how to combine 2 walls to form an edge", etc., etc., until you have a "build a house"-program, which is now a large array of little solveable problems, which are solved separately.

bakunin