Search results

Late to this but I had fiddled with a similar problem fairly recently and learned a few possibly relevant things (but probably not all the things) in the process. My problem was not a scrollbar, per se, but an ugly shaded gutter where a scrollbar might be, when the number of records were...

Close is one thing. Looking for trouble is a whole other kettle of fish. 😁

You answer your own question, actually: Readability. It's a well-understood term and the concept is directly relevant to the project. It is close, which is why I posed the question in the first place. The consensus seems to be that close is perfectly safe and acceptable because there are no...

Just the thing to avoid. Of course, I've never encountered any such thing in my code. ;-) Very interesting examples. That's the thing: It's perfectly valid or correct to have a style preference for one or the other, but only if one pays deliberate attention to the consequences. If one...

There's that, of course, but it also matters in object frameworks, garbage collection, filtering routines, and rendering GUI elements, especially things like complex TreeView controls. Nevertheless, it remains a subjective evaluation.

Well, that's exactly the tradeoff. That insurance carries a premium and the relative values can only be evaluated subjectively. Going in the deep end isn't as much of a problem if you can swim, as it were.

That's a good point. I'm conflating user-specific settings and application-specific settings. I'd put both in the BE for just the reason you state, to permit FE versioning. I can't imagine many reasons at all to keep any configuration data in a FE.

Not that you should, of course, but the reason I generally would is efficiency, unless I had a specific reason to use ByVal. For objects, ByRef passes the pointer itself, while ByVal passes a copy of the pointer (not, to be clear, another instance of the object). ByRef allows one to change the...

You just pointed out something else that might be at work. Ambiguity is one thing, and to be avoided, and consistency is another, to be sought. Specifically, you're using inconsistent key field names, id in one case and SexID in another. Instead, name all key fields, both primary keys and...

You're right. I just tried a WithEvents declaration and the VBE did not approve. Thanks for pointing that out. Even were it possible, though, my initial instinct would be to handle custom application events in the global form's module, which is much better suited. Out of curiosity, why...

This may or may not be what's at work but you do have a case of ambiguous naming that could lie at the root of your problem. The "Sex" case may be unique in your dB but you should verify other instances of the same difficulty don't exist. To the point, Access does best when objects have...

DLookup() is nifty as far as it goes but can be optimized in many ways. I developed a DLookup() clone (see below) to do just this, and designed it to be a drop-in for the OEM function. This won't address your network latency issues but may speed things a bit. I haven't tried it but I expect...

Re events, I haven't tried it yet but I expect one can sink events in a standard module via a module-level object variable declared WithEvents. What definitely can't be done is raise events to be sunk elsewhere. That requires a module instance being assigned to a remote WithEvents variable...

@MajP , you're quite helpful, and thoughtful, to raise these points. It turns out I'm deeply familiar with predeclaration, not to mention other dark arts of attribute manipulation, and have implemented it on a number of occasions. It's nifty as far as it goes but has its limitations. Most...

It's good to know that the compilation process provides a firewall of sorts in this regard. That probably rules out most of the risk scenarios I could envision and leaves me far more confident that a "Namespace" property or function won't court disaster. This said, I have discovered that...

The procedures in the same module need to pass a Form variable (not the form's name) when calling RepositionForm(), just as when calling it from a form's module. No telling what those procedures do, with what, or from where they are called but somehow, they need to gin up a pointer/object...

Pete, this was my initial take as well and thanks for confirming. As noted in my prior response, which was written before yours but delayed in posting, the project does in fact compile and, after a bit of churn on closing, things settle down. Actually, it is a property of a standard module. I...

Thanks, no, I didn't see it on the VBA list of reserved words, either, although it's definitely on the VB.NET list. There isn't an express naming conflict in the app. The property is the first use of "Namespace" in the app, ever. Also, the project does compile, after all, and this ordinarily...

"Namespace" is reserved in VB.NET but is not documented as such in VBA, as far as I can tell. VBA bucks a bit when I attempt a "Public Property Get Namespace()" but seems to take the bit after compiling, saving, and cycling the app a few times. Lest I court disaster and before I go too far...

Perhaps but if so, she ought to be able to respond substantively rather than ad hominem. It's an interesting presentation but I've also studied event progression with equal or greater rigor, so I do, too. Perhaps she might learn something if she paid attention, read closely, and weren't so...