Access VBA hell
zav last edited by
Deep within a piece of f/c|<1ng $h177y application that a manufacturer is using, in production 24/7:
MsgBox "Changing the existing routing type in this way will cause undetermined errors. Press OK to proceed.", vbOKCancel
Nice huh. Right now I'm not sure if the user clicking the cancel button doesn't "cause undetermined errors". Basically anything the user does or clicks on in this app has the need for this dialog box top pop up. I hate VB enough as it is, and then having to fix an Access VBA app like this makes me want to hurt something. I might have to submit a major WTF from this project just to make me feel better. It is just so hard to choose...
KattMan last edited by
Once again it is not the tool, but rather the "programmer." Any developer that thinks this might be a good pattern needs to stop developing. Are you sure the guy before you wasn't a semi-trained chimpanzee?
I feel for you man, really I do.
Guest last edited by
Sounds like you got someone's prototyping mockup instead of a real project, I hope, and this is to discourage anyone from trying to play too hard with it.
Manni last edited by
VBA is not a bad language as long as the person using it has half a brain to program with. Unfortunately, anyone with half a brain would pick a far more robust, stable language to use, which leaves the user base to the morons who tinker with it just barely enough to get it working the way they want.
I can't count how many VBA projects I've had to pick up that were started by someone with no coding background and very poor hand-eye coordination. Calling SendKeys all over the place, no error handling, declaring every variable globally and as a variant... dear lord.
But I always jump at the chance to flex my VB knowledge.
MsgBox is actually a function with a return value, so if there's nothing being evaluated on that line, then it doesn't matter what you click. OK, Cancel...all does the same thing.
Now the user thinks "If I just click Cancel, I'll be safe from these errors."
No you won't.
donazea last edited by
Unfortunately, anyone with half a brain would pick a far more robust, stable language to use,[/quote]
I'm inclined to agree with you; however, I must inquire though - what can I use instead of VBA in Access?
And yes, I know - I would prefer something more robust, but Access is what I'm stuck with.
powerlord last edited by
Since they used vbOKCancel instead of just vbOKOnly, I would hope they would check the response given.
vbYesNo and a reworded dialog probably would have been a better choice, though.
Jehtris last edited by
You could write .NET or VB6 as a front end to the Access app, but you'd have to duplicate all the work.
You could also write VB6/.NET COM .dll's, and have access call them, but it's more work than it's worth.
Access can do amazing things, and small apps can be built very quickly. The problem is not the tool (although file based databases are more apt for corruption, and I've had several forms become corrupted). The problem is the availability of Access on most business user's desktops, and the need to rely on VBA to get things done. Excel macros are also VBA, but you can do alot with Functions.