Search results

A few of us were putting heads together the other day to resolve some difficulties around closing form instances and I thought I'd report back. What's new recently in the experience of several of us is that apparently, clearing a reference to a form instance is no longer sufficient to close...

I'm noodling a bit on how the labels approach might substitute for a page with many subforms, but that's admittedly a special case. I have navigation baked into my application framework, that handles moving among forms and records. See here. AutoKeys can be handy to open forms in the first...

I noted the themes comment yesterday, and no, I haven't tried that yet. I have a few things competing for my attention this instant but will fiddle with that and report back. I'm actually doing some integration work concerning themes, etc., so this could be a timely wrinkle.

Judging by responses, this seems (as before) to be a transient bug replicatable by some but not others, and in any case without an obvious fix. I'll try re-developing the form and controls, probably with no code at first, in case design changes corrupted something. I'll report back if I can...

Colin, as noted in my original post, I'm currently on A2019, in which I just now observed the behavior, and previously reported it on A2007, whereupon it was confirmed in A2010-A2013.

Yes, now, but I wasn't in the prior case. Are you aware that this may create a difficulty?

Interesting. So, it's confirmed on A2010.

Tom, as noted in my original post, I reported this previously concerning A2007, it then was confirmed on A2007-A2013, and I now have observed it on A2019, which I'm currently working with.

Others in my prior post couldn't either, at first, so no surprise, but then several did.

Here's the problem case: and here's the case omitting the ampersand for the first (leftmost) tab: I will add that, in my prior post on this topic, many at first could not replicate the issue but then others did, going on to discover it introduced unspecified instabilities.

My understanding is that doubling an ampersand escapes it (just as doubling a quoted apostrophe or quotation mark), with the consequence that a single ampersand appears in the caption. Instead, I'm trying to designate the following character as an accelerator key.

I observed the same behavior in A2007 several years ago and while some weren't able to replicate it, others then confirmed it to be a bug across many Access versions (A2007-A2013) that actually destabilized Access. Today, it manifested in A2019. To review, we all know that an ampersand (&) in...

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