Question Strange TextBox Behavior (1 Viewer)

dpm · Dec 12, 2017

I'm using:
Microsoft Office Professional 2016
Version 1710 (Build 8625.2139 Click-to-Run)

It is possible this odd behavior has always existed, but in the many years I have developed Access applications, I have not noticed it.

I have placed a TextBox on a Form. I note this behavior whether the TextBound is bound or unbound. After typing a character into the TextBox, I hit Ctrl-z. The character is removed and the TextBox's Change event fires. After typing a character into the TextBox again, then hitting Ctrl-z, the character is removed, but the TextBox's Change event does not fire.

I can rinse and repeat this all day. Every other time I repeat the above, the Change event fires. Every other time, it does not.

I then created a new Form and placed a TextBox on it. Again, testing both bound and unbound, I am able to reproduce the behavior, though it is a bit different. Instead of every other time, I am able to use Ctrl-z twice, causing the Change event to fire. On the third press of Ctrl-z, the Change event doesn't fire. Rinse and repeat.

I created a new database and repeated the above. Every third press of Ctrl-z results in the Change event not firing. Naturally, I need the Change event to fire every time so that I can manage the state of a nearby Button. I have studied the matter closely in order to determine what alternate Event I might use. I believe I can safely say that there is not one. Has anyone else observed similar behavior?

jleach · Dec 12, 2017

Sounds strange indeed. Not sure why that behavior. Can you use the control's Undo event to manage this?

https://msdn.microsoft.com/en-us/VBA/Access-VBA/articles/textbox-undo-event-access

dpm · Dec 12, 2017

Well my goal is to use a couple of TextBoxes to add new child nodes to a nearby TreeView. As such there are no Fields in the underlying RecordSource to bind them to, and the Undo event is not fired.

I did experiment with placing these TextBoxes on a Subform, binding them to a local Table. The behavior is the same. In this scenario I do use the Undo event to call a method that manages the state of the the above-mentioned 'nearby Button'. Undo fires upon hitting Esc or using the Undo button up in the Quick Access bar, and does not fire when using Ctrl-z.

I was unable to come up with any combination of events to effectively trap the odd Ctrl-z. I tried the TextBox's KeyDown event - and was able to trap the Ctrl-z key combination, but it occurs before the TextBox's value changes. In other words, before the character is removed from the TextBox.

dpm · Dec 12, 2017

I think I've found a decent way of getting around this odd behavior. In the Form's KeyDown event, if Ctrl-z is pressed, I call the TextBox's Undo method. I already have button state management code in the Undo event handler. Calling the Undo method fires the Undo event.

I'll probably run into some other quirks, but at least I've got something to work with. Thanks!

jleach · Dec 12, 2017

Just out of curiosity, why not use the AfterUpdate event? I wouldn't imagine you're editing treeview nodes based on the specific characters in the textbox, but rather after they've committed the value?

dpm · Dec 12, 2017

I am creating new tree nodes based on the text in a pair of textboxes, actually. I do plan to make use of AfterUpdate at some point. However, it is the wrong event in which to validate/correct user input.

And it is that validation/correction I'm working on at the moment.

I have studied the bug in some detail - it is pretty nasty, as it affects both bound and unbound TextBox. I have sent Microsoft the following...
---------------------------------------------------------------------------------------

TextBox has a bug or bugs. Unknown if previous versions are affected.

To reproduce the issue:

01. Create a new Form
02. Place a Textbox on the Form
03. Open the Form
04. Type a character into the TextBox
05. Press Ctrl-Z
06. Type a character into the TextBox
07. Press Ctrl-Z

The TextBox's Change event does not fire.

08. Type a character into the TextBox
09. Press Ctrl-Z

The character is not removed from the TextBox.
The TextBox's Change event does not fire.

10. Continue to hold down Ctrl-Z or press it again.

The TextBox's Change event does not fire.

11. Close the Form.
12. Repeat steps 03 through 07
13. Close the Form
14. Open the Form
15. Type a character into the TextBox
16. Press Ctrl-Z

The character is not removed from the TextBox
The TextBox's Change event does not fire.

17. Continue to hold down Ctrl-Z or press it again.

The TextBox's Change event does not fire.

jleach · Dec 12, 2017

Typically the BeforeUpdate event is used to validate, although Change is nice for more immediate stuff, but still the control's BeforeUpdate would be the final test.

I'll verify the bug amd can send it directly to the Access team. Cheers

dpm · Dec 13, 2017

Thank you, jleach. That would be much appreciated.

Agreed, BeforeUpdate is the place for validation (after the fact, so to speak).

My goal is to manage the state of a nearby button. If either of two textboxes contained invalid data, the "Add" button is disabled. Once valid, the "Add" button is enabled. When the "Add" button is clicked, the new Node is added to the Treeview. This sort of thing needs to be done before the BeforeUpdate and AfterUpdate events fire. In other words, before the TextBox loses focus, or is exited.

Since the TextBox is bugged, I will have to resort to using Before/AfterUpdate events, along with an "Add" button that is always enabled. It is very unprofessional, but I'm stuck for now.

dpm · Dec 13, 2017

One thing is not clear in the steps to reproduce the issue.

12. Repeat steps 03 through 07

This is done to demonstrate that the conditions that allow the bug to exist are not reset when the Form is closed. In other words, if I close the Form before issuing the third Ctrl-z, then reopen the Form and attempt the same basic thing - typing a char into the TextBox and hitting Ctrl-z - the bug occurs immediately, rather than after the second use of Ctrl-z.

In short, it is possible that the bug is not restricted to the TextBox code, and TextBox may not be the source of the bug at all. The Undo Typing code is probably involved in some way, and may be the sole source of the bug.

Pat Hartman · Dec 13, 2017

The bug happens for me also.

The_Doc_Man · Dec 13, 2017

Did a little research. Seems that an input of the ^z character caused trouble 12 years ago, too.

https://bytes.com/topic/access/answers/202331-diffficulty-w-eof-character

It is possible that Access is reading that as its original ASCII meaning - <EOF> - used as a file separator when dealing with continuous character streams. If so, we have to ask if maybe the characters being sent to Access are being fielded by a "handle" open to a unit-record device. Remember that, at least in theory, a handle can be opened to ANY device that can produce a byte stream. (OK, I'm sure there are exceptions - but I'm not going to bet that a keyboard is one of them.)

So would it make sense that the <EOF> character closes the handle and forces Access open a new one to the same device? Just speculating here. And I have no clue as to why the work-fail or work-work-fail pattern described.

isladogs · Dec 13, 2017

Just tried in both Access 2010 & 2016 32-bit

The bug occurs for me in both versions with Ctrl-Z clearing the textbox the first 2 times but not the third.

BUT if I then repeat Ctrl -Z input, the textbox is cleared in both cases

The_Doc_Man · Dec 13, 2017

The interesting test is if you could normalize the Access window and have a copy of the performance manager open to show you handle changes, you might see a change in the number of handles (for a moment) when you used ^Z in the text box.

dpm · Dec 14, 2017

@The Doc Man

Great. This means it'll never be fixed.

I thought perhaps I could simply cancel any use of Ctrl-z in the KeyDown event, but the bug occurs in precisely the same fashion if, instead of using Ctrl-z during the steps to reproduce it, I use the Undo Typing button in the Quick Access Toolbar.

I'll have to scrub around some more, when I have time.

dpm · Dec 14, 2017

ridders said:
Just tried in both Access 2010 & 2016 32-bit

The bug occurs for me in both versions with Ctrl-Z clearing the textbox the first 2 times but not the third.

BUT if I then repeat Ctrl -Z input, the textbox is cleared in both cases

Yep, same here - or just continue holding Ctrl-z down on the third try; the keyboard spams another Ctrl-z.

Question Strange TextBox Behavior (1 Viewer)

dpm

Registered User.

jleach

Registered User.

dpm

Registered User.

dpm

Registered User.

jleach

Registered User.

dpm

Registered User.

jleach

Registered User.

dpm

Registered User.

dpm

Registered User.

Pat Hartman

Super Moderator

The_Doc_Man

Immoderate Moderator

isladogs

MVP / VIP

The_Doc_Man

Immoderate Moderator

dpm

Registered User.

dpm

Registered User.

Similar threads

Users who are viewing this thread