VBE keeps undoing my capitalization changes (1 Viewer)

Micron

AWF VIP
Local time
Today, 08:12
Joined
Oct 20, 2018
Messages
3,476
I'm not going to spend another 2-3 months fixing something that doesn't matter.
At least not yet. You could find a utility for renaming all controls with a prefix, I imagine (e.g. txtCustomer). Not sure if Find/Replace on the code would reconnect them on compile or not, because I'd never need to separate them anyway. Maybe someone else here knows.

As for compact on close, you must have either set that in options or are running code to do it, I would think. If you're sure neither is applicable, then it sounds like you should be rebuilding this sooner rather than later.
EDIT - as an experiment on a db copy, I might try turning on Name Auto Correct, rename the controls (via code or no code) save, compile and see if Access maintained a connection between the control and its procedure. If it works, it should rename the procedure too. Then I'd turn it off again. Seems like I'm not the only one who would not have field and objects named the same, but it doesn't seem to have convinced you to consider doing anything about it.
 

HalloweenWeed

Member
Local time
Today, 08:12
Joined
Apr 8, 2020
Messages
213
As for compact on close, you must have either set that in options or are running code to do it, I would think. If you're sure neither is applicable, then it sounds like you should be rebuilding this sooner rather than later.
 

HalloweenWeed

Member
Local time
Today, 08:12
Joined
Apr 8, 2020
Messages
213
... BTW, your comment about fixing (matching?) what you've done in table/query design is interesting. ...

Just to give you a taste, so to speak:
First, keep in mind our records in our main table have >50 fields per. They are legal records, so they must never be changed (except minor corrections like typos). There is recordkeeping of the edits/users.
I have a subform with 16 distinct visible fields that works kind of like an index/TOC. This subform has 14 sort buttons (7 fields) and 13 filter buttons (on 10 fields). All these buttons dynamically change color to indicate their state (active/inactive), including background, text, & hover(both). The sort order is changed on-the-fly by the order in which you press the buttons. These status are not saved in any table anywhere.

This subform calls up a form that displays the record. If you check a box on the subform, it saves your sort & filter status, even though it closes the form, when you go to the record form. Then, after returning (reopening) to the form with the subform, it automatically loads the sort & filter parameters, sets them, and sets the button colors using a private user-defined function, and you can then change the sort order as stated above, or disable/add filters, all using the buttons (filters sometimes require typing input). This is all done by building all the (active only) sort & filter status into a text string, and passing it to the next (sub)form in OpenArgs. The subform parses for each status from within the text sting passed to it. When a filter is active, the red "filtered" stamp shows in the middle of the header of the subform, among the buttons. It all works perfectly and beautifuly. It looks visually pleasing too.


Then there's the 'live search' forms. They take user input and dynamically change the results (drill-down) as the user types each character, reducing the number of results for the user to choose from. Without interrupting the user's input, without losing cursor position or selection. In it's current state, it usually takes only 1-4 keystrokes to see the target record on the screen without scrolling. It works instantly, no delay, if you are not working remotely.

A few of the fields (textboxes) in the aforementioned record forms brings up live search forms instead of letting you type into them. Automatically, instantly. And this is the only way allowed for these fields in this form (and another stripped-down version of the form). You might be surprised at how speedy of an entry method this is.


I hate ComboBoxes.
FYI. :cool:
 

HalloweenWeed

Member
Local time
Today, 08:12
Joined
Apr 8, 2020
Messages
213
Well I'm not working remotely today, and guess what: it's not doing the "compact on close" behavior. Could be since my last bugfixes, I won't know until I work remotely again, which might be almost two weeks.
 

Isaac

Lifelong Learner
Local time
Today, 05:12
Joined
Mar 14, 2017
Messages
8,738
Well I'm not working remotely today, and guess what: it's not doing the "compact on close" behavior
Very interesting - was precisely my experience. When I was remote, AND developing on a network copy ... rather than a copy on my local.
 

HalloweenWeed

Member
Local time
Today, 08:12
Joined
Apr 8, 2020
Messages
213
Very interesting - was precisely my experience. When I was remote, AND developing on a network copy ... rather than a copy on my local.
Even my local copy was "compacting on close," but it was just the FE that was local copy, the BE was on the institutional server (through a VPN). That's what makes it so curious to me. I may try connecting tomorrow for a few minutes, just to find out if it still does it.
 

HalloweenWeed

Member
Local time
Today, 08:12
Joined
Apr 8, 2020
Messages
213
Well I'm not working remotely today, and guess what: it's not doing the "compact on close" behavior. Could be since my last bugfixes, I won't know until I work remotely again, which might be almost two weeks.
Status update: oh call me an idiot, because it is/was still doing the "compact on close" behavior, I had just turned off the status bar. I can't tell (if it's doing the "compact on close" thing) when the status bar is off and I am running a local copy because it runs two maketable queries on another network db file before it closes, and that is not a quick close, takes about 30sec. remotely - half that time in the office LAN. I haven't confirmed that in the office yet, but I'm sure this was the basis for my misconception that it quit doing the "compact on close" thing.

What's more, yesterday with just 15 min. left in my shift, after I had been doing about 3 hours of troubleshooting in my vba since my last archive save, when I thought I had it done: it said "unrecognized database format" when I tried to compact it - in the office on that LAN. Fortunately I was able to get it to let me copy my text code in the two modules I was working on before I actually shut it down. But again, now I question the stability of my FE. The thing that was causing my code errors previous to that happening was the code was trying to set a value in another form (just opened) when that control did not exist on that form (neither did the field in the bound query). I had also discovered a flaw in my logic and had rewritten several dozen lines of code involving reading and writing values on three or 4 forms (other forms open hidden in the background). I always compile and then save my VBA code before "compact & repair." FYI.
 

Users who are viewing this thread

Top Bottom