Double "Esc" to undo new record - ideas? (1 Viewer)

Rx_

Nothing In Moderation
Local time
Yesterday, 18:40
Joined
Oct 22, 2009
Messages
2,803
My client does not like commnad buttons.
Three combo list boxes - 3 required fields
Add New Record - 3 required fields from Combo list box are populated
Once user tabs to field 4, the first 3 are "locked" and the rest of the form's controls are unlocked.
Should mention there is a autocounter and a customerID from a hidden text box in the NewRecord.

Question:
During edit, an individual "Esc" key will undo the text in the combo list box that has the focus.
The client wants a "double Esc" to stop the AddNew
and to go back to the orginal record.

A form boolean "AddRecordInProgress" is used for other process to understand when something is being added.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 01:40
Joined
Sep 12, 2006
Messages
15,634
everybody says that sendkeys should not be used, but i often do

sendkeys "{esc}" to send an escape

so you could either do this

sendkeys "{esc}{esc}", or send it twice.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 01:40
Joined
Sep 12, 2006
Messages
15,634
just with XP, Bob. Is it no longer functional under newer OS?
 

boblarson

Smeghead
Local time
Yesterday, 17:40
Joined
Jan 12, 2001
Messages
32,059
just with XP, Bob. Is it no longer functional under newer OS?

Yes, that is the situation. I guess it has to do with it not fitting with the security. So, if you are using them, it would be good to be planning on how you will move away from that when the time comes to move off of XP. Of course that could be quite a length of time in the future but it is something to be wary of as you move forward.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 01:40
Joined
Sep 12, 2006
Messages
15,634
thanks

docmd.undo then!

i think the problem was that .undo didnt seem to work in a before update event, but sending {esc} did - or i recollect something like that, anyway.
 

Rx_

Nothing In Moderation
Local time
Yesterday, 18:40
Joined
Oct 22, 2009
Messages
2,803
Great Discussion! Thanks so much.

Well, the customer is on XP and the IT staff is not looking at Windows 7 for about 8 months. Maybe I will give the send key a try for today.
Some nice comments can be added for the next temp contractor.
(or if it is me, a good mental reminder).

The client is completely against using command buttons and want every thing done on keystrokes and focus change. Already using the hidden command buttons. Just calling the subs. Was wondering if it made any difference to call it a different way or not. Hidden command buttons help me keep organization (and sanity).

Just for the sake of possibilities of Windows 7 on Access 2007:
Would it be feasible to put a timer event at the Form level that would measure two Esc key strokes in under one second?
Thinking of maybe intercepting a key stroke, evaluating it in a loop counter, that resets via some timer ? If it is one Esc, behave on the field level, it it is two Esc then call the me.undo (and probably refresh my form based on if it was a first record or more.

Thanks again for a very valuable discussion.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 01:40
Joined
Sep 12, 2006
Messages
15,634
as far as the client goes, there is a limit to things that can be run just from a event handler.

virtually every app uses command buttons somewhere or other, doesnt it?

------------
As I say, i think if you try to intercept and manage programmes at the keystorke level, you will make things very difficult for yourself.

One resource you may have is autokey macros

these are ctrl+character, which can be intercepted and reprogrammed to do a variety of tasks. The autokey macros do this for you without you needing to programme keypresses at all. Just assign the ones you want to use.
 

LPurvis

AWF VIP
Local time
Today, 01:40
Joined
Jun 16, 2008
Messages
1,269
>> just use me.undo instead of DoCmd.Undo

Although it's actually DoCmd.RunCommand acCmdUndo - that's not my point.
They're not the same thing - and although it's often better practice to use the object specific method (for example the exact equivalent situation in record navigation is better with Me.Recordset.MoveFirst than, say, DoCmd.GoToRecord acDataForm, "Form",acFirst) the DoCmd method has slightly further reaching scope in its ability to undo retrospective changes.
That's not entirely likely to be an issue - but it could be (bear in mind that it's the next level to try when Me.Undo just isn't cutting it).
Of course, nothing can undo the full commit that is explicit save command or sub/parent form focus change.

Anyway...
The Escape Key is pretty simple.
We're talking about a form which isn't using standard binding I presume (such that Escape key has no special meaning here)?
It's just a question of performing a special function upon the action (clear, enable combos - navigate to another record for example).

Code:
Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    
    Static sglTimer As Single
    If KeyCode = 27 Then
        DoCmd.CancelEvent 'escape form action - just in case
        If Timer - sglTimer < 0.5 Then
            'Done!! Perform your action here
            ResetDataControls
            sglTimer = 0
        Else
            sglTimer = Timer
        End If
    End If
 
End Sub

Since that's a form level event - you'll need to specify the Key Preview property to be True (Yes) in your form design view.

Cheers.
 

LPurvis

AWF VIP
Local time
Today, 01:40
Joined
Jun 16, 2008
Messages
1,269
Oh, and as the designated expert to whom the client is paying good money - it's your role to not only give them the result they want, but also advise as to good practice and what is of benefit to them (from a development time/cost perspective too).
i.e. Don't be too frightened to tell 'em what's what. :)

Key event driven UIs can be efficient for those fluent in them - but they're not the norm in modern software. Avoiding them for the sake of it (an irrational distaste) isn't a good use of resources.
Having them there to help new users makes sense.
If the client wants to also pay for time to implement the key events implementations then so be it - to assist the more keyboard oriented members of staff.

Cheers.
 

Rx_

Nothing In Moderation
Local time
Yesterday, 18:40
Joined
Oct 22, 2009
Messages
2,803
Outstanding!
I used the form's key press event, rather than the key down, please let me know if there is any up or down side for that choice.

Had already implemented code very close to this.
i.e. keep a bookmark before the NewRecord is chosen, go back to it on the double Esc and call on a module to implement the Forms's business rules for the recovered record... and so on.

The customer is pleased. Actually very pleased. Previoius "programmers" Used less than ten lines of code per form and the percent of incomplete required fields in records was double digits.

As suggested, the use of invisible commnad buttons for the Cancel
Record, and other commands the customer wants either Tab event driven or Key driven (i.e. Esc) was my standard. One question: is calling the code in a command button's click event equal to actually clicking the button?

Fantastic inputs and considerations. It is very appreciated. When working solo on a project, the practical inputs and timely suggestion at this forum are the best in the world.
 

LPurvis

AWF VIP
Local time
Today, 01:40
Joined
Jun 16, 2008
Messages
1,269
In this instance there's no downside to the change in events.
In other scenarios, the KeyCode parameter catches all key values whereas there isn't always an ASCII code for the key in question (as is the case in KeyDown).
(But Escape is 27 in both here).

I'm not entirely clear on what you're then saying.
>> Had already implemented code very close to this.
i.e. keep a bookmark before the NewRecord is chosen, go back to it on the double Esc and call on a module to implement the Forms's business rules for the recovered record... and so on.
Wasn't the whole point of this thread just the "on the double Esc" part? The rest, as mentioned, is to be implemented however you need to or probably already do.

And are you saying you used to implement hidden command buttons with Cancel property set - but couldn't here because of the double key press requirement?

>> is calling the code in a command button's click event equal to actually clicking the button?
Well, yes and no.
Yes, in that the same code will run, probably identically to if the button had been clicked (if you've not included any code assumptions about the active control).
No, in that the button event itself isn't raised (and UI effect actioned). You're just calling the event procedure I presume yes?
Call cmd_Thingy_Click
So both events call the same procedure - think of it that way.

>> When working solo on a project, the practical inputs and timely suggestion at this forum are the best in the world.
Well... you know...

You're welcome. :)
 
Last edited:

Rx_

Nothing In Moderation
Local time
Yesterday, 18:40
Joined
Oct 22, 2009
Messages
2,803
Yes, the suto code is a great representation of my solution.
Of course, for the sake of a forum, the details of my specific form were omitted.

Thanks for the update on the two key events. I suspected for this specific case, it made no difference. However, it never hurts to ask and learn.

And yes, a CancelNewRecord command button was created with visible = false. The customer does not want to see a comand button for this. They want the Esc Esc. So, the code in my CancelNewRecord is called. In design mode if I come back to revisit this 3 months from now, it just adds a visual reminder and a quick way to view the code.
 
Last edited:

G37Sam

Registered User.
Local time
Today, 04:40
Joined
Apr 23, 2008
Messages
454
I was also using the sendkey method but it wasn't very convenient, thanks to this thread I'm now using me.undo

Cheers,
 

Users who are viewing this thread

Top Bottom