I'm always tempted to say, at times like this, "If I write your code, will you send me your paycheck?"
So, I'll get you started, but you need to do most of the work yourself, otherwise you'll never learn anymore, will you!
So here's a spreadsheet with some skeleton code:
You'll notice that the first thing I've done is to put all of the very specific cell addresses into constants. THis avoids what are called, in the trade, 'magic numbers'. If you have a magic number and you need to change it, you need to be able to distingish between one meaning of the magic number (say 11) and another. At one time it might mean the number of players on the field for a soccer team, and at another, it might mean the number of months left in the year on February 1st. So rule #1:
ALWAYS GIVE CONSTANT VALUES A NAME - that way when they change (which is why they're called constants, right ) you only have to change them in one place. In your case, there are a lot of constants involved, but if your boss decides to add three more columns of data, you'll only need to change a few constants (depending on where those columns get added, and what they are!)
Second - you have indicated that both constraints need to be true (Value AND Share). So I've coded it this way. If either one needs to be true (or if ANY share needs to match the Share constraints) then the logic changes - quite dramatically. But again, there's only a limited number of places that need to change.
Third, some parts of the code need considerably more detailed calculation than others. Using a technique called Stepwise refinement, we simply shunt the active development of those parts off until later. You'll see this happen as I need to define a Group, a Share and an Extract. Simply declare the function or procedure, and then worry about coding it later. (You'll note that I've only developed one of the three functions - the others are for you to do!)
Lastly, always try and run your code as early and as often as possible. It's much easier to find problems from code that is running. Exceedingly true in COBOL programs (which are sometimes many thousands of lines long), but equally true in VBA. Sprinkle your code with debug statements, so you can see how things are progressing.
So, take a look at this code (it's in the attached spreadsheet), and see how you go on filling out some of the gaps,
HTH
Tony
PS I really don't want to deprive you of your paycheck, but you might want to give me some reputation...
Bookmarks