必须使用宏！我该如何遵守？ [英] Must use macros! How shall I comply?
问题描述
因为我的工作区明年没有Access程序员，我已经要求
重建他们的编码应用程序作为一组模块化
工具。这个想法是非程序员能够修改它，因为
要求发生变化。
更一般地说，事实上，他们想要一个通用的功能包$>
将预计*所有*要求。
必须将它们称为宏。
我能体会到这一点很简单操作顺序可以是
使用宏方便地串在一起。
我有一个想法是沿着将电子表格加载到表格这一行的宏/>
，带有验证错误可能有用。这基本上是像带有一些额外控件的TransferSpreadsheet那样的b $ b，有助于更好地确定错误。
然而，我的经理想要更多原子这个函数不是这个。
类型为IsAlpha的验证函数。例如。他希望
来验证每个记录中的字段，然后再将它们呈现给
表，其中定义了这些类型和其他约束。这些是由宏控制的
。
正如我所看到的，这使得非程序员处于使用
$ b的位置$ b宏循环。
我自己编码很困难：例如，表格结尾
条件不能直接测试。我写了一个（VBA）函数
[下面的DoMacroOverTable]来接受一个宏和一个表，并为表中的每个记录应用宏b $ b。而且，虽然我可以将
表格作为当前对象。并使用GotoRecord更改当前
记录，我无法看到（在被调用的宏内）如何引用此
记录或其中的字段它（没有为
定义表格和字段）。
任何想法？
此外，到目前为止，我已经失去了对我对此b / b
特定策略提出异议的论点。 （当
声明为表属性和参照完整性约束时，许多这些测试的冗余;
更适用于选择或更新查询的应用程序
比在宏中）。如果有人可以提供他们的推理（无论哪种方式！）
它可以帮助我。
公共函数DoMacroOverTable（sMacro As String，sTableName As
String）
DoCmd.SelectObject acTable，sTableName
DoCmd.GoToRecord ,, acFirst
On Error GoTo DoMacroOverTableErr
Do to False
DoCmd.GoToRecord acActiveDataObject ,, acNext
DoCmd.RunMacro（ sMacro）
循环
退出功能''从未到达过！
DoMacroOverTableErr：
如果错误= 2105然后
''预计
否则
MsgBox"意外错误：" &安培; Err.Number& "：" &安培; Err.Description，
vbCritical，DoMacroOverTable
停止
恢复
结束如果
结束功能
（结束留言）
Because my work area won''t have an Access programmer next year, I''ve
been asked to rebuild their coded application as a set of modular
tools. The idea is that a non-programmer will be able to modify it as
requirements change.
More generally, in fact, they want a general package of functions that
will anticipate *all* requirements.
They must be called as macros.
I can appreciate that a simple sequence of operations could be
conveniently strung together using a macro.
I had an idea that a macro along the lines "Load Spreadsheet to Table
with Validation Errors" might be useful. This would essentially be
like TransferSpreadsheet with a few extra controls and helps to better
identify errors.
However, my manager wants more "atomic" functions than this.
Validation functions of the type "IsAlpha" for example. He would like
to validate fields within each record before they''re presented to the
table where these types and other constraints are defined. These are
to be controlled by macro.
As I see it, this puts the non-programmer in the position of using
macro loops.
I''ve had difficulty coding these myself: e.g., the end-of-table
condition can''t be tested directly. I wrote a (VBA) function
[DoMacroOverTable, below] to accept a macro and a table and to apply
the macro for every record in the table. And, whilst I could make the
table the "current object" and use GotoRecord to change the "current
record", I can''t see how (within the called macro) to refer to this
record or to fields within it (short of defining a form and fields for
it).
Any ideas?
Also, so far I have lost the argument on my objections to this
particular strategy. (Redundancy of many of these tests when
declarable as table properties and referential integrity constraints;
better application where applicable within select or update queries
than in macros). If anyone can supply their reasonings (either way!)
it may assist me.
Public Function DoMacroOverTable(sMacro As String, sTableName As
String)
DoCmd.SelectObject acTable, sTableName
DoCmd.GoToRecord , , acFirst
On Error GoTo DoMacroOverTableErr
Do Until False
DoCmd.GoToRecord acActiveDataObject, , acNext
DoCmd.RunMacro (sMacro)
Loop
Exit Function '' never reached!
DoMacroOverTableErr:
If Err = 2105 Then
'' expected
Else
MsgBox "Unexpected Error: " & Err.Number & ":" & Err.Description,
vbCritical, "DoMacroOverTable"
Stop
Resume
End If
End Function
(End Message)
推荐答案
大卫，非常认真，我会如果
某位经理坚持要我在Access工作，那就找个工作就业。
他显然不知道错误处理，验证检查您是否需要
每种形式的
，可重复使用的代码，多用户问题，记录集，灵活的
报告接受在运行时构建WhereConditon，记录
错误，类型检查，或任何其他能给你一个强大且可靠的
可靠应用程序。
如果那个人想告诉我*如何*我必须去实现结果
他不需要了解这些过程，我在浪费我的生命
那里。
-
Allen Browne - 微软MVP。西澳大利亚州珀斯。
访问用户提示 - http：// allenbrowne.com/tips.html
回复群组，而不是mvps dot org的allenbrowne。
David Powell <哒*** @ powell-au.net>在留言中写道
news：b5 ************************** @ posting.google.c om ...
David, quite seriously, I would leave a job and find employment elsewhere if
some manager insisted that I work in Access like that.
He clearly has no idea about error handling, the validation checks you need
in every form, reusable code, multi-user issues, recordsets, flexible
reporting that accepts builds the WhereConditon at runtime, logging of
errors, type-checking, or anything else that will give you a robust and
reliable application.
If that person wants to tell me *how* I must go about achieving the result
he needs when he has no understanding of the processes, I''m wasting my life
there.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"David Powell" <da***@powell-au.net> wrote in message
news:b5**************************@posting.google.c om...
因为我的工作区明年没有Access程序员，我已经被要求重建他们的编码应用程序作为一套模块化的工具。这个想法是非程序员能够随着需求的变化而对其进行修改。
更一般地说，事实上，他们想要一个通用的功能包来预测*所有*要求。
它们必须被称为宏。
我可以理解，使用宏可以方便地将一系列简单的操作串联在一起。
我有一个想法是沿着将表格加载到表格，带有验证错误这一行的宏。可能有用。这基本上就像TransferSpreadsheet一样，有一些额外的控制，有助于更好地识别错误。
然而，我的经理想要更多的原子。比这更有用的功能。
类型IsAlpha的验证功能。例如。他希望
在每个记录中的字段被提交到
表之前验证它们，其中定义了这些类型和其他约束。这些都是由宏控制的。
正如我所看到的，这使得非程序员处于使用
宏循环的位置。
我''自己很难对这些进行编码：例如，表格末尾的情况不能直接测试。我写了一个（VBA）函数
[下面的DoMacroOverTable]来接受一个宏和一个表，并为表中的每个记录应用宏。并且，虽然我可以使
表格成为当前对象。并使用GotoRecord更改当前
记录，我无法看到（在被调用的宏内）如何引用此
记录或其中的字段（缺少定义表单和
任何想法？
此外，到目前为止，我已经失去了对这个特定策略的反对意见。 （当作为表属性和参照完整性约束声明时，许多这些测试的冗余;
在选择或更新查询中适用的更好的应用程序比在宏中更好）。如果有人可以提供他们的推理（无论哪种方式！）
它可以帮助我。
公共函数DoMacroOverTable（sMacro As String，sTableName As
String）
DoCmd.SelectObject acTable，sTableName
DoCmd.GoToRecord ,, acFirst
On Error GoTo DoMacroOverTableErr
Do to False
DoCmd.GoToRecord acActiveDataObject， ，acNext
DoCmd.RunMacro（sMacro）
循环
退出功能''永远不会到达！
DoMacroOverTableErr：
如果Err = 2105那么
''预期
其他
MsgBox"意外错误：" &安培; Err.Number& "：" &安培; Err.Description，
vbCritical，DoMacroOverTable
停止
结束如果
结束功能
（结束）消息）
Because my work area won''t have an Access programmer next year, I''ve
been asked to rebuild their coded application as a set of modular
tools. The idea is that a non-programmer will be able to modify it as
requirements change.
More generally, in fact, they want a general package of functions that
will anticipate *all* requirements.
They must be called as macros.
I can appreciate that a simple sequence of operations could be
conveniently strung together using a macro.
I had an idea that a macro along the lines "Load Spreadsheet to Table
with Validation Errors" might be useful. This would essentially be
like TransferSpreadsheet with a few extra controls and helps to better
identify errors.
However, my manager wants more "atomic" functions than this.
Validation functions of the type "IsAlpha" for example. He would like
to validate fields within each record before they''re presented to the
table where these types and other constraints are defined. These are
to be controlled by macro.
As I see it, this puts the non-programmer in the position of using
macro loops.
I''ve had difficulty coding these myself: e.g., the end-of-table
condition can''t be tested directly. I wrote a (VBA) function
[DoMacroOverTable, below] to accept a macro and a table and to apply
the macro for every record in the table. And, whilst I could make the
table the "current object" and use GotoRecord to change the "current
record", I can''t see how (within the called macro) to refer to this
record or to fields within it (short of defining a form and fields for
it).
Any ideas?
Also, so far I have lost the argument on my objections to this
particular strategy. (Redundancy of many of these tests when
declarable as table properties and referential integrity constraints;
better application where applicable within select or update queries
than in macros). If anyone can supply their reasonings (either way!)
it may assist me.
Public Function DoMacroOverTable(sMacro As String, sTableName As
String)
DoCmd.SelectObject acTable, sTableName
DoCmd.GoToRecord , , acFirst
On Error GoTo DoMacroOverTableErr
Do Until False
DoCmd.GoToRecord acActiveDataObject, , acNext
DoCmd.RunMacro (sMacro)
Loop
Exit Function '' never reached!
DoMacroOverTableErr:
If Err = 2105 Then
'' expected
Else
MsgBox "Unexpected Error: " & Err.Number & ":" & Err.Description,
vbCritical, "DoMacroOverTable"
Stop
Resume
End If
End Function
(End Message)
我完全同意艾伦。单独缺少错误处理会使宏（对于AutoKeys而言）不受限制。你永远不会有一个完全基于宏的强大，稳定的b $ b应用程序。你当然可以只使用宏来构建一些简单的程序，但是没有什么可以用来解决任何实际的业务问题。很多人，甚至是新手，都发现了很多令人困惑的问题......评论很好的VBA代码通常比宏观更加容易。
以这种方式看待它 - 这个项目在它开始之前就注定要失败。猜猜谁会得到责备...你的经理???我想不是。如果它是我b $ b，我会记录所有内容......让你的经理以书面形式提出他/她想要的东西（即只有宏等等）等），然后添加你自己的意见
关于这种方法的可行性。这可能是一个棘手的问题，因为管理人员讨厌有任何书面形式可以回到
困扰他们。保存电子邮件，备忘录等等......你需要提供文件
显示授权此次惨败的高层人员。
换一种方式，你的经理要求你驾驶汽车而不使用引擎......如果是我，我会告诉他们没有。
David Powell <哒*** @ powell-au.net>在留言中写道
news：b5 ************************** @ posting.google.c om ...
I agree completely with Allen. The lack of error handling alone makes macros
off limits to me (expect for AutoKeys). You will never have a robust, stable
application based entirely on macros. You could certainly build a few
trivial programs using only macros, but nothing that would be used to solve
or assist in any real business problems. And many people, even novices, find
Macros confusing ... well commented VBA code is usually much more easy to
follow than a macro.
Look at it this way - this project is doomed to failure before it even
starts. Guess who will get the blame ... your manager??? I think not. If it
were me, I''d document everything ... have your manager put, in writing, what
exactly he/she wants (i.e. Macros only, etc etc), then add your own comments
regarding the feasibility of this approach. This will likely be a tricky
issue, since managers HATE to have anything in writing that can come back to
haunt them. Save emails, memos, etc etc ... you''ll need documentation to
show the higher-ups who authorized this fiasco.
Put another way, your manager is asking you to drive the car without using
the engine ... if it were me, I''d tell them "No".
"David Powell" <da***@powell-au.net> wrote in message
news:b5**************************@posting.google.c om...
因为我的工作区明年没有Access程序员，我已经被要求重建他们的编码应用程序作为一套模块化的工具。这个想法是非程序员能够随着需求的变化而对其进行修改。
更一般地说，事实上，他们想要一个通用的功能包来预测*所有*要求。
它们必须被称为宏。
我可以理解，使用宏可以方便地将一系列简单的操作串联在一起。
我有一个想法是沿着将表格加载到表格，带有验证错误这一行的宏。可能有用。这基本上就像TransferSpreadsheet一样，有一些额外的控制，有助于更好地识别错误。
然而，我的经理想要更多的原子。比这更有用的功能。
类型IsAlpha的验证功能。例如。他希望
在每个记录中的字段被提交到
表之前验证它们，其中定义了这些类型和其他约束。这些都是由宏控制的。
正如我所看到的，这使得非程序员处于使用
宏循环的位置。
我''自己很难对这些进行编码：例如，表格末尾的情况不能直接测试。我写了一个（VBA）函数
[下面的DoMacroOverTable]来接受一个宏和一个表，并为表中的每个记录应用宏。并且，虽然我可以使
表格成为当前对象。并使用GotoRecord更改当前
记录，我无法看到（在被调用的宏内）如何引用此
记录或其中的字段（缺少定义表单和
任何想法？
此外，到目前为止，我已经失去了对这个特定策略的反对意见。 （当作为表属性和参照完整性约束声明时，许多这些测试的冗余;
在选择或更新查询中适用的更好的应用程序比在宏中更好）。如果有人可以提供他们的推理（无论哪种方式！）
它可以帮助我。
公共函数DoMacroOverTable（sMacro As String，sTableName As
String）
DoCmd.SelectObject acTable，sTableName
DoCmd.GoToRecord ,, acFirst
On Error GoTo DoMacroOverTableErr
Do to False
DoCmd.GoToRecord acActiveDataObject， ，acNext
DoCmd.RunMacro（sMacro）
循环
退出功能''永远不会到达！
DoMacroOverTableErr：
如果Err = 2105那么
''预期
其他
MsgBox"意外错误：" &安培; Err.Number& "：" &安培; Err.Description，
vbCritical，DoMacroOverTable
停止
结束如果
结束功能
（结束）消息）
Because my work area won''t have an Access programmer next year, I''ve
been asked to rebuild their coded application as a set of modular
tools. The idea is that a non-programmer will be able to modify it as
requirements change.
More generally, in fact, they want a general package of functions that
will anticipate *all* requirements.
They must be called as macros.
I can appreciate that a simple sequence of operations could be
conveniently strung together using a macro.
I had an idea that a macro along the lines "Load Spreadsheet to Table
with Validation Errors" might be useful. This would essentially be
like TransferSpreadsheet with a few extra controls and helps to better
identify errors.
However, my manager wants more "atomic" functions than this.
Validation functions of the type "IsAlpha" for example. He would like
to validate fields within each record before they''re presented to the
table where these types and other constraints are defined. These are
to be controlled by macro.
As I see it, this puts the non-programmer in the position of using
macro loops.
I''ve had difficulty coding these myself: e.g., the end-of-table
condition can''t be tested directly. I wrote a (VBA) function
[DoMacroOverTable, below] to accept a macro and a table and to apply
the macro for every record in the table. And, whilst I could make the
table the "current object" and use GotoRecord to change the "current
record", I can''t see how (within the called macro) to refer to this
record or to fields within it (short of defining a form and fields for
it).
Any ideas?
Also, so far I have lost the argument on my objections to this
particular strategy. (Redundancy of many of these tests when
declarable as table properties and referential integrity constraints;
better application where applicable within select or update queries
than in macros). If anyone can supply their reasonings (either way!)
it may assist me.
Public Function DoMacroOverTable(sMacro As String, sTableName As
String)
DoCmd.SelectObject acTable, sTableName
DoCmd.GoToRecord , , acFirst
On Error GoTo DoMacroOverTableErr
Do Until False
DoCmd.GoToRecord acActiveDataObject, , acNext
DoCmd.RunMacro (sMacro)
Loop
Exit Function '' never reached!
DoMacroOverTableErr:
If Err = 2105 Then
'' expected
Else
MsgBox "Unexpected Error: " & Err.Number & ":" & Err.Description,
vbCritical, "DoMacroOverTable"
Stop
Resume
End If
End Function
(End Message)
正如其他海报所说的那样，如果你做的话，不要打扰你，CYA！
如果你有时间，可以学习VBA，你很快就会体会到它的实力和灵活性 - 你可能永远不会打扰
宏再次（可能是Autoexec和/或Sendkeys除外）。
只是我的两个下午！
干杯，
Phil
da***@powell-au.net （ David Powell）在留言新闻中写道：< b5 ************************** @ posting.google。 com> ...
As other Posters have said, either don''t bother OR if you do, C.Y.A!
If you get the time, learn VBA and you''ll soon appreciate the power
and flexibility you are afforded - you''ll probably never bother with
macro''s again (except possibly Autoexec and/or Sendkeys).
Just my two penneth!
Cheers,
Phil
da***@powell-au.net (David Powell) wrote in message news:<b5**************************@posting.google. com>...
因为我的工作区明年没有Access程序员，我已经被要求重建他们的编码应用程序作为一组模块化的工具。这个想法是非程序员能够随着需求的变化而对其进行修改。
更一般地说，事实上，他们想要一个通用的功能包来预测*所有*要求。
它们必须被称为宏。
我可以理解，使用宏可以方便地将一系列简单的操作串联在一起。
我有一个想法是沿着将表格加载到表格，带有验证错误这一行的宏。可能有用。这基本上就像TransferSpreadsheet一样，有一些额外的控制，有助于更好地识别错误。
然而，我的经理想要更多的原子。比这更有用的功能。
类型IsAlpha的验证功能。例如。他希望
在每个记录中的字段被提交到
表之前验证它们，其中定义了这些类型和其他约束。这些都是由宏控制的。
正如我所看到的，这使得非程序员处于使用
宏循环的位置。
我''自己很难对这些进行编码：例如，表格末尾的情况不能直接测试。我写了一个（VBA）函数
[下面的DoMacroOverTable]来接受一个宏和一个表，并为表中的每个记录应用宏。并且，虽然我可以使
表格成为当前对象。并使用GotoRecord更改当前
记录，我无法看到（在被调用的宏内）如何引用此
记录或其中的字段（缺少定义表单和
任何想法？
此外，到目前为止，我已经失去了对这个特定策略的反对意见。 （当作为表属性和参照完整性约束声明时，许多这些测试的冗余;
在选择或更新查询中适用的更好的应用程序比在宏中更好）。如果有人可以提供他们的推理（无论哪种方式！）
它可以帮助我。
公共函数DoMacroOverTable（sMacro As String，sTableName As
String）
DoCmd.SelectObject acTable，sTableName
DoCmd.GoToRecord ,, acFirst
On Error GoTo DoMacroOverTableErr
Do to False
DoCmd.GoToRecord acActiveDataObject， ，acNext
DoCmd.RunMacro（sMacro）
循环
退出功能''永远不会到达！
DoMacroOverTableErr：
如果Err = 2105那么
''预期
其他
MsgBox"意外错误：" &安培; Err.Number& "：" &安培; Err.Description，
vbCritical，DoMacroOverTable
停止
结束如果
结束功能
（结束）消息）
Because my work area won''t have an Access programmer next year, I''ve
been asked to rebuild their coded application as a set of modular
tools. The idea is that a non-programmer will be able to modify it as
requirements change.
More generally, in fact, they want a general package of functions that
will anticipate *all* requirements.
They must be called as macros.
I can appreciate that a simple sequence of operations could be
conveniently strung together using a macro.
I had an idea that a macro along the lines "Load Spreadsheet to Table
with Validation Errors" might be useful. This would essentially be
like TransferSpreadsheet with a few extra controls and helps to better
identify errors.
However, my manager wants more "atomic" functions than this.
Validation functions of the type "IsAlpha" for example. He would like
to validate fields within each record before they''re presented to the
table where these types and other constraints are defined. These are
to be controlled by macro.
As I see it, this puts the non-programmer in the position of using
macro loops.
I''ve had difficulty coding these myself: e.g., the end-of-table
condition can''t be tested directly. I wrote a (VBA) function
[DoMacroOverTable, below] to accept a macro and a table and to apply
the macro for every record in the table. And, whilst I could make the
table the "current object" and use GotoRecord to change the "current
record", I can''t see how (within the called macro) to refer to this
record or to fields within it (short of defining a form and fields for
it).
Any ideas?
Also, so far I have lost the argument on my objections to this
particular strategy. (Redundancy of many of these tests when
declarable as table properties and referential integrity constraints;
better application where applicable within select or update queries
than in macros). If anyone can supply their reasonings (either way!)
it may assist me.
Public Function DoMacroOverTable(sMacro As String, sTableName As
String)
DoCmd.SelectObject acTable, sTableName
DoCmd.GoToRecord , , acFirst
On Error GoTo DoMacroOverTableErr
Do Until False
DoCmd.GoToRecord acActiveDataObject, , acNext
DoCmd.RunMacro (sMacro)
Loop
Exit Function '' never reached!
DoMacroOverTableErr:
If Err = 2105 Then
'' expected
Else
MsgBox "Unexpected Error: " & Err.Number & ":" & Err.Description,
vbCritical, "DoMacroOverTable"
Stop
Resume
End If
End Function
(End Message)
这篇关于必须使用宏！我该如何遵守？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
