相关疑难解决方法(0)

我仍然试图围绕VBA中的接口和事件如何协同工作(如果有的话).我即将在Microsoft Access中构建一个大型应用程序,我希望尽可能灵活和可扩展.为此,我想利用MVC,接口(2)(3),自定义集合类,使用自定义集合类引发事件,找到更好的方法来集中和管理由窗体上的控件触发的事件,以及一些额外的VBA设计模式.

我预计这个项目会变得非常毛茸茸,所以我想尝试在VBA中一起使用接口和事件的限制和好处,因为它们是我认为在VBA中真正实现松散耦合的两种主要方式(我认为).

首先,有一个问题是在尝试在VBA中一起使用接口和事件时引发的错误.答案指出"显然不允许事件通过接口类传递到具体类中,就像你想使用'Implements'一样."

然后我在另一个论坛的答案中找到了这个陈述:"在VBA6中,我们只能引发在类的默认接口中声明的事件 - 我们不能引发在Implemented接口中声明的事件."

因为我还在寻找接口和事件(VBA是我真正有机会在现实环境中尝试OOP的第一种语言,我知道不寒而栗),我无法在脑海中彻底解决所有问题这意味着在VBA中一起使用事件和接口.听起来你可以同时使用它们,听起来有点像你不能.(例如,我不确定上面的"一个类的默认接口"与"一个已实现的接口"是什么意思.)

有人能给我一些基本的例子,说明在VBA中一起使用接口和事件的真正好处和局限吗？

我经常与用户讨论的事情是他们希望快速获得解决方案,这意味着他们有时会说"哎呀,我只是卷起袖子然后在Access中完成它 - 它安装在我的桌面上".

有时,我们很幸运,创建Access数据库的人将其后端转发到SQL Server,因此至少通常出现的mdb文件问题不是问题.

但是,我认为将Access前端部署到SQL Server数据库作为具有数千个用户和数十万行的企业解决方案仍然存在问题.

你对此有何看法？有哪些潜在的陷阱？

要么

这是一个完全可接受,稳定,可维护且强大的解决方案吗？

您是否建议在MS Access应用程序上与多个程序员一起工作？

我们的一个MS Access应用程序已经发展到一个程序员在请求的时间范围内无法再处理更改(错误修复)和新功能的数量.

我们正在尝试使用VBA中未记录的SaveAsText和LoadFromText过程引入版本控制,以便在此应用程序上进行协作.遗憾的是,由于校验和存储在每个表单文本文件中,因此我们已经遇到了将修改后的表单和报表加载回Access的问题.

在花时间构建导入/导出应用程序以将文本文件编译到Access数据库之前,我们希望听到您的建议.

解释为什么Access.Application.Eval()(通常缩写为Eval())产生的结果不同于在这种情况下仅评估原始表达式:

Debug.Print Round(.575 * 100)
 57 
Debug.Print Eval("Round(.575 * 100)")
 58 

编辑:为了解决GSerg的答案,以下仍然会返回不同的结果:

Debug.Print Eval("Round(CSng(.575) * 100)")
 57 
Debug.Print Round(CSng(.575) * 100)
 58 

我想知道一些可以改进使用Access和VBA编程语言设计解决方案的过程的想法.当然,我不是在谈论一般的最佳编程实践,而只是与Access和VBA直接相关.

大家都知道,VBA具有较差的面向对象编程支持,没有继承,多态等等.那么如何一次确保DRY和KISS？有一些解决方案如何在VBA中实现其他语言模式和策略的通用,但坦率地说,它们往往过于复杂.哪些值得实施？

在我开始一个新的Access项目(如果有的话)之前),我希望收集最佳实践的集合,因为根据我的经验,我知道在Access中使用VBA(以及Access本身),避免糟糕的设计概念和以混乱,不可读和重复的多次代码结束.

我不确定是否已经提出过这个问题,但是你应该在UI类中添加多少逻辑？

当我开始编程时,我常常把我的所有代码放在表单上,​​就像每个人都知道的那样,这对于测试和维护的屁股来说是一个绝对的痛苦.加班我已经发布了这种做法有多糟糕,并开始将所有内容都分成几类.

有时在重构时我仍然有"我应该把这些东西放在哪里"的感觉,但是因为大多数时候我正在处理的代码是在UI层中,没有单元测试并且会在难以想象的地方打破,我通常最终将它留在UI层.

关于你在UI类中放置了多少逻辑,是否有任何好的规则？我应该寻找什么模式,以便将来不做这种事情？

我们是一家小型软件公司,为制造设施开发有关分析,可追溯性,报告等的项目.我们使用Access作为前端,SQL Server作为后端.我们也有很大的客户,我们的公司也在增长.到目前为止它工作正常,但我想我们应该转向更有影响力的技术,如基于Web的解决方案.您如何看待Access的未来？

我正在使用ms-access开发用于数据库管理的前端解决方案.我必须承认ms-access VBA是大规模应用程序开发的一个固定限制,这就是为什么我一直在转变使用c#而不是VBA的想法.

实际上,除了一个东西:表单之外,很容易摆脱ms-access中的所有内容.在数据显示和编辑方面,这些特别快速有效.在最新版本的ms-access中,表单就像类一样,因此您可以在运行时专门管理同一表单的一个或多个实例.在连续模式下使用时,它们可用于操作数据"excel方式",具有行和列显示,过滤和排序的可能性.简而言之,我喜欢它.

当然可以在c#(或其他类似语言)下对这个表单对象进行反向工程,但这可能已经完成了:你曾经使用过库,activeX控件或任何其他类型的附加组件吗？在c#中操作类似msacces的形式的可能性？

编辑:根据Renaud的评论,我承认没有兴趣仅转换表单的布局部分,并且无法转换其自定义/ VBA部分.在我们的特定情况下,我们很久以前就停止在表单中使用自定义VBA代码,并且从模块管理表单属性,方法和事件.这甚至在这里讨论过.

实际上,我们所有的表单都依赖于一个通用模板,并且是自动构建的"表单"和"控件"表.所有基础事件管理代码生成都是自动化的:根据其类型,控件与选定事件相关联,事件代码提供应用程序模块中保存的标准\通用程序.这使我认为可以将我们的'ms-access表单技术'转移到.NET平台.