所有由雷老虎发布的文章

简单方法搞定日期格式转换的问题

    程序中经常会用到日期和字符串之间的转换,由于计算机的区域设置(日期格式设置)的不同,会导致在A计算机上运行正确的程序在B计算机上就出问题。如何搞定这些问题?
    字符串–>日期的转换:StrToDate函数,这个函数有两个实现,分别是:
      StrToDate(const S: string): TDateTime
      StrToDate(const S: string;const FormatSettings: TFormatSettings): TDateTime;
      如果我们的字符串格式是固定的话,如yyyy-MM-dd,用第一个的话,会很容易在不同日期格式设置的计算机上出问题。所以要用第二个,但是FormatSettings这个参数怎么设置呢?
      var
        FormatSettings:TFormatSettings;
      ————————————————-
      FormatSettings.ShortDateFormat := ‘yyyy-MM-dd’;   // 这里设置成和字符串中的日期格式一致的格式
      FormatSettings.DateSeparator := ‘-‘;
      FormatSettings.LongDateFormat := ‘yyyy-MM-dd’;    // 这里设置成和字符串中的日期格式一致的格式
      如何保证由日期转换出来的字符串的格式是固定的呢?用 FormatDateTime(‘yyyy-MM-dd’,date);

    日期–>字符串的转换:
      除了上面提到的可以转换成固定格式的字符串外,有时候其实我们是想转换成计算机的缺省日期格式(事先无法知道目标计算机的日期格式,比如说,我们要拼一个SQL语句,这里面的日期格式最好就是和计算机一致的,否则可能会在数据库里进行自动转换成日期的时候出错,这种情况我们只需要用DateToStr(date)就行了。
      顺便说一句,Access数据库中SQL语句里表示日期的话需要前后都加上#,而不是SQL Server等数据库里前后加单引号(自动由字符串转换为日期)。

修改Delphi源代码并生成可以发布的无BUG BPL

    Delphi虽然是一个相当棒的RAD工具,但是难免也有小的瑕疵。遇到这种情况我们往往会找到Delphi/Source中的源代码进行修改,把这个源代码加入我们的Application,重新编译一下可执行程序就解决了这些小虫子。
    但是如果我们要发布的是应用程序是“Build with runtime packages”(就是说,要连同该应用用到的BPL一起发布才能正常运行应用程序),我们可能需要把诸如VCL70.bpl,RTL70.bpl一起发布。可是这些BPL都是安装Delphi时自带的,如果发布这些BPL的话,其中的BUG也会一起发布,有没有办法打造一个没有BUG的BPL文件呢,就是说如何修改并重新生成系统已有的BPL呢?
    下面我们就演示一下修改VCL70.bpl的方法:New 一个Package,在这个Package中创建一个普通的Form,Compile一下这个Package,会提示加入VCL,当然要同意了。这个时候可以看到在Requires里有一个vcl.dcp,双击它,会自动产生一个vcl.dpk,另存为vcl70.dpk,可能会有其他提示不管它。然后再编译一下(编译有问题的话,用dcc32命令行编译),缺省生成的vcl70.bpl存放在Delphi/Projects/Bpl下。这个就是你修改过Delphi源代码生成的无BUG的BPL,拷出来随便发布吧,如果怕和系统的弄混,可以改一下这个Package的版本号再生成。
    如果要修改的是其他的包呢?很简单,刚才是New了一个Form,因为TForm在VCL中所以会看到Requires里增加了VCL,如果增加的是另一个包里的内容,或者引用了另一个包的单元,自然就会提示你并自动在Requires里加入相应的DCP了,其实最终目的还是要看到这个DCP双击它自动打开一个DPK工程。
    另外,这个方法只能适用于有源代码的包,废话啦,没有源代码怎么修改BUG。
    有的同志会把vcl.dpk命名成其他的名字,这样也没问题,随自己高兴怎么改就怎么改。

BPL包无法调试的问题

    由于系统结构是Host主程序动态加载BPL包的模式。所以用到了Package的调试,但无论如何有一个包就是无法调试(加断点不起作用)。经过N久的查找,发现:
    1.包Package在编译,生成的时候会自动产生DCP和BPL文件,缺省产生到Delphi/Projects/BPL下。
    2.BPL文件的生成路径可以在Project/Options/Directories中修改
    3.多个Package联合调试时,最好把DCP生成在同一个路径下,并且在Tools/Invironment Options/Library的Library Path中添加。
    4.调试时Delphi在Library中按从上到下的顺序搜索DCP文件,如果第一个搜索到的DCP和最新的源代码是配套的,会进入调试,否则不会进入调试。

    我遇到的问题是这样造成的:首先保存了一个包,顺手Build了一下,这时候生成的BPL和DCP都在Delphi/Projects/BPL下。后来又改了Project中的DCP生成路径,生成到专门放DCP的文件夹。在后来的运行调试中,由于系统第一个会找到我生成到Delphi/Projects/BPL下的那个没有任何功能的DCP,自然和我目前的BPL是不匹配的,所以就无法调试。

    做开发不能调试实在是太痛苦了,终于在忍耐了一周之后要彻底解决这个问题,吃过晚饭七点多搞到现在凌晨两点,才算是搞清楚了,以后再也不会被包的调试困住了。

不能在Kettle目录外运行kitchen.sh(含官方解释)

you can’t run kitchen.sh from outside the kettle directory cuz the script sets LIBPATH to be a relative path.to fix, you should change to an absolute path. though i’m not sure why you need LIBPATH here, cuz it seems like kitchen should need these libs cuz it doesn’t use the graphics libraries. only spoon should need that stuff.–alex

 下面是该BUG的跟踪情况: