Just a guess, but is it possible that you have something that needs a little time to process.  Your breakpoint may be giving it that time to complete.

@Matt I don't think so, it seems Access seems to be taking a different path without the breakpoint, starting form procedures that have no reason to run. To my way of thinking, code should not operate differently just because you're stepping through it. Although timing could do that, but that would be an internal bug to Access, not at the code level we operate.

To follow on matt's idea, add a "Sleep" just before where the problem happens. this will confirm if it is a timing issue or not.

I'm with Matt on this.  The timing issue would be the first thing I would look into.  From what you said in the first post, problems occur whether you have a breakpoint or not.  So the problem likely lies in the code.  It may not have to do with breakpoints at all.

@ All, another thing started happening recently (after a Windows 11 update, as best as I can tell). When the VBA breakpoint is "hit", the VBA editor displays a procedure that doesn't have the breakpoint, and I have to go searching down to find it.

@ Kevin, in post#1 I said the problem goes away with a breakpoint (ignoring the image issue). That's the only thing that changes in the code (no immediate pane changes either). I wouldn't think that should change the procedure flow, but putting a breakpoint in a procedure that has no reason to run gets hit without the breakpoint, but doesn't get hit after an F5 at the first breakpoint. Maybe I'll make a video to demonstrate.

And why is the image issue ignored?  It could be another symptom of the same problem.  At this point, you don't know what is happening, so you have to take everything into account.  Hence, there is a problem whether you use breakpoints or not.  A bug in Access should be the last thing on your mind.  You should exhaust every debugging method on your code first.  Run it in debug mode line by line with F8, then skip over portions of the code with Shift-F8.  If user inputs are involved, try running the code with different user inputs.  Does the location of the breakpoint matter?  Try different locations as well.

Dang, it lost my last msg. Well, here we go again.
I made the video. It shows the program runs different by just adding a breakpoint. There is no timer code, and pressing F8 after the breakpoint runs nothing else. I show it several times to show that at least the strangeness is consistent.

https://drive.google.com/file/d/10kmwBythr3vsj3R6cVbBlIOhLtAjB_HR/view

What do you think I could be overlooking?

As to the image part, again, why would a breakpoint make an image not appear? The same code is running. If there is a problem with how forms behave with or without breakpoints, then it's Access that is suspect, since my code's behavior shouldn't change with only a breakpoint being added or cleared. Now, there may be a way to work around the Access error with breakpoints, but why have it come back to bite me or others later?

@Kevin, I guess to make it clearer, I can't step through code that doesn't run when there is a break-point set.

I watched your video.  You need to put the breakpoint at the start of the Click event, not the end.  When you reach the breakpoint, press F8 to step through every line.  Step into each procedure too, and step through every line in each procedure.  The Click event calls several other procedures that aren't shown in your video.  You need to see every line executed within those procedures in order to do proper debugging.  Monitor the value of Me.Recordset.AbsolutePosition in those procedures (with Debug.Print, for instance) and see when and where it changes from 39 (the 40th record) to 38 (the 39th record).  As I said, there are tons of debugging to do in a tricky situation like this before you can draw any conclusions.

Have you tried putting "Debug.Print Me.Recordset.AbsolutePosition" in as many places as you can in your code, with no breakpoints, running the form as you did in the video, then checking the immediate window?  You can have Debug.Print print something like:

Procedure1, line 10, 39
Procedure1, line 20, 39
Procedure1, line 30, 39
...
Procedure2, line 10, 39
Procedure2, line 20, 39
Procedure2, line 30, 38
...

This way you can narrow down the exact location where AbsolutePosition changes from 39 to 38.  Post screenshots of the code at that location, and see if we can spot something.

@Kevin, I understand what you're saying, and have done that. Logically it doesn't make any sense that a breakpoint, in any line, would alter the procedure flow. This isn't the first time I've seen something like this in the black-box of Access running of our code.
Thanks for the suggestions.

As I said, when using stop, or breakpoint, or Debug.Print, the AbsolutePosition never changes (until the crazy code starts to run without the breakpoint). Leaving out the breakpoint, and leaving the Debug.Print there still says 39 at the end of the Edit procedure. The last line of code that should run is the End in the Edit procedure. I'll add a snip, you can see the cursor is still sitting at End after an F8. Without a breakpoint, other code runs and I can trap it with a breakpoint in Form_Current.


But maybe I'm missing something, can you tell me how a breakpoint could properly alter code flow when just pressing F8?

If AbsolutePosition doesn't change inside the Click event, the next step is to check if anything happens after the Click event; and if so, whether it has any effect on AbsolutePosition.  Also, a screenshot or video showing the immediate window side by side with the form's record selector would help too.

>> can you tell me how a breakpoint could properly alter code flow when just pressing F8?

Again, you need to refrain from concluding anything about the breakpoint until all diligent debugging has been done.  Saying "I've done all the testing, trust me, it's the breakpoint, what say you?" is not good enough, because I need to see the testing too if my opinion is what you want.

After that, we can look into whether the form is damaged, or the database is damaged, or any number of things in Richard's list of troubleshooting.  There is a long way to go before we can conclude anything.

So, I made another video, simpler, shorter, with only a Stop and an F5. Now how could the form run any different with just those two? But it does!

https://drive.google.com/file/d/1V7Ur6koSEvz1qd2lrOFxHbm79Ph49IfB/view?usp=sharing

What I'm going to do is move the database to another laptop or two, with older releases of Windows and Access (hopefully they haven't updated recently) and see what happens. As I said, I've run into this kind or problem before, where testing with a breakpoint, things work fine. Without the breakpoint, all hell breaks loose.

Why would I refrain from considering the breakpoint as an influence? How about the stop? A properly functioning debugger should not contaminate the code flow.

I've spent 40 years debugging code, down to binary and assembler in chips and O/Ses. This simple procedure (even with its calls to other procedures) is nothing very complicated, well it is, because I can't see what Access is doing with my VBA.

Again, there is no way in hell a Stop and F5 should cause things to run differently. Unless there is a big, fat bug behind the scenes.

I went to the other laptop, with Office 365 and Access version 2410, even newer than my regular laptop. So, I'll have to go to the other office and see what access is on the laptop there. But we should be able to rule out that the Access on both laptops with different O/S and Access versions are both corrupted. If the database was corrupted, I would expect to see a lot of other errors popping up.

To make extraordinary claims, you need extraordinary evidence.  Maybe you've already seen the evidence to make your claims about the breakpoint, but *I haven't* from what has been shown so far in this thread.  So every time you make your claim about the breakpoint (in every post, so far), I'm going to make the necessary pushback to put our focus back to where we belong, the debugging.  This is what every developer is supposed to do in debugging, data and testing first, and conclusion last.

And if you insist on jumping to conclusions, you may upload the database to Google Drive and let me download and test it myself.

Okay, let's not jump to conclusions, again, how am I going to debug code that doesn't appear to run?
Yes, I'm supposing that my Access, that has recent upgrades, one just done a few minutes ago, is working as designed by Microsoft. How can we prove that assumption is wrong?

And again, what explanation do you have for a Stop and F5 causing different behavior, but a behavior that works fine in other fields and most records. The code doesn't change, and yes the data does, but nothing in this procedure with the stop added changes the data. In other words, I don't see any "if there is a stop in this procedure then do something different" command. There's no jumping to conclusions; the video evidence is right there. Unless you can convince me with documentation from Microsoft that says a breakpoint causes different code paths on purpose.

As far as evidence and extraordinary claims, we aren't talking about the existence of a God, and we have two videos that are fairly clear that something strange is happening (I promise I haven't done any extraordinary editing to make things appear different than they are). It's not like anyone has claimed that Access is without its bugs.

It's not a show stopper, but I've hit this kind of behavior before and would like to know why using a stop or breakpoint makes code behave differently.

@ Kevin. After having many such Access episodes as this, I'm game to see if the "bug" happens for you in your Access. Or if you come to a different conclusion about how the breakpoint affects flow. Maybe Microsoft has singled me out for bizarre things like this? I'll trim down the database and send it to you. Hopefully we can inspect on Zoom together. I've got my email in the YouTube video:
https://youtu.be/9v4nvbGhD5E  
Minute 1:04

@ Kevin Y. Let's agree to a few things before we go down the rabbit hole. The code I will share has 44 years of work in it. You agree to keep it confidential. We agree that the question isn't that there may or may not be a data or code error (because I'm still debugging), we are only curious as to why a Stop & F5 allows for different process flow in the VBA procedure and form (which hinders the debugging process). Agreed? Tromping through hundreds of lines of code may raise some suspicions, but it won't answer the simple question at hand about the Access editor/debugger behavior.

On second thought you'd better ask someone else to look into this for you.  I've already given all my thoughts in this thread, which can be summed up in two words: more testing.  If you can't find the cause of the problem, maybe a second set of eyes can.  You need another person to not only do troubleshooting, but have a different mindset and methodology from yours.  When I was in my old job, I called for outside help all the time; and the consultants I called in would in turn call additional consultants if they needed help themselves.  Your situation seems like a consultant's job, to be done in a professional setting.  If you are averse to what I say, maybe you'll listen to someone whom you paid and hired yourself.  I retired 5 years ago and have no interest in picking up any heavy-duty work.

P.S.  No I've never seen breakpoints behave like that ever in my Access work.  But I've seen odd behaviors in forms and reports, which all Access users have.  The video below shows a textbox that remains blank no matter what the user does.  You can download this database from the description and see for yourself:  

     https://www.youtube.com/watch?v=-LE4XBBSO1M

@Kevin, okay thanks for your insights.

I imagine any paid consultant is going to say the same thing I would say in any code where a Stop & F5 produces a different result than no Stop. I'd say, "Let's try on another computer and if it does it there too, then I'm going to report it as a bug."

I have textboxes that remain blank until the user presses the Edit button. If I hide the button, then a user can't enter anything. I'm not sure what you were driving at. A little more explanation of your "odd" database would help.

@ Kevin, I looked at your video. With out voice and with the mouse moving all over the place, it's kind of hard to tell what you're doing or what is suspect. The first thing I saw was a Fore Color of Text 1. I don't have Text 1 in my Access, so I would at first suspect that the fore color is the same as the Back Color and if not then I would try to figure out where Text 1 came from. That's why I don't use the Access Themes or funky color names.

Hi Thomas, I wrote about my misbehaving textbox in this forum post a while back, with more detail on the exact symptoms:

     https://599cd.com/blog/display-comment.asp?CommentID=82872

@ Kevin R. Funny, it doesn't show in the drop down of the field property.
But that's why I stay away from what Microsoft offers in colors. I think they're still figuring it out.
Is it RGB or BGR?

@Kevin Y. That would have been nice to know. Anyways, there are a lot of ways one can mess up a textbox, with so many properties. I too have seen them go awry, and format painter or delete redo often clears it up.

But, since Stop is a VBA statement which should have good documentation, I'll go look online to see if Stop has a feature that causes code to run differently, stand by...

From Microsoft:
"You can place Stop statements anywhere in procedures to suspend execution. Using the Stop statement is similar to setting a breakpoint in the code.

The Stop statement suspends execution, but unlike End, it doesn't close any files or clear variables, unless it is in a compiled executable (.exe) file."

Nope, don't see anything about other commands or statements being affected by Stop or affecting Stop. It's documented to behave just like every other programming language I've worked in that has a debugger and a way to halt execution.

So, if anyone else has had gremlins like this, and has jumped to the conclusion that the Stop statement is really just a Stop statement and nothing else, here I've done another video, the final that shows exactly what we've been discussing so far.

https://drive.google.com/file/d/10kmwBythr3vsj3R6cVbBlIOhLtAjB_HR/view?usp=sharing

The reason I've been so persistent even with Kevin's doubts, is that for years I've had code run one way, and then when I spend hours trying to track down why it's doing something I don't expect, I find that the code operates different when I'm debugging (using breakpoints and Stop). If anyone has something similar, I would love to know what version you are running, so that we can present Microsoft with EVIDENCE, that it's not just me, that can't debug code.

If you've wanted to take a peek under the hood of the ADS, this trimmed down version I made for Kevin includes code that you can watch and test for only the Entity Form. The evaluation version I send out is more robust, but is in an .accde, so the code is hidden. Here's your chance, but keep in mind the terms you agree to in the login form.

I've got my email in the YouTube video:
https://youtu.be/9v4nvbGhD5E  
Minute 1:04

Adding to the strange behaviors, if I am Stopped in the VBA editor and press F5 to continue, a tab is inserted into the code.

Even more, I go into a form to inspect something, right click on a control to see the VBA code, just look, don't change anything, go back to the form and close it, Access asks if I want to save the changes. But there weren't any changes. This started happening a few weeks ago. Another update to the VBA editor?

Before someone suggests that maybe I should roll-back, I tried that once before. Besides the confusing number of editions and versions of Access that make it very difficult, when I rolled back Access tried to verify my license. I had two laptops die, so Microsoft makes the old key invalid and refuses to do anything to help establish the key as valid for a new computer. Yes, I talked to a real person at Microsoft about this and they refused to offer any solution, other than "buy a subscription to Office 365". Hmmm.

Sorry, I managed to copy an incorrect link above, here's the latest and last (I promise) video on this Stop strange behavior:

https://drive.google.com/file/d/1kJgNK5f0bVl9zpKntg-Uu23e3gP64w0l/view?usp=sharing