Solved Key Events - Ctrl-Delete UnDetected

The thought occurs to me that "CTRL/DEL" is a keyboard shortcut for "delete word to right of cursor" which means it MIGHT be pre-empted for program use, particularly since the change to references a couple of decades ago that rearranged libraries. VBA stopped being "built-in" and became just another DLL that EVERY Office utility could use. Can't remember WHEN that happened, but VBA got changed to make it uniform across the Office spectrum.
I think VBA partially became a DLL with the release of Office 2007 (VBA Version 6), along with other major changes, such as accdb format, etc.
 
Thanks isladogs, yeah I know what's going on. He got it to me real quick & is just to show how to hook the key-combination. I've got lots of other stuff going on & handling the deletion through my procedures. I never stipulated any of that. Thankfully Arnel used his intuition on creating a subform & correctly assumed it was relating to a recent thread.

The biggest concern is why the test was showing the incorrect keys on test as @Imb pointed out. That is deeply worrying. I'm most grateful for his solution as I never really understood what the Timer was for, not to mention the bigger problem at play.
 
I think VBA partially became a DLL with the release of Office 2007 (VBA Version 6), along with other major changes, such as accdb format, etc.

Thanks for the reminder. My tired old brain remembered the change but not when it actually happened. Mostly because it had no effect on my work at the time, but later on a few differences WERE noted, mostly reference issues. By now, long ago resolved, but I was wondering if that interpretation of CTRL/DEL had become "global" by being part of the library.
 
Thanks for the reminder. My tired old brain remembered the change but not when it actually happened. Mostly because it had no effect on my work at the time, but later on a few differences WERE noted, mostly reference issues. By now, long ago resolved, but I was wondering if that interpretation of CTRL/DEL had become "global" by being part of the library.
Sorry but I still do not understand what you are referring to here
The built-in VBA library has been based on different versions of the VBE.dll file for as long as I can remember

In Access 2000, it is the first item in this list of references:
Code:
REFERENCES
-------------------------------------------------
Description: 'Visual Basic For Applications', Name: 'VBA', FullPath: 'C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL', Guid: {000204EF-0000-0000-C000-000000000046}, Type: '0', BuiltIn: True, IsBroken: False, Major: 4, Minor: 0
Description: 'Microsoft Access 9.0 Object Library', Name: 'Access', FullPath: 'C:\Program Files\Microsoft Office\Office\MSACC9.OLB', Guid: {4AFFC9A0-5F99-101B-AF4E-00AA003F0F07}, Type: '0', BuiltIn: True, IsBroken: False, Major: 9, Minor: 0
Description: 'OLE Automation', Name: 'stdole', FullPath: 'C:\WINDOWS\System32\stdole2.tlb', Guid: {00020430-0000-0000-C000-000000000046}, Type: '0', BuiltIn: False, IsBroken: False, Major: 2, Minor: 0
Description: '', Name: 'utility', FullPath: 'C:\Program Files\Microsoft Office\Office\1033\utility.mda', Guid: , Type: '1', BuiltIn: False, IsBroken: False, Major: 0, Minor: 0
Description: 'Microsoft Visual Basic for Applications Extensibility 5.3', Name: 'VBIDE', FullPath: 'C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB', Guid: {0002E157-0000-0000-C000-000000000046}, Type: '0', BuiltIn: False, IsBroken: False, Major: 5, Minor: 3
-------------------------------------------------
5 references found, 0 broken.

In Access 97, it is VBE.dll v5.04.41.21 in C:\Program Files\Common Files\Microsoft Shared\VBA. Once again, built-in and shared across the whole of Office

The first version of Access with VBA was Access 95. In that version the VBA library was a .olb file at C:\WINDOWS\system32\ven2232.olb.
I haven't been able to check whether that library also applied to other Office apps such as Excel etc
 
There was a time when a format change affected Access's VBA when it would NOT affect Excel's VBA because VBA had a different structure than it does now. Some time after I started with the Navy, we got to the point that if you diddled with the VBA-page edit options in Excel, those changes popped up in Access - but before that moment, they did not. In other words, I recall a time when VBA was NOT uniform across the components of Office. BlueSpruce seems to remember as well that VBA changed in some way. My freaky memory says it happened and I can offer the details of how things changed, though I'll be honest: At the time, I wasn't quite as interested in the mechanics of the situation.

Where this relates to the thread topic is that CTRL/DEL has special meaning to Office members and therefore it is POSSIBLE (and I admit, speculative) that a different layer of Access is intercepting that keystroke combo as a keyboard shortcut, which is why you don't see the event. Do you see the CTRL/ALT/DEL keyboard event or does Windows intercept it? I believe that CTRL/ALT/DEL is considered a "secure" method of obtaining control of the session's security page. (Might have incorrect nomenclature here.) I offer the speculation that something deeper in the stack is intercepting CTRL/DEL, perhaps when the app is in a state or context where that shortcut has a meaning. Because it is intercepted and acted upon, you do not get the event for CTRL/DEL.
 
a format change affected Access's VBA when it would NOT affect Excel's VBA because VBA had a different structure

Classic example of that was when the XML storage format was introduced in 2007, e.g. (mdb to aacdb, xls to xlsx). Access and Excel store their vba projects and object models differently. A file format change can affect one but not the other.

IIRC, when we migrated an Access 97 app to 2016, we had to go from 97 (VBA5) to 2000 (VBA6) refactor code and recompile even though they were both mdb's, then to 2003 (VBA 6.4) refactor/recompile again, still mdb, then 2007 (VBA 6.5) recompile, now accdb format, and straight to 32-bit 2016.

Does Access see CTRL/ALT/DEL keyboard event, or does Windows intercept it?

Windows always intercepts Ctrl+Alt+Del combination, not individual applications, including Access. It's a security feature named Secure Attention Sequence, which is trapped as a CPU interrupt and the Windows kernel receives it to prevent malicious applications from faking login screens and capturing passwords. Ctrl+Alt+Del is the only key combo that Windows always intercepts. Ctrl+Del is detected by Access, albeit some time delay needs to be introduced in the event to ensure it doesn't slip through unnoticed.
 
Last edited:
@BlueSpruce - actually, my question was rhetorical. I knew about the Secure Attention Sequence and knew it would be intercepted. I'm just wondering if some of the problems in this case were ALSO an intercept case. You suggest that they make it through, though there is a delay involved. Thanks for clarification.
 

Users who are viewing this thread

Back
Top Bottom