动作是否可能返回值到Quicker中？以便下一个动作读取。

请问子程序如何解决呢？另一个动作不一定会装这个子程序的。

需要这功能就拖子程序出来用，不需要就不用。如果老大增加这种模块功能，也是这样拖模块出来用，所以是差不多的操作。

一开始运行的动作，不一定会内置这个子程序，让用户自己去加工动作，增加拖进子程序有点太难了。

那另外一个动作也可能不会使用所谓的通用变量

不使用也可以，那是一种选择。但是关键在于他想用，【可以】使用。

1. 
   
2. 用剪贴板动作为例子，如果现在我有另一个动作想要获得剪贴板收藏的其中一个类别，而剪贴板支持把这个类别信息的【通用变量】输出，这个动作就可以对这些类别进行完全不同的应用（可以是与剪贴板原来功能完全不相关的应用）。
3. 
   
4. 如果另外一些动作，跟剪贴板中的内容没有关联（”对剪贴板不感兴趣“），它就不在前面获取这个【通用变量】，也照样可以运行。
5. 最后就是输出与否，可以在最后的用户侧进行控制，如果用户觉得压根就不会想要导出剪贴板的内容，他去到剪贴板的设置中【关闭】掉即可。
6. 还有就是这个输出的【通用变量】一开始是可以默认关闭的，所以如果不打开，对一般用户是没有影响的。

这个情况不是一开始就想好，要那两个动作进行联动，而是后来的动作制作者看到前面的制作者的动作而想进行一个配套功能。

后来的动作也不是要主动触发第一个动作来获得信息（如果是这样的话，的确是可以用您介绍的方式进行度取返回值）。

关键在于，后续作者的动作【有这个选择】去获得之前动作的返回值，去判断是否符合一定条件， 也【可以】不获得。如果不去获得就正常运行。如果选择获得，就根据这些返回值进行细节化的配套。 前面作者也【可以选择】，是否可以【通过用户设置】给当前动作，增加一个返回值，以便后续作者进行加工。

这种情况直接通过剪贴板或自定义文件传递就挺好的。按剃刀原则，尽量少加奇怪的逻辑。

剃刀原则的前提是能解决同样的问题，无论是剪贴板与自定义文件，都没办法解决我前述的问题。

剪贴板很好理解，自定义文件，作为动作开发者，如果前置动作没有输出变量到一个文件，自己设计的动作自然无法到文件中去读取数据。

剃刀原则的前提是能解决同样的问题，无论是剪贴板与自定义文件，都没办法解决我前述的问题。

剪贴板很好理解，自定义文件，作为动作开发者，如果前置动作没有输出变量到一个文件，自己设计的动作自然无法到文件中去读取数据。

剃刀原则的前提是能解决同样的问题，无论是剪贴板与自定义文件，都没办法解决我前述的问题。

剪贴板很好理解，

自定义文件，作为动作开发者，如果前置动作没有输出变量到一个文件，自己设计的动作自然是无法到文件中去读取数据的。

给与动作数据共享的选择，以及给与动作接受共享的数据的选择，只有Quicker软件本身能做到。

举个例子，还是那个获取浏览器地址的动作，不是每次都把地址都放进某个文本中去保存，而是用户需要的时候可以打开这个功能，可以在动作中选择我要获得这个【最终的结果】, 如果能够按需打开这个功能。  那么相对应的，另外的一些开发者B就可以按需获取这个【最终的结果】。如果每个动作作者都用用文本来记载变量的话的话，100个开发者有100种放入文本的方式和方法，开发者B就无所适从，应该如何入手设计这个【接受结果】的步骤。