On Jun 14, 1:58*pm, "Cor Ligthert[MVP]" <notmyfirstn...@planet.nl>
wrote:
No, they don't do the same thing at all. One loop is within the other.
Yea, but in my idea is the one inside the other doing the same loop
completely again
Cor
@Everyone
Thanks for everyone's input.
Yes, it does look a little ridiculous looping through itself, but here
is the situation. I have a list of recipes that have been
"produced" (i.e. made by people each day). Let's say, today the
restaurant has made 32 Qt's of Spicy BBQ Sauce. One of the
ingredients of Spicy BBQ sauce is just plain BBQ Sauce. BBQ sauce is
also in the list because 10 QT's of it were made for other reasons.
So I need to loop through the list and find any items that have
ingredients that are also on the same list and then add the right
amount to them, so I know the total made.
In the end, I used something very similar to what i posted, it seems
to working fine, list total count is about 500 and won't creep to much
higher than that in the foreseeable future.
@Tom Shelton
I use the For... Next instead of For Each for performance sake,
although I agree it's probably not much to worry about. As for the
referencing of the count outside of the loop, that's there for legacy
sake, and will get tossed during the next big iteration when i have
time to replace all of them, for now I like to keep the code
consistent.
@Family Tree Mike
Exactly. You seem to have hit the nail on the head about what the
code does. The biggest problem is that some ingredients are in
mutliple recipes. And those recipes can also be ingredients in other
recipes. There is some pretty deep nesting involved, nearly 4 levels
in some places. This increases the complexity of the loops and does
indeed change the .ProductionOut values quite often in the middle of
the loop.