对于web方向的工作流,一直在用gooflow对于目前我的winform开发平台却没有较好的工作流组件.  针对目前的项目经验告诉我们.一个工作流控件是很必要的. 当然在winform方面的工作流第三方组件在网上找了很久,也没有发现自己比较心仪的组件. 对于工作流组件通过web方式来实现具有绝对的优势.我的这套winform平台当然也不能少了工作流组件. 通过winform来实现自己的工作流组件,目前我想到的指能通过GDI+重绘的方式来实现工作流的方案. 说干就干,如下图这是我通过GDI+绘制的

从事软件行业那么多年,一直很少写博.很多技术,长时间不用都慢慢淡忘. 把自己学到的用笔记下来,可以巩固和发现不足,也可以把自己对技术的一些 理解,分享出来供大家批评指正. 废话不多说,进入正题.工作流设计器网上有很多第三方开源的项目,也有成熟 的产品,但是有些不太符合自己的业务,于是自己动手做一个设计器.使用winform +GDI 绘制. 大概功能: 1.拖动绘制节点 2.移动节点 3.直线.折线链接节点 4.节点移动要能自动移动连接线 5.高亮显示选中的节点,和线 6.能删除选中的线和节点

Winform开发框架之简易工作流设计 一讲到工作流,很多人第一反应就是这个东西很深奥,有时候又觉得离我们较为遥远,确实完善的工作流设计很多方面,而正是由于需要兼顾很多方面,一般通用的工作流都难做到尽善尽美.微软也提供了几个版本的WF框架支持,也有一些厂家是基于这个框架基础上开发的工作流应用. 以前由于项目的需要,参与过一些工作流的项目开发,其中有些是基于我简易工作流的原理上进行拓展的,包括一个广州市各区县使用的行业审批业务平台,由于基于自己的流程处理,界面设计.流程流转等方面可以很好符合客户需

一讲到工作流,很多人第一反应就是这个东西很深奥,有时候又觉得离我们较为遥远,确实完善的工作流设计很多方面,而正是由于需要兼顾很多方面,一般通用的工作流都难做到尽善尽美.微软也提供了几个版本的WF框架支持,也有一些厂家是基于这个框架基础上开发的工作流应用. 以前由于项目的需要,参与过一些工作流的项目开发,其中有些是基于我简易工作流的原理上进行拓展的,包括一个广州市各区县使用的行业审批业务平台,由于基于自己的流程处理,界面设计.流程流转等方面可以很好符合客户需求,定制的弹性较好,缺点是不够通用,也需

系列目录 工作流在实际应用中还是比较广泛,网络中存在很多工作流的图形化插件,可以做到拉拽的工作流设计,非常简便,再配合第三方编辑器,可以直接生成表单,我没有刻意的浏览很多工作流的实际设计,我认为工作流只要有动态可修改的流转,有时可按角色,部门,上级或者职位流转即是比较好的正常工作流!这里只带给一个思路的简单工作流... 工作流其实有几种,也可以设计得很简单: 1.固定的工作流,很小的公司,很固定的流程! 2.自定义表单和字段,有时候可以校验表单 3.自定义流转的人员,即按角色流转,用户每一次提交

如今,尽管WPF.UWP大行其道,大有把Winform打残干废的趋势.但是还是有那么一波顽固不化的老家伙们固守着Winform,其中就包括我. 好吧,既然都说Winform做得软件不如WPF界面美观效果绚丽,那么我们就找一个方法让Winform也拥有漂亮的界面.DevExpress和ComponentOne都是不错的选择,Telerik虽说是做Asp.net组件出生的,但是他家的UI for Winform做得也很不错.稍等,那问题来了,这些组件收费昂贵不说,而且是年付,起价都得几百美刀.对于我

在winform 数据库设计中,有时候需要通过条件查询对应的数据,并且将数据显示在文本框(or 富文本框)中,下面,小编将讲述通过一个条件: 首先,我们需要对数据库建立连接,并且执行数据库命令,在此之前,我们先创建一个winform窗体,窗体设计大概如下所示:    在创建窗体后,我们应该进行书写代码阶段: 1 string s = "server=SAM_PC;database=MInformationDB;Integrated Security=true"; SqlConnecti

工作流设计 业务流程管理模块是本平台的重要组成部分,要实现将已经发布的标准中规范化的流程转化为具体计算机中的流程从而实现流程的自动运转,将标准化成果与员工的日常工作紧密结合起来,具有重要意义. 业务流程管理模块主要包括流程建模.工作流执行服务.流程监控等部分.其中流程建模是用来定义一个流程,具体主要包括流程定义.流程的活动定义等: 工作流执行服务用于解释流程过程定义,并控制其运转,工作流执行服务中最重要的就是工作流引擎:流程监控用于用户监控流程的运转情况.业务流程管理模块示 意图如图3-5所示:

原文:构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(48)-工作流设计-起草新申请 系列目录 创建新表单之后,我们就可以起草申请了,申请按照严格的表单步骤和分支执行. 起草的同时,我们分解流转的规则中的审批人并保存,具体流程如下 接下来创建DrafContoller控制器,此控制器只有2个页面,一个Create(起草页面)Index(表单列表) 表单列表显示个人想法,我是根据分类直接获取其下表单,即Flow_Type下的Flow_Form public

原文:构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(47)-工作流设计-补充 系列目录 补充一下,有人要表单的代码,这个用代码生成器生成表Flow_Form表的Index代码就可以 加上几个按钮就可以了 <div class="mvctool"> <input id="txtQuery" type="text" class="searchText" /> @Ht

原文:构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(46)-工作流设计-设计分支 系列目录 步骤设置完毕之后,就要设置好流转了,比如财务申请大于50000元(请假天数>5天)要总经理审批,否则财务审批之后就结束了. 设置分支没有任何关注点,我们把关注点都放在了用户的起草表单.所以本节如同设置字段,设置步骤一样,只需要填充好Flow_StepRule表 表结构:Flow_StepRule表主要是字段对比值,所以需要操作符,我们约定操作符为=.>.<

原文:构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(45)-工作流设计-设计步骤 系列目录 步骤设计很重要,特别是规则的选择. 我这里分为几个规则 1.按自行选择(在起草时候自行选审批人,比较灵活) 2.按上级(无需指定,当时需要知道用户的上司是谁,可以在职位管理设置,或者在用户表直接设置) 3.按职位(选择职位,直接获得该职位的人员) 4.按部门(按部门,直接获得该部分的人员) 5.按人员(设置步骤时就指定人员) 以上用户必须和部门,职位,上级有所关联

原文:构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(44)-工作流设计-设计表单 系列目录 设计表单是比较复杂的一步,完成一个表单的设计其实很漫长,主要分为四步. 开始之前先说说表的结构. 其实表Flow_Form与Flow_FormContent设计是有一个缺陷的.我总共是设置最高26个字段从A~Z如果超过26个字段的表单是属于硬编码的.但是我认为26个字段已经足够 因为这里我是单表模式比起表关联无限字段理论上性能会更加快,特别是当数据库申请带到千万级

原文:构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(43)-工作流设计-字段分类设计 系列目录 建立好42节的表之后,每个字段英文表示都是有意义的说明.先建立,就知道表的关系和用处了,当然,我的设计只是一个参考,你可能有很多改进的地方. 我们的工作流具体细节流程是这样的: 最终我们的模块也是这样的,最后理想也是这样的.现在从表单设计入手一步一步来. 今天解决分类管理,字段管理 准备开始 1.同样启用代码生成器生成最基础的源码.把表和目录都创建起来,每一个

原文:构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(42)-工作流设计01 工作流在实际应用中还是比较广泛,网络中存在很多工作流的图形化插件,可以做到拉拽的工作流设计,非常简便,再配合第三方编辑器,可以直接生成表单,我没有刻意的浏览很多工作流的实际设计,我认为工作流只要有动态可修改的流转,有时可按角色,部门,上级或者职位流转即是比较好的正常工作流!这里只带给一个思路的简单工作流... 工作流其实有几种,也可以设计得很简单: 1.固定的工作流,很小的公司,

自从开源OA系统启动:系统概览放 出来后.园友们反馈了一些不错的建议.主要集中在工作流部分.本来是先不考虑工作流部分.这些天的交流和思考.决定把工作流部分作为系统基础结构贯穿整个 系统.所以先考虑了这个部分的设计,因为这部分的设计是否合理关系到整个系统是否可以继续和是否有实际价值的问题.自己不敢独断专行.特放出来.让大家拍 拍砖.期待各位园友一如即往提供专业意见! 本来打算用尝试用MindManager画个思维导向图的,不过down了N久都没down下来,也就做罢了.1,基础部分数据库设计.  

原文:http://www.cnblogs.com/kwklover/archive/2007/01/13/bpoweroa_03_baseandworkflowdesign.html自从开源OA系统启动:系统概览放 出来后.园友们反馈了一些不错的建议.主要集中在工作流部分.本来是先不考虑工作流部分.这些天的交流和思考.决定把工作流部分作为系统基础结构贯穿整个 系统.所以先考虑了这个部分的设计,因为这部分的设计是否合理关系到整个系统是否可以继续和是否有实际价值的问题.自己不敢独断专行.特放出来.

通达OA网络教学公开课開始了.有须要的小伙伴们抓住机会奥. 8月29号晚8点不见不散.本次课程的主要内容是通达OA工作流设计课程中须要用到的Html部分学习. 帮忙转发的朋友加送一节VIP课程.

最近接了个小项目10K.用了2个下班时间写完,共花费了6-7个小时完成.如有同类需求的可以与本人联系,QQ:120772981 功能目标: 需要写一个仿PPT画泳道图的组件.之前写过工作流的组件,其实这个跟工作流组件基本一样,所以写这个也得心应手.PPT的效果图如下, 在C#winform里面想要及支持手动拖拽又要只支持自定义的一些功能, 很会想到拖拽控件,控件直接放图片不就的了吗?这样也可以, 但后续控件元素越来越大的时候,可能会出现控件闪屏,严重的可能性能都跟不上,再有如果用户需要放大和缩小

系列目录 建立好42节的表之后,每个字段英文表示都是有意义的说明.先建立,就知道表的关系和用处了,当然,我的设计只是一个参考,你可能有很多改进的地方. 我们的工作流具体细节流程是这样的: 最终我们的模块也是这样的,最后理想也是这样的.现在从表单设计入手一步一步来. 今天解决分类管理,字段管理 准备开始 1.同样启用代码生成器生成最基础的源码.把表和目录都创建起来,每一个类都是对应每一个表. 2.在App.Admin---->Areas---->创建Flow文件夹 3.修改路由规则 using

系列目录 设计表单是比较复杂的一步,完成一个表单的设计其实很漫长,主要分为四步. 开始之前先说说表的结构. 其实表Flow_Form与Flow_FormContent设计是有一个缺陷的.我总共是设置最高26个字段从A~Z如果超过26个字段的表单是属于硬编码的.但是我认为26个字段已经足够 因为这里我是单表模式比起表关联无限字段理论上性能会更加快,特别是当数据库申请带到千万级数据的时候(你自己可以设计更加灵活的表单管理) Flow_Form的A~Z对应的是Flow_FlowAttr表中的数据, F