cheekybuddha
AWF VIP
- Local time
- Today, 03:18
- Joined
- Jul 21, 2014
- Messages
- 2,745
It doesn't when you look at Access documentation.Why does M$ keep calling VBA code "macros" in the documentation?
In Excel, VBA is called macros.
It doesn't when you look at Access documentation.Why does M$ keep calling VBA code "macros" in the documentation?
That will be office documentationWhy does M$ keep calling VBA code "macros" in the documentation?
for those who have simple requirements and don't want to learn VBABut then, you have to ask, why did the "experts" that created Access create so many different macro actions?
never heard of it, but definitely for a new thread. Not clear whether this is a service like onedrive/google drive or a net based rdbms. If the former, then no it won't work and if the latter an access FE should be able to connect to it providing it is ODBC compliant. Wouldn't have thought it was of interest to you since your objective is to avoid anything that relies on the internet.Oh, oh, oh I'm curious if anyone has tried an Access BE on Amber (product on Amazon) just for fun? That should be a new thread I suppose.
Okay, I understand, a lot of times I don't understand other's code either. That's the way it is.It only jumped to the new record once. All other attempts it went to record 4 of 7, 7 of 15, etc. F8 is no help as it seems to be endless going thru loops like crazy.
Pretty much all of it. I'm pretty active on several forums and most code I can follow. Yours not so much.
Amazon.com: AMBER X Smart Personal/Home Cloud Storage Device for Data and Media Files, Built-in 512GB High-Speed SSD with USB Storage Expansion, iOS/Android/Windows/Mac Compatible, Black : Electronicsnever heard of it, but definitely for a new thread. Not clear whether this is a service like onedrive/google drive or a net based rdbms. If the former, then no it won't work and if the latter an access FE should be able to connect to it providing it is ODBC compliant. Wouldn't have thought it was of interest to you since your objective is to avoid anything that relies on the internet.
I've seen it many times over the years. I'll keep an eye out and post back next time I see such a macro reference for VBA in M$ documentation.It doesn't when you look at Access documentation.
In Excel, VBA is called macros.
No, I set the break in the beginning of the code and had to hit F8 for 10 minutes.Are you saying you're getting caught in a real endless loop?
Ya should have probably said that first.Yes, string array manipulations are all about loops, you can easily set a break-point for after their execution to avoid the loops.
Not sure why you are using Option Compare Binary. All the rest can be read in post #66
I don't know what to say. Even if I don't stand on the F8 key, it takes me less than 60 seconds to get through the all the routines. Now, if you're reading each line of code in a loop over-and-over again after the first iteration...No, I set the break in the beginning of the code and had to hit F8 for 10 minutes.
Ya should have probably said that first.
I'm talking about how we read. We are much more efficient with tall, thin text than short, wide text. Also, you can alphabetize the tall, thin and you wouldn't bother with the short, wide. And if you're defining 50 variables, you are probably doing too much in the procedure.You can have 50 lines of dims or 10 rows with multiples in a complex program, I'm not one for scrolling through pages of Dims. But to each their own.
Correct. My view of arrays comes from COBOL tables where all the rows were the same data type just like an actual table and could actually include multiple fields per "row". To do that with VBA, you need a multidimensional array. But making arrays of disparate fields simply makes no sense even though you can do it.I'm not sure what to say about your observations on arrays. There's nothing that says arrays have to be "same data types".
That IS the problem. The copied record which is meaningless since it is a duplicate, has already been saved. The macro code copies the code into a new record that you are now positioned on but leaves the record dirty because it has not yet been saved and it is still under the control of the form. If you think about the code that the macro generates it is more like - move to a new record, copy field by field, give focus back on the new record. Whereas the suggested three lines is copy, paste append (which adds a new record and saves it), move to new record. As I said, I find so little need for this type of code that I've never experimented with it. I'll see if I can copy, move to new record, then paste (just plain paste rather than paste append). That should leave the new record dirty. Of course it doesn't fit with what you want to do.I'm confused about the problem with the new record being dirty comment. In the test I just did with a modified TWG.accdb, it doesn't go dirty until a textbox is changed.
That field is changed by your copy code, NOT by the BeforeUpdate code. You are using DAO to save the record, NOT the form so the form events don't run.You can clearly see on the form that the update stamp changes to a new date when saved, so it had to run to do that.
But it included "how to find the ID" which is how we got to the copy part. The only reason you don't know the ID is because you just pasted a new record."How can I "move" to that new record in the same open form with VBA ?" Notice that the question doesn't include how to copy.
The form failed for me the first time also. I wasn't stepping through the code so I don't know what happened either.More importantly, I'm curious where the form copy is failing for you.
Option Compare Database
Option Explicit
Public FormFields(1 To 255) As Variant
Public Function LoadFormFields(frm As Form)
Dim ctl As Control
For Each ctl In frm.Controls ''' Remember - do NOT tag the PK. It can't be copied. Also, don't tag any field with a unique index
If IsNumeric(ctl.Tag) Then
FormFields(ctl.Tag) = ctl.Value
End If
Next
End Function
Public Function FillFormFields(frm As Form)
Dim ctl As Control
For Each ctl In frm.Controls
If IsNumeric(ctl.Tag) Then
ctl.Value = FormFields(ctl.Tag)
End If
Next
End Function
Private Sub cmdCopy2_Click()
WhichCode = 1
DoCmd.RunCommand acCmdSaveRecord
If Me.EntityID & "" = "" Then
MsgBox "Please select a record to copy.", vbOKOnly
Exit Sub
End If
Call LoadFormFields(Me)
DoCmd.GoToRecord , "", acNewRec
Call FillFormFields(Me)
End Sub
Private Sub Form_BeforeUpdate(Cancel As Integer)
If WhichCode = 1 Then
Me.UpdtUserId = 111
Me.UpdtPgm = Me.Name
Me.UpdtStmp = Now()
Else
Dim temp1 As Variant
gSp(1) = "": gSp(2) = 81
Call sFormProc(FrmNm)
End If
WhichCode = 0
End Sub
common to do that with instr()What can we do if the tag field is already used for something else like language translation?
No, but I told you how to change it. Instead of looping through the controls, you loop through the ControlSource. But beware, Access forms are now acting like Reports where the Access elves are being smarter than we are and rewriting the RecordSource to discard fields not bound to controls. So, if you don't bind a field to a control, Access might remove it from your control source when you least expect it because it is trying to make your SQL efficient.Will it copy fields from the record that aren't in the form, but are in the record, to the new copy record?
That is done with an append query that copies the common fields but replaces the ones that change such as the date with a new value. You would never have to visit each record MANUALLY in order to have it processed by a form.Each step in the process has its own record that spawns a new record in a different table for the succeding life cycle record.
When you say elves, do you mean the coders at M$ that are maintaining Access?... where the Access elves are being smarter than we are and rewriting the RecordSource to discard fields
And you were given the solution in the first few responses.For the copy, I just wanted to move to the new record, and it was a given in the post that I knew the ID of the new copy record
Trick question as it seems you keep moving the goal post and your existing code makes little sense to many of us.Will your design handle this data processing reality?
That is no longer copying data in the form, it is copying the record in the table.Will it copy fields from the record that aren't in the form, but are in the record, to the new copy record?