Delphi

2020年使用Delphi的25个理由(我觉得四个优点:控件+可视化开发+跨平台+数据库,还有一个编译快,运行快)

China☆狼群 提交于 2020-02-28 06:49:52
25年后从10个使用Delphi的理由到1个至25个使用Delphi 10.3的理由 25年前发布Delphi 1时,我汇总了使用Delphi的十大理由。 这是我精通Delphi原始书的序言中的原始列表: “可以使用许多编程环境,但是Delphi之所以出色,有很多原因。 以下是我以相反顺序使用Delphi的十大理由: 10.以前的Borland Pascal和C++编译器 9.第三方组件和工具 8.编辑器,调试器,浏览器和其他工具 7.库源代码的可用性 6.基于表单和面向对象的方法 5.快速编译器 4.数据库支持 3.与Windows编程紧密集成 2.Delphi的组件技术 1.对象Pascal语言” 现在,经过了这么多年,什么会成为前十名,或者更好的“使用Delphi的25大理由”列表? 这次,我不会以任何顺序对它们进行排序,并保留所有仍适用的内容(提示,全部!): 1. Object Pascal语言 2. 丰富的第三方组件和工具生态系统 3. IDE本身,以及编辑器,调试器和其他工具 4. 库源代码的可用性 5. VCL仍然是本机Windows开发的最佳组件库,迄今为止,它在25年内更加稳定,并且包含所有Windows API,包括COM和WinRT。 6. FireMonkey库具有为在台式机和移动平台上运行的应用程序的UI编写单一源代码的能力,并涵盖5个操作系统 7.

delphi下element-ui 开发

半城伤御伤魂 提交于 2020-02-28 02:26:55
案例使用delphiwebmvc框架开发 登录界面代码 <html> <#include file="/include.html" /> <body> <div id="app" style="margin-left: auto; margin-right: auto; margin-top: 100px; width: 350px;"> <h1>{{title}}</h1> <el-form class="apply-form first-form" :model="formData" :rules="rules" ref="form"> <div> <table style="width: 100%;"> <tr> <td style="width: 60px;font-family:Helvetica Neue;">用户名</td> <td> <el-input v-model="formData.username" clearable></el-input> </td> <td style="width: 80px;"> <el-form-item style="height:1px;" prop="username"></el-form-item> </td> </tr> <tr> <td>密码</td> <td> <el-input v-model="formData

对于《关于使用Delphi XE10 进行android开发的一些总结》的补充

纵然是瞬间 提交于 2020-02-27 14:24:54
看了一篇《关于使用Delphi XE10 进行android开发的一些总结》有些想说的。 以下内容有复制原文,正常字体显示的是原文,黑体是我想说的。 我并不想讨论什么样的开发语言更优秀,只希望能以我自己的体会、总结的使用情况,说出我的感受 如果说, 再有新项目, 让我选择用Java还是Delphi, 那么, 我会毫不犹豫的选择使用 Java… (选择什么语言开发,都是各自的权利,没什么应该或不应该) 不可否则, Delphi在界面上, 确实没的说, 搭建速度快, 所见即所得, 传说的一份代码多平台使用(确实可以在ios下运行, 但是也会存在不少问题) (无论什么系统,都会存在问题,Delphi做的时候肯定也会有问题,我们应该理性的去区分出现问题的根源,有部分朋友只要一发现问题就说是XX的问题,这样是不正确的、不科学的、不客观的) 但是, 由于以下几个问题, 导致我完全, 再也不想用Delphi做Android开发了: 应用第三方Jar包非常麻烦 首先, 要用第三方工具, 将jar转换成pas; 其次, 转换后也不一定可以直接使用, 需要逐步的排查错误, 导入需要的文件; 无所谓, 反正arcgis map的5W行pas文件, 我都调试通过了… (Delphi使用Jar包其实已经非常方便了,我做过很多调用JAR方面的技术工作,总结一下:调用Jar确实不好做,非常多的坑

发布“点我网”的挂机小程序

与世无争的帅哥 提交于 2020-02-27 13:42:12
下班了,把这两天利用业余时间写的“点我网”挂机小程序放上来吧。这是应网友的要求,分析了“点我网”的程序运行过程,采用MSHTML组件开发,功能比较简单。希望对网友有用。 程序在开发过程中,走了点歪路。原本想用VS2005开发的,在调试过程中,发现VS2005中的WebBrowser不好控制Frame内页面。上网查询后,以为用delphi开发比较合适,好在以前也用过D7,虽然功能也都实现了,但觉得用了VS.NET回头再用Delphi,有太多的不顺手。最后一细想,不都是用MSHTML组件,Net也一样能实现,写起代码来还轻松,于是,又回过头来,打开VS2005....... 现将这两个版本的程序都放上来,写得匆忙,正在测试,欢迎大家多提意见! 下载1(不需要DotNet框架,适合广大用户) 下载2(需要DotNet框架 ) 来源: https://www.cnblogs.com/yuanbao/archive/2007/09/03/880537.html

这一顿神操作!我把 3000 行代码重构成 15 行!

我怕爱的太早我们不能终老 提交于 2020-02-27 02:43:40
作者:马非码 博客园: https://www.cnblogs.com/marvin/p/4133973.html 如果你认为这是一个标题党,那么我真诚的恳请你耐心的把文章的第一部分读完,然后再下结论。如果你认为能够戳中您的 G 点,那么请随手点个赞。 把三千行代码重构为 15 行 那年我刚毕业,进了现在这个公司。公司是搞数据中心环境监控的,里面充斥着嵌入式、精密空调、总线、RFID的概念,我一个都不懂。还好,公司之前用Delphi写的老客户端因为太慢,然后就搞了个Webform的替代,恰好我对Asp.Net还算了解,我对业务的不了解并不妨碍我称成为这个公司的一个程序员。小公司也有小公司的好,人少,进去很快负责代码开发。我当然也就搞这个数据中心智能管理系统啦。 这个系统非常的庞大,尤其牛逼的是支持客户端组态,然后动态生成网页,数据还能通过Socket实时监控(那时我还真就不懂网络编程)。这个对于当时的我来说,真真是高、大、上呐!!当时跟着了解整个系统大半个月才算能够调试,写一些简单的页面。 在维护系统的过程中,时不时要扩展一些功能,也就接触了下面这个类: 看到没有,就是当年最最流行的三层架构的产物,对于刚出茅庐的毛头小子来说,这是多么专业的文件头注释,还有反射也就算了,这构造函数还能静态的,还能私有的?那时刚接触这么高大上的代码的我,瞬间给跪了! 但是,类写多了,我就感觉越来越别扭

* .h或* .hpp用于您的类定义

£可爱£侵袭症+ 提交于 2020-02-26 13:24:39
我总是使用 *.h 文件作为我的类定义,但在阅读了一些boost库代码后,我意识到它们都使用 *.hpp 。 我一直厌恶那个文件扩展名,我想主要是因为我不习惯它。 使用 *.hpp 不是 *.h 什么优缺点? #1楼 您使用哪种扩展名无关紧要。 任何一个都可以。 我使用 *.h 代表C, *.hpp 代表C ++。 #2楼 你可以随意打电话给你的包。 只需要在 #include 指定全名即可。 我建议如果你使用C来使用 .h 和使用C ++时使用 .hpp 。 它最终只是一个惯例。 #3楼 Codegear C ++ Builder将.hpp用于从Delphi源文件自动生成的头文件,以及.h文件用于“自己的”头文件。 所以,当我写一个C ++头文件时,我总是使用.h。 #4楼 在我90年代早期的一个工作中,我们分别使用.cc和.hh作为源文件和头文件。 我仍然喜欢它的所有替代方案,可能是因为它最容易打字。 #5楼 我最近开始使用 *.hpp 用于c ++标头。 原因是我使用emacs作为我的主编辑器,当你加载 *.h 文件时它会自动进入c模式,当你加载 *.hpp 文件时它会进入c ++模式。 除了这个事实,我认为没有充分理由选择 *.h 不是 *.hpp ,反之亦然。 来源: oschina 链接: https://my.oschina.net/u/3797416/blog

快速应用开发(RAD)平台

风格不统一 提交于 2020-02-26 08:26:26
过去几年中,现代软件开发的整体环境发生了巨大的变化。对我个人来说,这种变化与宇宙的加速膨胀差不多。第二个千年刚到来时,产业的发展看起来还不是那么快,只是逐步在前进。现在技术发展的复杂度和多样性已经可以用超音速来形容了,越来越快,出现了新的编程语言、开发工具、开发方法论等等。 由于类似 Uber、Facebook、Google 这样的企业需要构建全球解决方案的需求越来越多,使得技术变得更加全面也更加复杂。这种超级的复杂度,是能构建全球性巨大系统而必须付出的代价。但是对于构建相对简单的典型业务自动化系统,我们也应该付出相同的代价吗? 业务应用系统 - 自动化的沃土 2000年代初,在“能自动化就自动化”的格言激励下,业务自动化得到了极大的发展。这种自动化的结果就是所谓的业务应用系统(LOB Applications)。这是一个非常通用的术语,描述那些终极目的就是使得业务能更有效运行的非常重要的应用程序(大部分都是定制开发)。 通常, LOB 应用程序有下列特点: l 特定领域 - 为特定领域的专业人员服务,而不是大众市场 l 以数据为中心 - 高度依赖关系型数据库,并且关系型数据库是应用程序的关键核心 l 面向事务( OLTP) - 代表系统的一致性和可用性级别(高一致性、高可用性),假设每个事务都符合 ACID l 全面的业务逻辑 - 包含大量自定义的业务逻辑和数据处理算法 l

Pascal基础(六)-C语言动态链接库

谁说我不能喝 提交于 2020-02-26 03:11:55
Pascal 调用 C语言 开发的 动态链接库, 环境: Fedora 31, gcc 9.2.1, fpc 3.0.4 C 语言的编译和链接相对简单(相对于C++), 所有只有C语言的动态链接库的调用方法记录,C++本身就复杂,编译和链接自然也复杂, 个人 猜测 ABI 一致也相对较难,暂不涉及 有时间会记录一篇Pascal编译为dll, 供C语言调用的例子 C语言动态链接库源码 //simplemath.h #ifndef SIMPLEMATH_H #define SIMPLEMATH_H #include <stdlib.h> typedef enum LoLevel_{ llDebug, llInfo, llWarn, llError, llFatal }LogLevel; typedef struct Student_{ int id; char name[20]; }Student; /* int plus_int(int a,int b); int max_int(int x,int y); void swap_int(int* x,int* y); int swap_void(void *a,void* b,size_t t); void logger(char* msg,LogLevel level); */ #endif //simplemath.c

Delphi编写自定义控件以及接口的使用

你说的曾经没有我的故事 提交于 2020-02-26 01:56:20
写给觉得自己编写Delphi很复杂的人,包括自己。 Delphi自己写控件其实并不难,难的在于开发复杂的控件。(其实,编程,很多东西都是会了就不难,因此,我怕自己日后觉得自己写控件很难,特意在这记录自己写控件的过程,顺便也写下接口的使用) 第一步:控件代码: 下面是控件的一个Unit内容: unit pgdbedit; interface uses SysUtils, Classes, Controls, StdCtrls, CnEdit; const IID_pgDBConInterface='{88CEA70D-0506-4CC0-ABB0-4BDBFA0DDBCE}'; type TdbType = (dbText, dbInteger, dbFloat, dbBit, dbTime, dbBlob); //文本类型 IpgDBConInterface = interface(IInterface) //定义数据库操作控件的接口 [IID_pgDBConInterface] //Stdcall是指示函数的参数入栈方式是从右到左 function GetCanUpdate: Boolean; procedure SetCanUpdate(value: Boolean); property DB_canUpdate: Boolean read GetCanUpdate write

Implementing VirtualTreeView TVTDefaultAccessibleProvider in C++ Builder

时光总嘲笑我的痴心妄想 提交于 2020-02-25 23:06:28
问题 When using VirtualStringTree to add accessibility support it is required to include the unit VirtualTrees.Accessibility in the uses section. This works in Delphi. The equivalent of this in C++ Builder would be to include the #include "VirtualTrees.Accessibility.hpp" . But including the include file doesn't have any effect. I've traced the problem to the VirtualTrees.Accessibility.pas file and it executes a few lines of code to register the default accessibility provider in Delphi while this