用C#实现用户自定义公式计算

作者:V君 发布于:2019-7-13 13:33 Saturday 分类:挖坑经验

这次主要是讨论各种已知的实现方式,然后扯扯目前的实现,并非着急解决问题。
因此没有TL;DR (pia

如果你着急,可以先看看我目前选择的实现方式,已经托管在公开的GOGS了。

按用户定义的计算公式做各种数据操作,在业务系统中并不罕见。
最近就遇到了这样的需求,新项目,可以比较宽松地选择实现方式。
(我不会说现有老项目也有公式计算,使用基于SQL的实现方式,比较恶心)

说到公式计算其实就是动态行为嘛!
我首先想到的就是将用户输入处理成Linq表达式文本(如关键字、字段名称替换),
然后再喂给动态Linq表达式解析解析器,最后编译成委托去执行。
经过实践发现这种方式存在许多限制,不合适用在太开放的用户自定义公式的场景。
停止进一步尝试,表达式解析引擎不是那么容易魔改的,投入咕狗的怀抱寻找更合实现方法。

咕狗一圈回来一共找到了5种方式,分别是:

  • SQL(和老项目的方式一样,相当恶心)
  • DataTable的Compute方法(同样恶心)
  • JScript:Eval(运行效率?弱类型脚本语言并不好吃)
  • 造(找)轮子(后序式计算或其他自行实现,如ToolGood.Algorithm
  • 代码编译执行(需要考虑资源释放,也就是要创建独立的AppDomain并在用完之后卸载掉)

(用动态Linq方式居然一个人也没有?编译出来的委托还带自动垃圾回收释放内存呢!)

造轮子是不可能造轮子的光是表达式解析就是个课题了,
用别人做好的东西又担心有风险,主要是在PM的要求下别人的东西好不好修改这方面。
那就只剩下凑代码编译来执行了。

扯一扯目前的做法吧,还是分成几个步骤来实现:

  1. 中文标识符映射
  2. 提前浮点类型转换
  3. 编译代码
  4. 调用已编译的代码
  5. 释放资源(TODO)

为了使用户体验更友好,字段名、部分函数名、操作符之类的玩意儿,允许用户以中文代替。
那么第一步就是将这些中文标识符提取出来,替换成可编译的代码标识符。
最初的实现方式是粗暴地按空格分割表达式项,逐个检索字典替换。
后来发现这样做太糟糕,总不能让用户把操作数和运算符都用空格分开吧?
老早就知道动态Linq表达式解析器里面有解析表达式项地实现了,试着扒一扒。
弄出一个专门提取表达式项的玩意儿,除了不支持字符转义和全角符号,其他方面还凑合吧。
连续两个中文标识符肯定是要用户自己以空格分开,现在第一个步骤已经相对完善。

尽管以代码编译的方式解决了动态Linq表达式不支持的持隐式转换,
但C#中的浮点类型们似乎还是有些水火不容。他们是decimal和double、float,
我们需要根据使用场景来决定兼容的转换方向,
比如计算金额的时候,应该提前将double和float转换成decimal;
再比如要计算参数的时候先将decimal转成double,再去计算,以避免编译失败。
(虽然不知道有没有用decimal保存参数的场景,先提前做好准备吧)

编译代码就简单得多了,只要确定委托签名,就凑出只有一个静态方法的类的可编译代码。
将凑好的代码喂给CSharpCodeProvider的CompileAssemblyFromSource,
稍微看看编译结果有没有问题,就能通过反射取得编译后的方法,把它作为委托放到字段里;
如果发现有编译错误,那就将错误信息整合到异常消息丢出去。

调用代码这一步没什么好扯的了,已经将表达式编译成明确的委托,
只需要将参数怼进去,结果就会返回来。如果还不清楚,那就看看我做的PoC界面实现吧!

最后一个步骤就稍稍有些麻烦了,说是要改变整个格局都不为过。
打算集成到具体项目再考虑,并没有包括本文提供的Poc中,现在只能干巴巴地扯一下。
参考上面提到的链接,在.NET域之间穿梭是一个相当麻烦的事情,
他的工作机制决定了能传输的形式——要求可序列化,且域之间的对象是不能直接引用的,
要通过代理对象去操作,其参数似乎也要求可序列化,这样就很大条了。
就算能很好地控制出入参数,在大量计算地时候还是有不小的序列化开销。
我的方案是把操作颗粒度划得更大一些,整个计算操作在域里面进行,包括数据源的获取,
这样就减少了绝大部分跨域操作,甚至还有敦促垃圾回收的作用。
那么问题来了,是将计算结果跨域传回来呢?还是在域里面就包括输出的动作?
这就要视具体情况来确定了…


那么,每月至少刷一次的存在感就扯到这里,我们下个月再见(pia

标签: 软件开发 C# 动态编译

评论(2) 引用(0) 浏览(52)

[ALPHA]适用于Notepad++的Markdown插件

作者:V君 发布于:2019-5-12 6:04 Sunday 分类:我的应用

TL;DR

本站下载:[ 本体32位 ][ 本体64位 ]

源代码 ]

效果: 增加一个可拆分、停靠的插件窗口,呈现Markdown,可导出PDF
限制: 支持大部分常见的Markdown语法,数学符号,图表目前还不支持
环境: 已使用Notepad++ v7.6.6在Win10和Win7SP1确认
技巧: 等你来发现。。。

点击查看原图

使用方法:

1)确定Notepad++位数和版本,下载对应本体,解压到插件目录的NppMarkdownRenderer文件夹
2)启动Notepad++点击工具栏中的点击查看原图按钮,或通过插件菜单
NppMarkdownRenderer打开插件窗格

目前待实现的功能:
1) 样式表管理
2) PDF导出选项(如背景启用和边距)

FAQ:
1)Notepad++提示错误,无法加载插件。
 有两个常见的原因会导致插件无法顺利在Notepad++启动时加载。
 - 在Win7可能是缺少.NET,可从官方网站获取最新版。
 - 缺少CRT库,可以从官方网站下载安装或者直接将散装文件(32,64)解压到插件目录
2)插件窗口显示ERROR: Only Markdown(*.md) supported
 - 将当前文件保存成扩展名为.md的文件,然后任意变更或来回切换选项卡即可
3)崩溃、卡死和其他BUG
 - 请把重现步骤反馈到评论中
 - 具备开发能力者请调试源代码

扯扯:
 总算是发布了第一个看起来可以用了的版本,虽然还有许多功能只做了界面还没实现。。。
 其实没有Notepad++也可以运行
MarkdownRenderer.Test.exe来体验一番 乂目

标签: 软件开发 插件 C# Interop HybridApp

评论(0) 引用(0) 浏览(177)

[WIP]通过音频预处理、分析和可视化,辅助制作LRC时间轴

作者:V君 发布于:2019-3-31 13:50 Sunday 分类:折腾手记

目前实现程度非常不完整,稍稍展示一下目前的效果,如果想听我扯扯就点进来吧

点击查看原图

阅读全文>>

标签: 软件开发 C# 图像处理 多媒体 音频

评论(0) 引用(0) 浏览(170)

做了个LRC歌词日文汉字注音小工具

作者:V君 发布于:2019-2-21 13:04 Thursday 分类:我的应用

TL;DR

[ 本体 ][ 源代码 ]

点击查看原图

效果: 在LRC歌词中的日文汉字后面自动加上平假名注音,用括号括起来
限制: 仅处理 [mm:ss.ff] 格式时间轴前缀的行,其他文字会直接追加到输出
环境: 只需要 .NET 2.0 就能运行,依赖MSIME.Japan 对于精简掉日文输入法的系统可能会挂
技巧: 左边窗格支持把文件拖放进去, 默认情况下以ANSI编码读取文本, 可以按住shift换utf8

扯扯:

自从发现了K米可以自动关联MP3旁边的LRC文件之后(之前只知道可以自己传,没想到还能带歌词),开始自己做时间轴歌词去练习K歌了. 最开始的时候是一个个汉字查字典找平假名注音,然后编辑本文. 多了就会烦,受不的时候才想起可以写个小工具来实现自动处理(真是码农失格!)

尽管已经把源代码放出来,但也可以扯扯实现过程的经历.

在动手之前,首先确认可行性,比如看看如何获取日文汉字的平假名注音,把想法拿去喂狗,然后咕狗吐出一篇博客文章详细地讲解了如何用MSIME.Japan实现获取日文汉字平假名.

但这是一整句转换,距离达成目的还差挺远.接着停下来想办法,或许用正则进一步处理可以实现.又去咕狗,找到了另一篇文章,讲解了如何使用正则判定日文平假名.

我去! 原来正则还有内置的字符集标识

  • \p{IsHiragana}判定日文平假名
  • \p{IsCJKUnifiedIdeographs}判定汉字

到目前为止,技术上的可行性已经确定,只需要把一个个[平假名+汉字]的组合分别喂给MSIME然后再抓出想要的部分,塞进括号并插入汉字后面就OK.

总结下来这个东西似乎并不太具备技术含量.. 嘛!问题解决了就好 _(:з」∠)_ 

接下来可以挑战一下卡拉OK视频字幕,虽然以前有做过,但那是手工操作的,那就让它自动化吧!

标签: 正则表达式 软件开发 C# Interop Winform

评论(0) 引用(0) 浏览(256)

用C#为Notepad++写插件:完善IDE调试体验、使用共享项目、实现窗口停靠

作者:V君 发布于:2019-1-5 21:57 Saturday 分类:折腾手记

TL;DR

完善IDE调试体验

1) 在 Notepad++ 插件目录创建文件符号链接,指向 bin\debug\x86(或x64)\ 里的 dll
2) 将项目属性-调试选项卡-启动操作的外部进程指定为 Notepad++ 的绝对路径
3) 设置断点,F5!

使用共享项目

1) 新建共享项目,命名 Kbg.NppPluginNET.PluginInfrastructure 这样可以一致命名空间
2) 将 PluginInfrastructure 里的代码文件移动过去

3) 在插件项目中添加共享项目引用, 这样一份基础设施代码就能在多个项目之间共享

实现窗口停靠

1) 从官网插件开发向导页面找C#插件示例中参考窗口停靠的具体实现。在GitHub也有在线版
2) 新建一个窗体,命名 SayHiForm,延续上回命名习惯
3) 将示例代码应用到项目中,按 F5 键启动调试验证实现。可以在 SVN 上查看最终实现

点击查看原图

~扯谈时间~

在上一篇文章里我们搞清楚了如何开始用 C# 为 Notepad++ 写插件让我们继续折腾,这次一共有3个折腾点,分别是完善调试体验、用共享项目避免重复代码还有实现窗口停靠。让我们从第一个折腾点开始。

按照TL;DR的步骤操作下来,现在可以命中断点了,也能查看和修改变量值以及拖动执行代码,略遗憾的是编辑并继续不可用。提示未加载程序集时不允许,可能是 DllExport 修改 DLL 导致。总而言之,能打断点已经是很好的体验了。非要在调试时想要编辑并继续也不是不可以,只要另起一个项目作为调试启动入口来调用这个程序集,那么在调试时也是可以编辑并继续的,只不过你得而外地为调试入口做一些适配,从而弥补调试入口和实际被 Notepad++ 加载运行时的差别。扯完这个折腾点之后让我们简单扯扯代码共享项目。

说到代码共享项目那就得先聊聊过去,在没有这种项目类型时,我是如何管理重复出现于多个项目的代码集。在那个时代,我的解决方案有两种,分别是将其独立成为类库,或者用目录符号链接。这两种方法相对于代码共享项目来说都是有明显缺陷的,拿这次我们折腾的,带非托管导出函数的程序集来说,就得把代码放入当前项目中,导出函数不应该出现在引用的程序集;而符号连接虽然能算作当前项目的代码文件,然而命名空间不能与项目名称保持一致,从规范层面来看有些尴尬。用了共享项目之后这两个问题得到了彻底的解决。共享项目能扯的并不多,最后是这次的重头戏--可停靠窗口。

说到可停靠窗口,我要先小声 BB 一下,现在能找到的,能在 Windows 下离线使用的,带实时预览窗格的 Markdown 编辑器中,大部分布局都是文本编辑在左边,预览窗格在右边。只要把预览窗格做成可浮动、停靠的活动面板,这就完美的满足了我这种挑剔家伙和大众普遍习惯的需求。就算是能把预览窗格移动到左边的 vs code,它也不能实现浮动窗口。

回归主题让我们继续吧!进入官方推荐的插件示例项目一看,略震惊。具体实现只需要短短几行代码把窗体句柄按照指定的姿势丢给 NPP,它就能自己管理停靠! TL;DR 里已经写的很清楚,这里就不再啰嗦。

才如果你把整个解决方案Check出来,会发现上一篇文章折腾的 HelloNppPlugin 插件项目并没有使用共享代码项目,这是有意而为之,让内容和文章描述尽可能一致,避免初看的读者受到影响。

这次就扯到这里,下次关于 NPP 插件的文章估计是 Markdown 插件发布的时候了。

标签: 软件开发 插件 C# Interop 调试技术

评论(0) 引用(0) 浏览(234)

Powered by emlog 去你妹的备案 sitemap