Recent content by pdanes

Bullseye! That fixed it - just tried ten times in a row, selection sets both large and small, and 100% success on first opening. Many thanks.

Title pretty much says it all. I have an Edge Browser control on a pop-up form opened in dialog mode. It is supposed to show a map, using an OSM Leaflet. When the app opens, the first instance of opening the subform shows nothing. I've put debug print statements in the form's Load event, and all...

Okay, I'll give you that one - posting a PDF version of my article was a good suggestion.

I tried, but you're an admin on the site, and the software won't let me block you. Actually, I'd prefer if you occasionally said something sensible or useful, since you obviously do have some experience, but when responding to me, at least, you have limited yourself to insults, snark, pointless...

I wish I could block you. I can't think of a single instance where you've contributed anything useful to a question I've posed.

No argument there. Very few non-trivial categories are easily definable in such a way that any particular item can immediately be assigned to the proper one. Even 'good enough' is hard to define. I agree that setting up public property routines in a form is preferable to having outside code...

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...