lets say you have a pageful of code (a function) that will also do a job in an other part of your app. but you have to change a few variable names it will call on.
It's tempting of course and you ask what could go wrong?

well for starters some of those vars will be global not private, so if you miss changing just one of of them the function will still work because it doesn't 'know' which global vars are you referencing the old ones or the new ones.

there is more to it than that, it need not be a function it could be a directory address or whatever or worse case a pointer address that happens to be valid, but believe me it can drive you nuts trying to find a bug like that because everything seems to work ok but gives you the wrong results.

It probably won't matter as much in a small project.

forgot to add, you might not even know you are getting the wrong results.

Thanks for that.

It goes along way in answering an issue I have at times - get the wrong result.
The code runs automatically through the day. As I am not placing bets at this time I just let the computer run through and then go through and tidy up any code at the end of the day and update the records.
Sometimes the code will say to place a bet when it should say no bet and other times the opposite.
I put it down to the excel not being on the screen or something like that.
Now from what you are saying then maybe it is because I have a lot of global variables.
Oh well...more work to do.
Thanks for the heads up.

Ta,
Martin

Another convention! All global variables should be named ala: gMyVariable

...although globals were thought an indicator of poor design back in my day... Hasn't stopped me lately; I don't even bother defining variables half the time. And memory? How big a deal did that used to be?! And how great is Google?! I don't know VisualBasic, but I know what it *should* be able to do, I google it, and there's a code example! No more manuals. No more learning. We're in a golden age now!!!

If you're looking for another related project to spend time on, you could start collecting xml race files and cobble together an 'automated test harness'. Essentially, have your project cycle through a series of these files (that would ideally represent everything you would encounter in a real-time environment and base decisions on within your program) and verify that the program behaves as it's meant to. That is, instead of making a bet it outputs to a text file noting the action it would've performed. Once all the xml files are processed you compare the text file produced to one that contains the correct results.

A pain to set up, but it quickly and easily highlights logic bugs and allows you to verify you haven't made any unintended changes when you edit.

Oh! Use revision/version control too. It's all coming back to me now. ...make it stop! Make it stop!

youre right about google and VBA.
i use it all the time for vba code.
Just type up a coding problem and there is someone, somewhere, who has a solution for it.