xml使用的还是比较多的,duilib界面也是通过xml配置实现的 duilib提供了CMarkkup和CMarkupNode类解析xml,使用起来也是比较方便的,比较好奇它是怎么实现的,如果自己来写一个 解析又需要怎样架构,架构之路还很遥远... 先来看看头文件吧,CMarkup主要是用于分割xml,判断xml格式是否正确:CMarkupNode主要是将CMarkup分割的xml,获取节点中的属性, 最多支持64个属性 enum { XMLFILE_ENCODING_UTF8 = ,//定义编

时隔5个月才有时间接着写未完成的实现部分,也是惭愧呀 选几个关机的函数来解析,一些get方法就忽略掉吧 CMarkupNode 与 CMarkUp 互为友元类,CMarkUp 实现解析,CMarkupNode 用于存储读取节点数据 void CMarkupNode::_MapAttributes() { m_nAttributes = ; LPCTSTR pstr = m_pOwner->m_pstrXML + m_pOwner->m_pElements[m_iPos].iStart; LPC

在<Duilib源码分析(一)整体框架>.<Duilib源码分析(二)控件构造器—CDialogBuilder>以及<Duilib源码分析(三)XML解析器—CMarkup>中我们已从粗略的角度去分析框架操作流程和消息流程,只能对其有基本的印象,此处我们将通过实际的举例分析,duilib创建的工程,在整个资源解析.控件创建.控件加载与绘制,控件数据处理等管理的整个过程进行整合: 为了便于分析,我们仍然从项目中附带的工程“TestApp1”进行更深入的学习,以下执行流程为

Duilib界面库是一款由杭州月牙儿网络技术有限公司开发的界面开源库,以viksoe项目下的UiLib库的基础上开发(此后也将对UiLib库进行源码分析):通过XML布局界面,将用户界面和处理逻辑彻底分离,极大地提高用户界面的开发效率.一般常用于开发小型项目Windows桌面客户端软件:其子窗口不以窗口句柄的形式创建,只是逻辑上的窗口,绘制在父窗口之上.目前开源协议以BSD发布,可使用于商业应用,好了,其他更为详细的介绍,请查阅其官网或百度. 源码获取: 目前duilib不在被维护,基本上网络中

* 本文速览 由于本篇文章篇幅比较大,所以这里拿出一节对本文进行快速概括.本篇文章对 MyBatis 配置文件中常用配置的解析过程进行了较为详细的介绍和分析,包括但不限于settings,typeAliases和typeHandlers等,本文的篇幅也主要在对这三个配置解析过程的分析上.下面,我们来一起看一下本篇文章的目录结构. 从目录上可以看出,2.3节.2.5节和2.8节的内容比较多.其中2.3节是关于settings配置解析过程的分析,除了对常规的 XML 解析过程分析,本节额外的分析了元

百篇博客系列篇.本篇为: v53.xx 鸿蒙内核源码分析(ELF解析篇) | 你要忘了她姐俩你就不是银 | 51.c.h.o 加载运行相关篇为: v51.xx 鸿蒙内核源码分析(ELF格式篇) | 应用程序入口并不是main | 51.c.h.o v53.xx 鸿蒙内核源码分析(ELF解析篇) | 你要忘了她姐俩你就不是银 | 51.c.h.o v54.xx 鸿蒙内核源码分析(静态链接篇) | 完整小项目看透静态链接过程 | 51.c.h.o v55.xx 鸿蒙内核源码分析(重定位篇) | 与国

子曰:"苟正其身矣,于从政乎何有?不能正其身,如正人何?" <论语>:子路篇 百篇博客系列篇.本篇为: v72.xx 鸿蒙内核源码分析(Shell解析篇) | 应用窥视内核的窗口 进程管理相关篇为: v02.06 鸿蒙内核源码分析(进程管理) | 谁在管理内核资源 v24.03 鸿蒙内核源码分析(进程概念) | 如何更好的理解进程 v45.05 鸿蒙内核源码分析(Fork) | 一次调用 两次返回 v46.05 鸿蒙内核源码分析(特殊进程) | 老鼠生儿会打洞 v47.02

上一节介绍了控件构造器CDialogBuilder,接下来将分析其XML解析器CMarkup: CMarkup:xml解析器,目前内置支持三种编码格式:UTF8.UNICODE.ASNI,默认为UTF8:CMarkupNode:xml节点类 先介绍CMarkup: XMLELEMENT: xml节点元素类型定义,iStart,节点元素在xml文件中的起始位置:iChild,节点元素子节点:iNext,节点元素的下一个节点(兄弟节点):iParent,节点元素的父节点:iData, 节点元素的数据

在 Spring Developer Tools 源码分析一中介绍了 devtools 提供的文件监控实现,在第二部分中,我们将会使用第一部分提供的目录监控功能,实现对开发环境中 classpath 的监控. 二.类路径监控 首先看一些这一部分可能涉及到的类图: 在图中,红色斜线左上部分是第一部分中介绍的文件目录监控的类,其中 FileSystemWatcher 会通过独立线程监控指定的目录,当目录内容发生变化时,通过对比快照可以获得所有监控目录变化的文件ChangedFiles,然后将变化通知

在<MyBatis框架中Mapper映射配置的使用及原理解析(二) 配置篇 SqlSessionFactoryBuilder,XMLConfigBuilder> 一文中,我们知道mybatis配置文件是由XMLConfigBuilder来解析的,看以下代码: public Configuration parse() { if (parsed) { throw new BuilderException("Each XMLConfigBuilder can only be used on

项目中用的dubbo的挺多的,然后随着自己对dubbo的慢慢深入,自己也希望能够了解dubbo的底层实现,这半年来一直在看dubbo的源码,有点断断续续的,于是准备写一个dubbo源码系列的分析文章,一来方便自己总结,二来也能够让自己的学习有输出分享. 整个系列会从dubbo的xml到bean到生产者启动-注册到消费者订阅-调用的这一主线,然后会穿插一些相关的负载均衡.熔断.过滤器.监控.spi等等.让我们进入一个全新的世界吧,let's go 1.如果你好奇为什么配置了xml文件dubbo就可

Thinkphp6源码解析之分析 路由篇-请求流程 0x00 前言: 第一次写这么长的博客,所以可能排版啊,分析啊,什么的可能会比较乱.但是我大致的流程已经觉得是说的够清楚了.几乎是每行源码上都有注释.关于请求流程大概是: 入口文件先实例化容器,然后再通过容器去获取到Http对象 (Web管理类),然后执行Http对象中的run方法. 方法内会创建一个Request对象,然后将对象绑定到容器内.然后再到runWithRequest方法,执行应用程序 runWithRequest方法内会初始化当前

本文的源码基于Jetty9,主要分析了Jetty 的Connector与Server类间在Jetty启动过程中的一些细节.Jetty9 对以前的Connector体系进行了重构, 结构与6和7都不同,原有的一些BIO类已经被抛弃. 先看Server 构造函数 public Server(@Name("port")int port) { this((ThreadPool)null); ServerConnector connector=new ServerConnector(this);

XML <?xml version="1.0" encoding="UTF-8"?> <root> <!-- MySQL --> <dbms value="MySQL"> <cast query="CAST(%s AS CHAR)"/> <length query="LENGTH(%s)"/> <isnull query=&quo

上一节了解了大体流程,但是界面控件元素是如何被加载.解析.构建.管理.控件消息如何处理的呢?接下来我们将结合控件构造器进行分析: CDialogBuilder:控件构造器,主要用以解析xml配置文件并以此创建相应控件及相关属性. 类成员数据: m_xml:xml解析器,用以读取并解析xml配置文件: m_pCallback:构造器回调函数,用以给予用户可以实现自定义的构造控件对象的方式: m_pstrtype:以NULL为结束符的字符串,资源类型,参数含义同EnumResLangProc函数中的

tp框架作为国内主流框架,目前已经发布了6.0版本,相当于3.*版本是进行了重构,今天我们从源码的角度来研究下tp5.1自动加载的实现 作为单入口框架,从入口文件看起,入口文件在public/下,那么为什么大多数框架要把入口文件放到子文件夹下面呢? 第一,为了动静分离,因为现在的tp框架一般都是单入口,既然是单入口,那么必然要做rewrite,如果把静态文件和程序文件放到一起. 框架路由势必要对每一个请求进行筛选,所以这些框架不约而同的把资源文件和程序文件区分开来,放在了不同的文件夹下面,所以从

ChannelPipeline 负责channel数据进出处理,如数据编解码等.采用拦截思想设计,经过A handler处理后接着交给next handler ChannelPipeline 并不是直接管理handler 而是通过 context 包装管理,一般以context 命名的是个重量级对象,提供给多层使用 public interface ChannelPipeline extends ChannelInboundInvoker, ChannelOutboundInvoker, Ite

接下来,继续分析duilib之UI布局Layout,目前提供的布局有:VerticalLayout.HorizontalLayout.TileLayout.TabLayout.ChildLayout分别为垂直布局.水平布局.平铺布局.TAB布局.子窗体布局: 一般项目中用得比较多的是垂直布局.水平布局,我们将分别分析各布局: VerticalLayout:垂直布局,继承于CContainerUI容器UI类:而CContainerUI也继承于CControlUI,故VerticalLayout实际

接下来,分析uilib.h中的WinImplBase.h和UIManager.h: WinImplBase.h:窗口实现基类,已实现大部分的工作,基本上窗口类均可直接继承该类,可发现该类继承于多个类,我们将对其父类逐一分析,然后整合分析该窗口实现基类,我们按照继承顺序开始 接下来的分析:   CWindowWnd:UIBase.h中的窗口类,已在前面章节作了分析,主要实现了基本的窗口注册.创建.显示.消息处理等基本的封装显示,这样WindowImplBase已具备窗口类的基本特征:   CNot

接下来,我们将继续分析UIlib.h文件中其他的文件, UIContainer.h, UIRender.h, WinImplBase.h, UIManager.h,以及其他布局.控件等: 1. UIRender.h:UI渲染器,其中cpp文件中,定义的ZIP压缩相关的数据结构,以及宏操作,与XUnzip.cpp中一样的(个人认为可以提取出来作为共用的一部分),此外还有stbi_load_from_memory.       stbi_image_free,涉及到图片加载操作,具体详细细节可参考s