有谁会用icopy？？？？

有谁会用icopy？？？？应该怎样定义元素

嘿嘿，真是个好问题呀，我也想等待一个回答...

珍爱生命 远离icopy

想了一下，icopy的机制应该是，在第一个元素做一个自适应的面，让icopy的时候软件自动算各copy元素到路径和阵列面上各交点之间的装配重合，可就是不会做。

回楼主，关于iCopy，我在笔记中去年夏天是这样写的：
这个机制是笔者记忆中，史上最难以使用的Inventor机制。遗憾的是以笔者对机械设计和Inventor双方的理解程度，竟然也没能找到一个接近实战的设计实例需要iCopy，并能够演示出来给读者看明白；而在网络上一年以来对于iCopy也几乎无人提及，更没有对笔者有启发的讨论... 所以笔者只好认输。

回楼上：
如果说“一堆不懂机械的程序员”，我认为有些过；实际上确实有几个能称为“懂”的成员。
其实iCopy正是这种“懂”的成员的构思，并且题目确实来自某典型大用户的实际需求。
但是我想强调：
这个“不懂”不见得是坏事，因为自己知道不懂，可能会因此组建技术专家团队，因此变得懂。
而这个“懂”也不见得是好事，自己认为懂而实际上不透。这是因为多数可能列入“懂”范围的成员，是学过机械类专业而无实践。所谓只知其一不知其二的状态。

于是...
1）不去请教专家，也不去深入与用户交流，在半瓶醋的基础上进行策划，成为开环的设计过程
2）为了程序编写能容易些，又不具有与用户相同的设计过程概念，整个交互的规则与用户的常识不符合，造成用户不理解为何这样操作
3）因为对Inventor本身的能力理解较浅（甚至还不如资深用户），实现过程并未设计成Inventor最佳性能的表现，成为使用中有障碍的结果
4）好容易与真正的用户讨论了，因为用户表述不准确（这很常见），因为听者并不真的懂（这个更常见），所以又是开环的过程，没有反馈、没有验证，但是却有结论
5）基于“有懂的人在”的假设，研发上会放弃类似总工程师技术负责制的管理机制，而采用各自为战的研发机制。这将导致软件的系统关联性下降，风格不一...

至于“inventor的明天在哪里那”？
我认为答案非常清楚：在我们这里的、还在讨论最基本的几个概念的人群中。因为他们总会一浪浪地来到我们这里。
所以我们这里总是A-B-C的循环而难以达到D...

学习了！原来这个功能是这样的使用难度！

总算做好了。

我想是中间划线，给出两头的点。icopy的assembly就可以展到两点之间了。

端部必须是平的么？