Thank you for the compliment. I try and keep things simple. I want others to be able to do the same thing as I'm demonstrating. I'm not the type of person trying to seem smarter or better than others. I'm simply trying to share information to elevate others.
In the first approach, perhaps I'd set the frm_saveRecord =false in the BeforeUpdate event, to prevent save the record twice if it the same record is modified after saved, and after the second modification, "save" Is not pressed
Yeah, and as usually, better to put this in a Class, so u than have just one line code in ur form. btw, b havior on this kind of solution by OnCurrent: Me.cmd_Save.Enabled = False This will create an error, when the control has the focus, so always set the focus on a control that is always avaible. Or set the focus only if u have to with this: SetPropertyConditional Me.cmd_Save, "Enabled", False, me.MyMail Here is the fct: Public Function SetPropertyConditional(obj As Control, prpName As String, Content As Variant, Optional EvasiveControl As Control) As Boolean Dim i As Byte On Error Resume Next For i = 0 To 1 If Not obj.Properties(prpName) = Content Then obj.Properties(prpName) = Content If Err.Number = 0 Then SetPropertyConditional = True Exit For End If EvasiveControl.SetFocus Err.Clear Next End Function
Classes are great and, yes, this would be a great application, but not everyone uses them so I kept the example simple and accessible to all. As for getting an error, it hasn't ever cause such an issue to date.
The button has to have the focus at that moment in time, yet no error. Not a bad idea to set the focus back into the detail section or previous control. Something to explore. As always, I present the basics, try help novice developers, there will ALWAYS be room for improvement!!! (this is true of all code, without exception!) Nice dig though! I sleep quite fine at night thank you.
@@DanielPineault The fact that dirty=false requires error handling should be clear to anyone who is not a complete beginner. I was concerned here with the classic non-obvious error that will catch up you one day. The quick solution of putting an on error resume next before enabled=false should not overwhelm the audience. Class-programming should, I agree with you. In my opion the whole topic is important and very clearly presented. All my forms in this view are structured in this way and the user experience has improved significantly.
The problem is when you have to save invoice, you have invoice number, date of invoice etc.. and then you have items in that invoice. You need master details form and how to make save together or cancel changes. You gonna need temporary recordsets, or temporary tables. In multi user environment it can be chalenge.
It's a simple but beneficial approach. Thanks!!!
Your most welcome.
Awesome and well explained Thankyou
Glad you liked it.
You teach with simplicity
Thank you for the compliment.
I try and keep things simple. I want others to be able to do the same thing as I'm demonstrating. I'm not the type of person trying to seem smarter or better than others. I'm simply trying to share information to elevate others.
Easy way but great idea, thanks so much.
Always a pleasure.
TKS. Solves a huge problem for me. Looking at making a sub Class Module as there is many forms that i will have to change.
This is a great use of a subclass. If you haven't already seen it, look at
www.devhut.net/converting-form-code-to-a-reusable-class-module/
Thanks for this. Do you also have a workaround for continous forms?
This approach works for continuous forms.
Thank you
My pleasure.
In the first approach, perhaps I'd set the frm_saveRecord =false in the BeforeUpdate event, to prevent save the record twice if it the same record is modified after saved, and after the second modification, "save" Is not pressed
👍
👍🏻👍🏻👍🏻
Thank you.
Yeah, and as usually, better to put this in a Class, so u than have just one line code in ur form.
btw, b havior on this kind of solution by OnCurrent: Me.cmd_Save.Enabled = False
This will create an error, when the control has the focus, so always set the focus on a control that is always avaible.
Or set the focus only if u have to with this: SetPropertyConditional Me.cmd_Save, "Enabled", False, me.MyMail
Here is the fct:
Public Function SetPropertyConditional(obj As Control, prpName As String, Content As Variant, Optional EvasiveControl As Control) As Boolean
Dim i As Byte
On Error Resume Next
For i = 0 To 1
If Not obj.Properties(prpName) = Content Then obj.Properties(prpName) = Content
If Err.Number = 0 Then
SetPropertyConditional = True
Exit For
End If
EvasiveControl.SetFocus
Err.Clear
Next
End Function
Classes are great and, yes, this would be a great application, but not everyone uses them so I kept the example simple and accessible to all.
As for getting an error, it hasn't ever cause such an issue to date.
@@DanielPineault if ur button has the focus, u will get the error. If it can happen, it will happen. But everyone has their own quality standards.
The button has to have the focus at that moment in time, yet no error. Not a bad idea to set the focus back into the detail section or previous control. Something to explore. As always, I present the basics, try help novice developers, there will ALWAYS be room for improvement!!! (this is true of all code, without exception!)
Nice dig though! I sleep quite fine at night thank you.
@@DanielPineault The fact that dirty=false requires error handling should be clear to anyone who is not a complete beginner. I was concerned here with the classic non-obvious error that will catch up you one day. The quick solution of putting an on error resume next before enabled=false should not overwhelm the audience. Class-programming should, I agree with you. In my opion the whole topic is important and very clearly presented. All my forms in this view are structured in this way and the user experience has improved significantly.
The problem is when you have to save invoice, you have invoice number, date of invoice etc.. and then you have items in that invoice. You need master details form and how to make save together or cancel changes. You gonna need temporary recordsets, or temporary tables. In multi user environment it can be chalenge.