Recent content by pdanes

You wrote in one place "...ALWAYS the same specificlly named controls...". That is what made me think you were hard-coding foreign object names in your called routine. If you are doing it by looping through collections or referring to a name passed as a parameter, then I agree - that is the...

You can always grind things down to an absurd level by inventing scenarios that you dream up specifically to chase down and illustrate a perceived shortcoming in someone else's position, but I see nothing to be gained by that. The scenario you propose is not so much an illustration of any...

"using that object, reference actual controls on the calling form to get/put data" THAT is what violates the anti-coupling rule. Unless you do everything with loops and such, referring to an actual control requires knowledge of that control in source code. Such knowledge violates decoupling.

Passing string parameters also does not require any classes. Only clumsy if you make it so. Parsing strings is a trivial exercise in coding, and setting it up as a Select Case inside a loop makes it childishly simple to read, understand and add to if needed. Not true - exactly the opposite...

Nice - lots of good functionality there in very few lines of code. I considered trying to make something like that, but decided that I didn't really know enough to be sure I could do it well, and since I was trying to make my existing constructs simpler and clearer, sticking to strings was a...

That rather violates the principle of loose coupling. Having knowledge of the calling form hard-coded into the called form seems like exactly the sort of thing you would want to avoid. What if you want to call that form from different places? I need to do exactly that quite often, and that was...

Sorry for lagging - my availability comes and goes. Yes, I like what you've done there. It allows a popup form to manipulate an element on the calling form without requiring the popup form to know anything about the calling form. This would allow you to use the same popup from multiple places...

You think adding reference to such a .DLL might enable modern Access to read such stuff? How would you call such functionality?

Thanks - I found references to that, but I no longer have any functional machines with 2003. It's a bit frustrating when functionality disappears, but on the other hand, app bloat is already a problem as is, and if the developers left in everything that was ever useful to someone, the product...

Thank you for the offer, but the import is not really that big a deal. That was more of a background whine on my part. The only hassle is that I have some custom document properties set, and Access's built-in import function doesn't handle those. I don't know why not - it seems a rather obvious...

References are all okay. I don't think it would even compile if there was something wrong with a reference. And it's only this one app - other Access apps on the same machine work fine. I haven't tried this app on a different machine, though. That's probably worth a look, although I'm not sure...

Yeah, I was hoping to not have to go that far, but I may have to. It's aggravating though, because the app works fine. It's only the debugging when I'm making some changes for the user that I run into this. And yes, I do use Option Explicit everywhere.

Please see last sentence in first paragraph of my post.

I have an app that has recently developed an extremely annoying trait – it crashes and closes on breakpoints. I set a breakpoint, as I always have, the code gets to that point, stops, the VBA window appears with the line highlighted, perfectly normally, then a few seconds later, Access just...

I think you're right. I just found a Paradox convertor and it shows the contents properly. This one is limited to 50 records in the trial version, but at least I know what I have now. Many thanks. How did you know?