主题：[原创]狐表中能否增加一个代码管理器！增加对一个项目的所有代码进行集中管理！

   我的意思并不是必须在代码管理器中管理代码，而是保留以前的方式，即仍然可以在对象上设置事件代码，在此基础上，增加对代码的集中管理。平时的设置仍然在对象事件中，需要整理查看、管理的时候才使用代码管理器。两者各有两长，用途不太一样。

易表要一列一列查看，即使是同一列，也要分别单击不同的菜单去取查看计算公式、操作公式、默认值公式，才能知道到底有没有设置公式，公式是什么，这个时候自然应该有一个管理器方便，Foxtable有这个问题吗？

至于窗口，你随便选一个按钮，右边事件页就会显示该按钮设置了哪些事件代码，也可以预览，需要一个一个事件去查看和判断吗？

如果你觉得这样还不方便，你还以用窗口的全局事件，不需要去为每个控件设置代码，也不需要每个控件去查看。

就为了知道哪些控件设置了代码，就另来一套代码管理和编辑系统?

凡事都是需要取舍的，只有相对，没有绝对。

    狐表中当然没有切换列、并切换列的各种公式的问题。但同样的道理，我们看一下在狐表中要切换不同窗口的不同控件的不同事件的代码需要几步：（1）退出当前窗口（2）切换表（不同的窗口可能从属在不同的表中、实在不知道窗口从属于表有什么意义）（3）打开新窗口（4）找到要编辑代码的控件 （5）找到相应的事件 （6）编辑代码。或许贺老师说即使有一个代码管理器，这几步基本上都不会少。但是，目前的狐表中操作以上6步需要在不同的位置来回点击切换，如果存在这么一个代码管理器，则所有的操作全部在一个窗口中进行。哪个快哪个慢，会差别多大，就不言而喻。而且如果代码管理器中可以隐藏没有事件代码的控件，效率会更高！
    怪不得阿翔说提了N遍了，贺老师都不支持。我认为贺老师仍然从一个软件专家的角度来考虑问题，我还是希望贺老师多为用户考虑一点，多为用户提供一点方便吧！或许贺老师，还有一些用户，都认为没有必要。 但现在的事实是，没有这个功能也不会影响狐表的使用，但增加了，肯定会增加效率。麻烦与麻烦，有多大工作量，当然是贺老师说了算，或许这个事也并不是当前最紧急的，还是希望贺老师换位思考一下吧！
   或许，很多人都不太欢迎我提意见，我总结过，第一我的语气不太好，过于坚决，有点自负；二是我提的建议总是工程量比较大，甚至总建议改变狐表的现有框架。尽管如此，还是希望贺老师认真分析一下我曾提的建议，不管是曾经采纳的、还是未曾采纳的，您可以对比一下我当时提建议时您和大家的态度（基本上当时都引起很大争议、您和大部分人都反对），以及改进到软件之后是否有意义、是否为大家所认可！（尽管还有许多方面的建议改进到目前为止仍然没有为大家所理解和认可，但我认为使用狐表时间长了，自然会明白意义所在！）

大家不要争了，本来早就想说话，但是楼主告诫说不要先否决，前几天也没多说什么，所以一直看到今天，今天忍不住唠叨两句，并给大家举一个例子：
    
       本人曾经在易表中研究过用一个表来管理所有函数，根据各列分类，逐级管理，相当于大家说的集中管理，采用了点阵管理法，到各单元格引用，系统其他的诸如变量、刷新公式、操作公式、默认值公式、表预处理公式、文件与处理公式、所有验证公式、按钮公式等等，只要用到公式的地方，全部到该表引用指定位置的值并eval()之，这种做法的优点，只要不改变系统的表、窗结构，可以只能更新系统，更新的代码实际就是更新这张表，我把它称之为公式集中营，相当于点阵管理，随着系统越来越大，我每次更新修改公式的时候，由于已经忘记哪一个地方到底需要实现什么功能，需要怎么修改，我还得一个一个比照按钮、列、表、窗口等逐一核对，最头疼的是，这种分类管理的代码让人烟花缭乱，就像前面说的，就像一盆浆糊，简直就是一盆黑芝麻糊。会看得您流眼泪，对于易表集中管理的方法，我在易表论坛还发过帖子。

        再说回来，随着某一个对象，逐个找到自己要修改的代码，等于对系统的设计功能重新理一个头绪，这样，对于重新更新和改进系统更有帮助，可以从窗口、表、或者菜单对系统的设计思路进一步熟悉，按照步骤更新和修改，如果就是集中管理，也没有人会不经过调试，一气修改N个事件或N个对象的代码，哪怕是高手也不会这么做，（面向对象编程的目的就是要所见即所得），因此，本人认为，加上这一功能，犹如画蛇添足！

以下是引用hnaysx在2009-4-17 7:11:00的发言：

此主题相关图片如下：未命1名.jpg



如果要增加的话  其实直接修改一下foxtable 代码编辑器就可以了 不用新增

打个比方，我在写A表B窗口C按钮的代码，如果我想参考D表E窗口F按钮的代码 就比较麻烦

如果有类似上边的 我可以直接复制粘贴过来

[此贴子已经被作者于2009-4-17 7:17:52编辑过]

    难道上面的这种方式真的有那么不好吗?
    已经有几位老兄说把代码集中管理会眼缭乱，像一盆浆糊，还有几位老兄一直强调所见即所得的好处。其实这几位老兄无非是要强调一个观点：就是以前的那种所见即所得的管理代码的方式也是很优秀、很方便的、不可缺少的！其实我感觉这是对我这个建议的误解，我从未否认以前的那种所见即所得的管理代码的方式很优秀、很方便，我也从未建议取消以前的那种到对象中编辑代码、即所见即所得的方式，即使有了一个集中管理的代码管理器，我仍然离不开而且会经常采用以前的那种打开对象编辑代码的方式。如果哪位老师真的感觉集中管理代码会眼花缭乱，像浆糊，不用它不就行了吗，并会防碍使用老方式管理代码啊！
    但是，以前的那种方式再优秀、再方便，并不能说明没有任何缺陷，更不能说明集中管理代码的方式没有任何用途。大家知道出行时坐汽车很方便，是不是因为汽车很方便，就不需要发展火车和飞机了呢？恐怕不会吧？各有各的用途！倒是贺老说软件中有有所取舍，是有道理的。但我认为贺老师太小看这种集中管理代码方式的用途了，既然有很多人需要，为什么不能在保留原有功能的基础上增加一个呢？个人认为工作量也根本没有大家想象的那么大！贺老师以前说只有大部分人需要的功能才添加，个人认为这样说不太符合现实，如果这样，狐表中的功能至少需要再砍掉一半。我在一本书上看到说：软件功能和使用人数仍然符合二八定律，即20%的功能是给80%的人用的，而80%的功能是给20%的人用的。很明显，增加这个功能，对于需要的人提供了方便，还可能成为软件的其中一个卖点多卖几套软件，对不需要的人则没有任何妨碍，只不过贺老师费点时间；不增加，也不影响使用，但会影响一部分用户的使用效率，会感觉不方便。从以上的讨论中看出，需要这个功能的人绝对不止20%，贺老师为什么因为一部分人不需要（哪怕是占50%），甚至自己也不需要，就否决这个功能呢？ 不理解。

嘿嘿，代码管理方式只会有一种，不会有两种，你见过那个软件有两个代码管理和编辑器？
你以为“智者”贴的所有代码在一起的方式，真的很适合大家吗？
按照我的想法，Foxtable离完美的软件的软件还差得远，我还可以继续开发10年，20年，甚至穷我一生来开发，永远试用下去都可以。

最后说一次，凡事有取舍，你虽然是为我好，我也谢谢你，但是若非对“实现”有重大影响的问题，大可不必如此纠缠不休。

锁贴！