Visualization and HMI Toolkit的为开发高级图形的动态界面而设计的艺术化的框架:它不仅仅是简单的按键与菜单,它是全动态的能显示动态数据以及能反映用户互动的图片对象。它不仅仅是能制作“漂亮图片”绘制工具(它还具有很多其他功能),而是能使开发人员定义图片对象以及与程序中的对象互动的图形引擎。它的使用对象主要针对应用程序开发人员,能将乏味的低级别图片代码编译工作转化成高级的互动设计行为。
GLG工具包Visualization and HMI Toolkit更新至v3.6,点击下载>>>
支持Java Script:
对Java Script的增加的支持使得用户可以定义自定义函数,将多个输入值转换为驱动动画的输出值。通过可以添加到对象属性的新Java Script转换来使用Java Script。例如,一个新的“LED Value Display”部件可以通过使用Java Script转换来实现部件的逻辑。
转换的Java Script属性包含用于生成输出值的Java Script代码。转换的Arg List属性通过$ N符号提供脚本中使用的可变的参数,其中N是基于1的参数索引(即 $ 1是第一个参数)。参数可以是双(D)、字符串(S)或XYZ(G)类型。Java Script转换的输出值也可以是D、S或G类型,与其所附属性的类型相匹配。
例如,可以使用以下Java Script将D属性的值设置成以度为单位的第一个参数的sin函数:Math.sin ($ 1 / 180. * Math.PI)
下面的Java Script可用于根据第一个参数的值和由第二个、第三个参数定义的阈值来在“NORMAL” 和“ALARM”之间切换的文本字符串:$ 1 <$ 2 || $ 1> $ 3?“ALARM”:“NORMAL”
对于复杂的Java Script来说,可以通过Java Script文件提供Java Script函数和方法库。加载此文件时,可以在图形中使用该文件中定义的Java Script函数。
应用程序可以使用包含Java Script方法集合的全局Java脚本文件并在应用程序的图纸中使用。该文件将被预加载并用作Java Script库。Viewport的JavaScriptFile属性也可定义为该viewport预加载的Java Script文件。所有加载的Java脚本都是全局的,可以在应用程序的任何位置访问。从Java Script文件加载的函数将覆盖任何以前具有相同名称的Java Script函数。
GLGeditors和所有GLG API都支持Java Script:C / C ++、Java、C#和Windows上的ActiveX。C / C ++和ActiveX中的Java Script支持由Duktape JavaScript Engine提供,对于C#来说可以使用Jurassic JavaScript引擎(由Jurassic.dll提供)。在Java中可以使用Java的JavaScript引擎。
所有Java Scripts都在绘图设置时先行编译,以实现更快的运行。这些脚本也可以进行缓存。
GlgJavaScriptFile全局配置资源或GLG_JAVA_SCRIPT_FILE环境变量可用于指定全局Java Script文件。 对于GLG Builder和GLG HMI配置器,还可以通过-glg-java-script-file命令行选项或GLG配置文件中的GlgJavaScriptFile资源(即glg_config或glg_hmi_config)提供全局Java Script文件。





pdf2cad是一款可将PDF文件转换成CAD格式的转换工具。仅需几秒钟,便可将所提取的准确图形在常规的CAD工具中进行修改,如AutoCAD, TurboCAD和MicroStation。pdf2cad可将PDF工程图输出为DWG, DXF和HPGL格式。pdf2cad格式转换工具适用于Windows或Mac OS X操作系统。
pdf2cad v11提供了许多新功能和增强功能,包括64位版本,支持所有当前的Windows和Mac操作系统,处理受密码保护的PDF文件,更多地控制图像,灵活的页面编号,其他方法来分隔图层等等。






















Java社区进程(JCP)执行委员会的成员Ben Evans认为最急需重构的应用恰好就是最适合进行模块化的应用。如果你已经备受Lava Flow/God Class/Stovepipe System地狱的折磨,而且你的利益相关方明确知道这一点,那么你可能更容易说服他们进行一次完整的底层重构,通过渐进式的努力形成一个完成的模块解决方案(而不是简单重构并迁移至Java 8)是值得去做的。
对特定类型的应用来说,这是很有帮助的。例如,我曾经见到有的电子商务网站具有非常大的堆空间,其中包含了大约40G的字符串数据。Java 9的ompact Strings技术能够将这种类型的内存使用减半。这反过来又会对GC的性能带来积极的影响。对于有些应用来说(这可能就包括大型的Solr安装环境及类似场景),单单这一项收益就值得将运行时升级到Java 9。
这项变更是很重要的,因为相对于Parallel来说,G1会在应用线程上做更多的事情,而Parallel几乎没有在应用线程上做任何事情,它基本上完全依赖GC线程完成所有的内存管理。这意味着切换到G1将会为应用线程带来额外的工作,从而直接影响到应用的性能。 在很多(甚至可以说大多数)场景中,这种额外的性能损耗都不是什么问题。但是,在这方面,我确实也曾经见过从Parallel切换到G1时,有一定比例的工作负载会引起性能的下降。对于这些应用来说,这种性能下降是无法接受的,所以他们无法切换至G1收集器。随着G1成为默认的收集器,这将会影响到升级至Java 9的每个应用。
