simonw代码@痕记

sender=item[1]=source=window 这个就错了
item[1]=source, sender=button应该是这样

self.ClickEvent(self)在触发事件时会传入button, 这个self参数这时传入的就是Event.Call(table, ...) ...中的自定义变量了, 内部是item[2](item[1], ...)这个形式调用, 其中得第二个参数就是这个button,展开后得实际调用形式是
Window.Button_OnClick(Window, button)

Button.ClickEvent:Add(self, self.Button_OnClick)
此时self为window
function Event:Add(source, func)
即source为window
--item[1]就是source, item[2]就是func响应方法
--lua 5.1中无需使用unpack(arg), 直接使用即可
item[2](item[1], unpack(arg))
=
Window:Button_OnClick(sender)
sender=item[1]=source=windw
可是为什么输出来的是button??????

呃...找到程序中的错误了，改了就好了

这段代码我在最新的lua5.13里执行不了哦

把unpack去掉了

还是不行

麻烦问一下：dz6.1是不是也能这样做？
还有“支持html的论坛”是什么意思啊？

出售蓝奇高级验证码识别引擎，可准确识别新浪动网淘宝CSDN等多种复杂验证码。

输出为一个标准DLL，可供VB,VC,Delphi,C#.NET,VB.NET,模拟精灵,按键精灵等多平台调用，调用方法简单，几行代码即可完成。独具特色的边缘检测字符分离、旋转倾斜纠正和通用字符匹配算法（无论字体和大小）， 使得该引擎对于像新浪、动网、淘宝、CSDN等多种验证码均有不错的识别率，是一款效果较为理想的验证码识别引擎。附详细的调用实例和代码注释等相关技术文档。

官方网站 - http://***/yzm_advocr
识别效果怎么样一试就知道 - DEMO下载 http://***/yzm_advocr/advocr.rar

开发技术，系统分析，架构，项目管理，公司运营，外包，合作
群将满，不发言的踢出
群号:47763528

但业务数据访问层最大的特点就是针对具体业务做抽象，而抽象的数据层访问方案是针对通用做抽象。
==============================

能否详细举例解释下上面这句话？

写的非常好，很多组件都想试试，如果有个具体的Demo就好了。

--引用--------------------------------------------------
@FantasySoft
从技术角度讲Wiki现有的语法优于html, 但html已然成为了标准, 更何况html比较于Wiki现有的语法并没有做不了的事情, 只是技术难度稍大些, 这些困难在10年前很难解决, 而在现在都可以处理妥当. 有了一个成熟而普及的技术为何还需兼容另一种.
我的思路是彻底抛弃wiki现有语法, 改html, 而非在现有wiki语法上修修补补添加html支持.
--------------------------------------------------------
@bigtall
WYSIWYG html 一样能做到专注内容专注写作, blog的成功就是最有力的证明. 而在格式控制上要比wiki语法好用的多.
--------------------------------------------------------
@随风流月
复制/粘贴, 永远无法避免. 我们不能对用户及应用场景做绝对化的假设.
--------------------------------------------------------
@simonw 更重要的是自内聚的功能。譬如模板、分类、链入、链出等等 @FantasySoft 其实对于wiki最重要的莫过于内链接, 我们只需针对这点创造语法
--------------------------------------------------------
同意.我现在复制了很多,所以复制/粘贴, 永远无法避免.我觉得wiki语法比html更难懂,不知谁说的wiki更简单?不过wiki中列表的语法的确是更简单.其它只能说wiki语法比较简短,这样虽然有利于程序解释处理,但对作者而言,更难以检查其格式是否是自己所需要的.

--引用--------------------------------------------------
finesite: --引用--------------------------------------------------

--------------------------------------------------------
点拨了一些，不错
--------------------------------------------------------

--引用--------------------------------------------------

--------------------------------------------------------
点拨了一些，不错

参数详细说明已经完成, 见我wow blog

其实我想有个比较详细的例子,因为你说4.0以后都改变了,但是现在你以前帖子的例子现在都不适用的,所以除了你默认的配置能看懂一点外,其他真的不知道怎么用.
譬如Type: 动作类型, 常用枚举值包含action,spell,item,marco,stop,target,focus,assist,menu,command
那这些类型怎么用?每个后面的value能跟什么东西?
还有ShortKey.ExtFrame里只说明了小队里面的,那团队里面叫什么名字?

可能以上这些在学习过wow相关的lua知识都知道答案,但是对于我们初学者或者说使用者来说真的一点都不懂的,希望有比较详细的说明或者例子能告诉我们,或者我一时没有找到你给我个地址参考一下也行,谢谢

还有就是我比较感兴趣那个复活死者而且随机喊话的例子,能把它改成现在可以用的版本的例子说一下吗?谢谢

控制层负责和业务层交互, 比如textbox1.Text=User.Name 或者你控制button的显示或者隐藏等等

文章写得很好 对我的帮助很大
但是还有一些问题不是很明白：
例如：
如果在系统架构中加入控制层时应该怎样设计呢 ，我最近在写内部设计 对控制层不清楚

原来要自己下一个NH 的generic.dll.
这里有文章专门讲这个.
http://www.ayende.com/projects/nhibernate-query-analyzer/generics.aspx

写这篇文章的时候是有的, 现在有段时间没有跟进castle了, 不知是否有改变.

CustomAccess = Generics.Access?
有这样的enum吗?

我的blog左上有写我msn

嘿嘿,选定施放法术时候,目标的那个会弄啦.
我是这么写的:
ShortKey.Config[1] = {

{Key = "Q", Type = "spell", Value = "治疗之触"},
}
也是照着例子里的代码改的.
这么写的代码,执行出来的效果就是,进入游戏后,按Q就跟按了技能一样的效果,然后把界面设置里的"自我施法"打开,就能完成之前我说的功能了.
可是我之前在别的地方比如:duowan,wowoui,等地放看到的介绍里.
能按Esc(主菜单)->按键设置里,设置将技能设置成哪个按键.
而现在这么写,只能在ShortKeyConfig.lua里调.
写完了,再进游戏,设置的是哪个按键就是哪个,不能在游戏里修改.
请问怎么写,才能把技能设置成在游戏里也能修改按键?

另外麻烦解释下
ShortKey.Config ShortKey.ExtFrame [SK_Constant_Class_HUNTER] 是什么意思啊?

这篇文章,最前面的那些有关猎人的代码,是用[0][1][2]编号写的,这些代码,我复制过去,根本就不起作用,复活的那个代码,我把复活改成补血技能,想试下随机喊话,也不能实现.
请问,这些代码还用加什么其他代码吗?

有关宏命令的按键绑定,我按了4.01的例子..还是不太明白.
其中绑定的宏的名字是什么? 怎么知道绑定的宏的名字.
就这些了...麻烦了.
我的MSN cnfczn@hotmail.com
还是希望能跟您聊聊,有好多问题,总是这么说也不方便啊.

对了,您的MSN是什么啊?
我还有点问题,可能一两句话说不清楚,留言又不及时.
麻烦啦.

呵呵,太感谢你啦...
我终于知道怎么使了?

我一开始是在ShortKeyConfig.lua的--[[ ]]-- 中间加的代码.
后来才刚发现,是不是类似于其他编程语言里的注释...然后就写到后边去了.
然后把您写的代码后边的职业,角色名改了...果然能使了.
不过还有点问题
比如说:我把Q键设置成圣光术(骑士的补血技能).如果是平常在游戏里,不用插脚,设置个快捷键,那么当你配合游戏里的界面设置里的"自我释法(当选择目标时候,为目标施法,当选择敌对目标时候则为自己释法)",就可以这样:
如果选择队友则为队友释法,如果未选择目标或者选择敌对目标,则为自己释法.
麻烦问下,这个功能怎么用代码实现.
麻烦啦....

to slamfinger
以后主要在这里回复了
http://blog.cwowaddon.com/simonw

to 叶子
你下错版本了吧, 以前的版本才是这么配置, 而且已经失效了.
http://blog.cwowaddon.com/simonw 看这里. 不需要任何库支持, 记事本打开这个ShortKeyConfig.lua文件直接编辑就行.

比较喜欢shortkey，可以说是居家旅行杀人必备利器。
在这个代码里我有一点困惑。
支持同一按键上的序列法术动作绑定.如何定义法术的等级？
{Key = "e", Type = "spell", Value = {"冰锥术", "火焰冲击"}},
我记得以前可以用rank=“”，现在如何处理？

麻烦问个很弱的问题啊
刚看了这个插件,感觉功能真是太好了.
能绑定技能到按键.
我一直就是想找一个插件,能将技能绑定到按键,而又不占用技能条的位置.
之前用了一个SpellBinder 能实现上面的功能,但是当使用聊天窗口的时候,按到绑定技能的按键还是会施放技能,感觉是个不小的BUG了.
后来看了这个插件感觉不错.不过我是个菜鸟,实在是不太明白怎么设置.
刚下载完成以后,里边就三个文件.ShortKey.lua ShortKey.toc ShortKeyConfig.lua 三个文件
我就是想实现按键绑定技能的功能
[0] = {Name = "圣光术"},
[1] = {Type = Type.Spell, Name = "圣光术", Rank = "1", Target = "target"}

语句,我也看了一些,应该是这么写吧?
但是这个语句应该写在哪个文件里,保存成什么扩展名的文件.
这两句话,是否还需要加些其他什么语句,才能执行?
是否还需要ACE2的库?
麻烦帮忙解答下...我特别想用这个插件...麻烦了.

@FantasySoft
我见到过，是改造已有可视化编辑器的插件。

请LZ,如何实现以下内容

一首先判断自身有无“命令圣印（等级5）”BUFF，如果有，则对目标施放“审判”并在施放“命令圣印（等级5）”；如果无，则先施放“命令圣印（等级5）”，再对对方施放“审判”，就是这样一个循环宏

怎么设置组合技能?这些要写在哪里啊?




1.组合技能，当短暂能量护符有效时施放短暂能量+痛
[0] = {Name = "短暂能量+痛", Condition = {Name = Condition.IsItemUseable, State = true, Parameters = {"短暂能量护符"}}},
[1] = {Type = Type.Equip, Name = "饰品1"},
[2] = {Type = Type.Spell, Name = "暗言术：痛", Rank = "8", Target = "target"},

写的不错

@FantasySoft
我认为应用WYSIWYG html 要比改进wiki语法效果好, 见效快, 成本低.

@simonw

确实，Wiki的核心在于Wiki链接。但是，我觉得还是不应该抛弃原有的一些其它语法，至少我们得进行详细的分析之后才能得出一个结论，到底哪些语法需要保留，哪些可以去掉。 譬如那些字体加粗的语法，就可以毫不犹豫地丢掉了。

@simonw
同意你的观点！

@bigtall
WYSIWYG html 一样能做到专注内容专注写作, blog的成功就是最有力的证明. 而在格式控制上要比wiki语法好用的多.

楼主分析只对了一半，wiki之所以使用特有的语法，根本原因在于要让写作者专心于文档内容，而不是他的格式。

那个东西至少对中国人来说价值等于0.

我成功访问过一次!

@FantasySoft
您可能没有注意看最后一段, 其实对于wiki最重要的莫过于内链接, 我们只需针对这点创造语法, 可以模仿ubb,vbb这样的思路实现, html一样可以被解析.

@随风流月
复制/粘贴, 永远无法避免. 我们不能对用户及应用场景做绝对化的假设.

@simonw

不赞同您的观点。 我之前的回复可能没有说到点子上。

Wiki不仅仅只有内容发布的功能，更重要的是自内聚的功能。譬如模板、分类、链入、链出等等，这些都是通过Wiki语法来实现的。自内聚功能是需要通过文本Parse才能实现的。所以，Wiki语法不应该抛弃，而应该简化它的使用。

@随风流月

是吗？您说的是哪一款？ FCKEditor？

@FantasySoft
Meta Wikimedia 上已经有 WYSIWYG 编辑器。
彻底抛弃 Wiki 语法绝不是好事。况且 Wiki 的宗旨是原创，而非复制/粘贴。

@FantasySoft
从技术角度讲Wiki现有的语法优于html, 但html已然成为了标准, 更何况html比较于Wiki现有的语法并没有做不了的事情, 只是技术难度稍大些, 这些困难在10年前很难解决, 而在现在都可以处理妥当. 有了一个成熟而普及的技术为何还需兼容另一种.
我的思路是彻底抛弃wiki现有语法, 改html, 而非在现有wiki语法上修修补补添加html支持.

@simonw

如果WYSIWYG编辑器不能支持Wiki现有的语法，它是不成功的，或者说不完善的。因为Wiki条目的文本是需要被parse的，如果纯粹的HTML会影响到parse过程的性能。

所以，我觉得一个完善的WYSIWYG编辑器应该两者都能支持：支持Wiki语法，支持HTML语法。

如果再不提供WYSIWYG的编辑器会影响wiki的发展。

@chy710
wiki与ajax确实不好比对.

@JesseZhao
就写作习惯来说, 即便对于程序员, WYSIWYG也是更好的方式.

@FantasySoft
针对目前wiki结构化文本WYSIWYG的编辑器继续发展下去不是一个好的选择, 原因有三:
1. wiki语法并没有像当初的html成为标准, WYSIWYG技术发展下去难度很大.
2. wiki最终输出的还是html, 何苦使用其他语法在绕弯子.
3. 外界web上的文档大多为html格式, 若从他处粘贴, 必然又要经过一次多余的转换.
也就是说 wiki语法->html, html->wiki语法, 双向转换都要做到完美, 其实这又何苦.
将其写作语法替换为html而应用html上成熟的WYSIWYG技术必然会对wiki引擎大动干戈, 也不是一时半会能完成的事情. wiki需要逐步走向大众, 所以不能总以专业人员的眼光来看待, 很可能未来wiki引擎会因写作语法技术的变更而重洗牌.

LZ说得很对，一个能够适用于Wiki WYSIWYG的编辑器是让Wiki更易用的关键，可惜没有人能够静下心来完成这件事情。

@chy710
如果Wiki真能如Ajax那么流行，那可是天大的幸事了。

Ajax和Wiki不同，虽然Ajax提高了用户体验，但是它存在的意义和Wiki相比则相去深远。Wiki造就了维基百科，这是一个互联网上最有价值的宝库。

Wiki的成功不需要炒作，而且炒作只会碍事，因为Wiki需要的是沉淀，而不是浮躁。

有兴趣的话，多点了解Wiki的内涵，您会发现它的魅力......

楼主分析的不错

支持一下

其实感觉wiki的这种写作手法对我们程序员来说还是比较好用的
学习一会就可以搞定

关于历史暂且不说，web2.0时代，wiki如此兴起，大家再一窝蜂去学，难道这里没有炒作？ajax也是很早就有的，但近一两年来，到了极点，用户体验是好呀，可现在滥用ajax的网站多的是，都是炒作惹得祸。