Adding fill to cell always gives marching ants border, too

Windows 10, Office 365 Personal, both with all updates.

The subject line pretty much says it all. When a friend selects a cell, then the 'paint bucket' icon on the ribbon to add a fill color, no matter what color he chooses, the cell is filled with the selected color, BUT he also gets a 'marching ants' border, which he doesn't want. That border will disappear if he presses Esc. IOW, it's behaving as though adding a fill also copies the cells. This is an XLSX file, i.e. no macros.

Is this a new bug?

I found info in another thread suggesting it's a keyboard problem. He's tried a different keyboard. That doesn't fix it.

A Quick Repair of Office doesn't fix it.

He's sent me a copy of the workbook. I can't replicate the problem.

Thanks much for your thoughts.

The 'ants' remain until he hits ESC. It's all workbooks, not just this one, including a newly created, empty workbook in which he's just clicked on a cell, then clicked the Fill button. Also, this behavior only started recently.

I think there's corruption in Excel (on his machine). He's doing an on-line repair. I'm hoping that will fix it.

From what I've found on-line, there's no way for a user to create a 'marching ants' border -- only Excel can do it, because those 'ants' are reserved as an indicator that the copied cell contents are still on the clipboard, to enable pasting multiple times. I did find VBA code that simulated thie 'marching ants' by using a dashed line as the border, and repeatedly changing the dash pattern. Don't remember how they managed to continue that for the entire time the workbook was open, but it sounds to me like it would cause a real slowdown.

PS: I was formerly a MS MVP for Excel, from 1994 - 2004, but haven't had the time to continue that.

Who doesn't know the name Myrna Larson?

What if he opens Excel in Safe mode?

No, MVP 2011-2017.

But I've seen your permutations and combinations code posted maybe 38,742 times

Yes, that whole thread appeared in (AIR) 2005, when the code wouldn't run because things had changed in Excel since 2000 or 2001.

The code had a constraint, that the results had to fit on a single worksheet, so it checked for that, using the Count property, which returns a long integer. In the interim, MS had increased the number of cells on a worksheet to a number that exceeded the maximum for a long integer. So you couldn't use Sheet.Cells.Count any more.

The guy started the thread because it was aborting due to an error. He found the problem, but he didn't know enough VBA, so he 'fixed' it by commenting out the error check.

Are you the fellow who provided the correct fix, i.e. If N > .Cells.CountLarge Then.... ?

If so, thanks! I only discovered the thread a year or so ago, 15+ years too late!!! Not very good 'customer service'.

Are you the fellow who provided the correct fix, i.e. If N > .Cells.CountLarge Then.... ?

If it was me, Myrna, it's way lost to the mists of time.