Windows gui: How to prevent keyboard buffer getting cleared

Posted by cverbiest on 27-May-2016 07:37

Hi All,

We detected this issue during a customer upgrade. In our new version characters in the keyboard type ahead buffer are no longer processed.

Details

oe11.5.1, windows 2012 r2, rdp & citrix clients.

The previous version is running on the same server using the same OpenEdge version.

At this site there are a couple of users who are fast at keying-in new orders, they enter item numbers and amounts faster than our software records it.

In the previous version this posed no problem because all characters got recorded in the keyboard type ahead buffer and these were processed eventually.

In our upgraded version characters are lost , they are either not recorded or the contents of the type ahead buffer is cleared.

Are there things we can do in ABL(.Net) that influence the keyboard type ahead buffer behaviour ?


we we're calling LockWindowUpdate at certain points I already removed those but that doesn't seem to make a difference

All Replies

Posted by Garry Hall on 27-May-2016 08:50

Is this the same version of the app running on a newer OE, or did the app get upgraded as well, so that it is using newer features (e.g. .NET UI)? If it is the same app, what was the older OE version?

This will probably result in a Tech Support call, but some suggestions for investigation would be:

- using PROEVENTS.*:4 logging, to see if you are getting the key events

- using Spy++ to see what messages are sent, to compare to what PROEVENTS logging reports

I have nothing usable to offer at the moment, just a vague guess this might be an unintended side-effect of changes to message handling to address bugs. But if this is not the same app, and is using different UI components, then the suggestions above are possibly irrelevant.

Posted by Brian K. Maher on 27-May-2016 11:32

Add 4GLMessages to the logentrytypes then add a message “hello” view-as alert-box statement as the first line of code in the .p pointed to by the –p startu parameter.

Posted by Matt Gilarde on 27-May-2016 13:08

Try setting MTIDiscardMessages=no in the Startup section of the registry or ini file. This setting enables a fix that was disabled because it caused issues with some applications. If this setting does resolve the issue you should do comprehensive testing before putting it into production. As Garry said, there are sometimes unintended consequences when we fix message-handling bugs. It's possible that MTIDiscardMessages=no could fix this problem but cause other problems in the application.

Posted by cverbiest on 12-Jan-2017 08:43

Hi all,

sorry for not responding to your suggestions, the notification mails on this, and other, question(s) got redirected to a folder that now contains 7500 unread mails.

[mention:a387dc18957841c098637f5e31360c01:e9ed411860ed4f2ba0265705b8793d05] I started Spy++ but I have no idea how to use this tool . I started logging everything for the keyboard

[mention:43713cf888d84bdcb3637e465ffa1de6:e9ed411860ed4f2ba0265705b8793d05] What is tHe function of the message statement, should it trigger something ?

[mention:931f7f12516e4daa930b60341926d260:e9ed411860ed4f2ba0265705b8793d05] Ill try MTIDiscardMessages=no, what kind of issues should we be looking out for when we change this parameter

Posted by Matt Gilarde on 12-Jan-2017 09:25

> Ill try MTIDiscardMessages=no, what kind of issues should we be looking out for when we change this parameter

MTIDiscardMessages affects how the AVM processes the messages it receives from Windows so the effects can be wide ranging. I would look for issues when painting forms or windows, issues with asynchronous AppServer calls, and issues with UI responsiveness. Of course, this only matters if changing the setting actually helps.

Posted by Brian K. Maher on 12-Jan-2017 10:50

Carl,
 
I think I replied to the wrong post as my comment makes no sense in the context of your problem.  <smile>
 
Brian

This thread is closed