小编SOU*_*ser的帖子

借助于Sertac Akyuz它,似乎直接原因与charset有关\bullet:在我的本地化Windows中,\bullet输入Alt(0149)总是得到输入\fcharset134,并且尝试通过改变其字体EM_SETCHARFORMAT总是失败(好吧,颜色,大小,样式确实可以改变但不是字体系列名称).

因此,最简单的解决方法是首先重置字符集,然后更改字体.

注意:应该使用RichEdit (版本> = 4.1)!

注意:RichEdit版本可以在MSDN的About Rich Edit Controls,Murray Sargent的MSDN Blog RichEdit版本和RichEdit版本更新到7.0中找到.后面的页面提到RichEdit版本高于4.1.作为测试,我将使用Office 2010的RICHED20.DLL与应用程序一起复制到Windows 2000,一切都像一个魅力!

procedure TMainForm.ButtonFontClick(Sender: TObject);
var
  format: TCharFormat2;
begin
  if dlgFontCdxTxt.Execute then
  begin
    FillChar(format, sizeof(format), 0);
    format.cbSize:= Sizeof(format);
    format.dwMask:= CFM_CHARSET;
    format.bCharSet := 1; // or 0;
    redtTextBlock.Perform(EM_SETCHARFORMAT, SCF_SELECTION, Integer(@format));

    FillChar(format, sizeof(format), 0);
    format.cbSize:= Sizeof(format);
    format.dwMask:= CFM_FACE;
    StrPLCopy(format.szFaceName, dlgFontCdxTxt.Font.Name, High(format.szFaceName));
    redtTextBlock.Perform(EM_SETCHARFORMAT, SCF_SELECTION, Integer(@format));
  end;
  redtTextBlock.SetFocus;
end;

==================================================

根据维基百科,WordPad …

综述:

1. 我一直在寻找的术语似乎是"自然的排序".

2. 对于操作系统中的行为:

   • 对于Windows(版本> = XP),Windows资源管理器使用自然排序.
   • 对于Linux终端:使用"ls -v"而不是普通的"ls"来获得自然排序.

3. 对于Delphi中的编程,使用StrCmpLogicalW Windows API进行自然排序.

4. 对于Delphi和Kylix&Lazarus中的编程,使用手工制作的函数进行自然排序:
   • (1)由Martin Pool进行自然顺序字符串比较的Delphi包装器.
     http://irsoft.de/web/strnatcmp-and-natsort-for-delphi
   • (2)来自davekeolle网站的其他语言的字母排序算法代码.
     http://www.davekoelle.com/alphanum.html
   • (3)其他知识页面:
     http://www.codinghorror.com/blog/2007/12/sorting-for-humans-natural-sort-order.html
     http://objectmix.com/delphi/722211-natural- sorting-optimize-working-solution.html
     http://groups.google.com/group/borland.public.delphi.language.delphi.general/browse_thread/thread/1141d49f8bbba577
     http://objectmix.com/delphi/401713-字母排序-例行delphi.html

==========================

将在Windows资源管理器中订购以下文件名,如下所示:

test_1_test.txt

test_2_test.txt

test_11_test.txt

test_12_test.txt

test_21_test.txt

test_22_test.txt

例如,如果我将它们放在TStringList实例中并调用Sort,则排序顺序如下:

test_1_test.txt

test_11_test.txt

test_12_test.txt

test_2_test.txt

test_21_test.txt

test_22_test.txt

为了记录,上述文件名将在Cygwin的rxvt终端或Linux发行版的xterm终端(如CentOS)中进行排序,如下所示:

test_11_test.txt

test_12_test.txt

test_1_test.txt

test_21_test.txt

test_22_test.txt

test_2_test.txt

您能否帮助评论如何理解排序行为的这种差异？此外,是否可以获得与Windows资源管理器中相同的顺序？任何建议表示赞赏!

PS:我的Windows语言环境设置为中文,但我认为英语语言环境也是如此.

总结: FRUIT只能用于Fortran编译器,尽管使用Ruby可以增强其功能.请查看以下作者Andrew Chen的答案.

===========================================

似乎Fortran的可用单元测试框架(
XUnit )包括:funit
http://nasarb.rubyforge.org/

水果
http://sourceforge.net/projects/fortranxunit/

flibs
http://flibs.sourceforge.net/

ObjexxFTK(商业)
http://www.objexx.com/ObjexxFTK.html

在他们的网页,funit,fruit和flibs中提到他们依靠Ruby来运行.我不知道ObjexxFTK.在我看来,Java,C#和Delphi等中的XUnit框架只依赖于相应的语言本身.那为什么Fortran框架选择依赖Ruby而不是Fortran呢？

以下Delphi程序在nil引用时调用方法并运行正常.

program Project1;

{$APPTYPE CONSOLE}

type
  TX = class
    function Str: string;
  end;

function TX.Str: string;
begin
  if Self = nil then begin
    Result := 'nil'
  end else begin
    Result := 'not nil'
  end;
end;

begin
  Writeln(TX(nil).Str);
  Readln;
end.

但是,在结构相似的C#程序中,System.NullReferenceException将会提出,这似乎是正确的做法.

namespace ConsoleApplication1
{
    class TX
    {
        public string Str()
        {
            if (this == null) { return "null"; }
            return "not null";    
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            System.Console.WriteLine(((TX)null).Str());
            System.Console.ReadLine();
        }
    }
}

因为TObject.Free使用这样的样式,所以在Delphi中调用nil引用上的方法似乎是"支持"的.这是真的 ？(假设在 …

根据"在Delphi中使用汇编程序",eax将包含Self.但是,eax如图所示,内容为0.我想知道出了什么问题？

procedure TForm1.FormCreate(Sender: TObject);
var
  X, Y: Pointer;
begin
  asm
    mov X, eax
    mov Y, edx
  end;
  ShowMessage(IntToStr(NativeInt(X)) + ' ; ' + IntToStr(NativeInt(Y)));
end;

*摘要:

请查看德尔福专家的知识渊博的评论.特别是对我来说,我会尝试使用旧的TList/TObjectList作为David建议,并使用hard-cast和TObjectList.List属性作为A.Bouchez建议.我将在未来重构时尝试使用TDynArray.

================================================== ===================

假设我有一个TAtom如下面代码中定义的类.目前,在运行时hundreds最多thousands有TAtom实例stored in a dynamic array.在运行时,我需要对TAtom.X/Y/Z所有现有的TAtom实例进行简单的浮点运算,30每秒多次.

现在,我需要补充的能力adding,inserting,deletingTAtom的实例在运行时.似乎我的选择是(1)请求一个大阵列; (2)坚持动态数组并手动设置SetLength; (3)切换到常规TList; (4)切换到常规TObjectList.

我想避免(1)除非有必要,因为我必须改变很多功能签名.(2)看起来也不好,因为TList/TObjectList似乎为这项任务而生.但是,因为需要使用常规TList/TObjectList进行类型转换,是否可以对可能的性能命中进行一些评论？我的意思是,如果在重写代码之前可以估算性能负担,那将是最好的.如果性能会明显下降,我还可以使用其他技术吗？

此外,我想知道使用TList和TObjectList之间是否存在性能差异？

  TAtom = class
  public
    ElementZ: Integer;
    X, Y, Z: Extended;  
    other variables: other types;
  end;

  TAAtom = array of TAtom;

在Fortran 90及更高版本中可以使用可分配的阵列.

INTEGER, ALLOCATABLE, DIMENSION(:) :: test_int_array

Fortran 2003中可以使用可分配的标量,例如可分配的字符.

CHARACTER(LEN=:), ALLOCATABLE :: test_str

我想知道是否有可能声明一个可分配字符的数组,固定或可分配？(可能就像下面的东西,不幸的是不能编译.)

CHARACTER(LEN=:), ALLOCATABLE, DIMENSION(4) :: test_str_array

总结:
假设我有一个TForm和两个面板.面板与alTop和alClient对齐.alClient面板包含一个TPaintBox,其OnPaint涉及绘图代码.

组件上DoubleBuffered的默认值为false.

在绘图过程中,闪烁是显而易见的,因为表格,面板都绘制了它们的背景.

由于表单由面板覆盖,因此拦截其WM_ERASEBKGND消息可能很好.如果没有,可以看到面板上的闪烁,并在调整窗体大小时在面板的右边缘闪烁,因为窗体会绘制其背景.

其次,因为alTop面板是一个按钮的容器,所以将DoubleBuffered设置为true可能很好,让Delphi确保它没有闪烁.它可能不会带来太多的性能负担.

第三,由于alClient面板仅用作另一个绘图组件的容器,因此该面板很可能不参与组成最终绘图.在这方面,使用TPanel后代而不是标准TPanel可能是好事.在这个TPanel后代中,覆盖受保护的过程Paint并在过程中不执行任何操作,尤其是不继承调用以避免在基类TCustomPanel.Paint中进行FillRect调用.此外,拦截WM_ERASEBKGND消息并且内部也不执行任何操作.这是因为当TPanel.ParentBackground为False时,Delphi负责重新绘制背景,当它为True时,ThemeService负责.

最后,在TPaintBox中绘制没有闪烁:
(1)使用VCL内置绘图例程,可能更好......
(2)使用OpenGL,启用OpenGL的双缓冲.
(3)......

===问:如何消除TPaintBox右边缘的闪烁？===

假设对于一个TForm,我有两个面板.顶部相对于表格对齐alTop并被视为按钮的容器.另一个是相对于表单对齐的alClient,并被视为绘制组件的容器(例如来自VCL的TPaintBox,或来自Graphics32的TPaintBox32).对于后一个面板,它的WM_ERASEBKGND消息被截获.

现在,我在以下示例代码中使用TPaintBox实例.在它的OnPaint处理程序中,我有两个选择来绘制一个我希望无闪烁的绘图.选择1是在填充矩形后绘制的.由于其父面板不应擦除背景,因此绘图应无闪烁.选择2绘制在TBitmap上,然后将其Canvas复制回paintbox.

然而,两种选择都是闪烁的,第二种选择尤其是闪烁.我主要关心的是选择1.如果你调整表格的大小,你可以看到闪烁的主要部分发生在右边缘.为什么会这样？有人可以帮助评论原因和可能的解决方案吗？(注意,如果我在这里使用TPaintBox32而不是TPaintBox,右边缘根本不会闪烁.)

我的第二个担忧是,当使用选项1时,闪烁的次要部分会随机出现在绘图箱上.如果您快速调整表单大小,它不是很明显但仍然可以观察到.此外,当使用选择2时,这种闪烁变得更加严重.我没有找到原因.有人可以帮助评论可能的原因和解决方案吗？

任何建议表示赞赏!!

    unit uMainForm;

    interface

    uses
      Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
      ExtCtrls, Dialogs;

    type
      TMainForm = class(TForm)
        procedure FormCreate(Sender: TObject);
      private
        { Private declarations }
        FPnlCtrl, FPnlScene: TPanel;
        FPbScene: TPaintBox;

        OldPnlWndProc: TWndMethod;

        procedure PnlWndProc(var Message: TMessage);
        procedure OnScenePaint(Sender: TObject);
      public
        { Public declarations }
      end;

    var
      MainForm: TMainForm;

    implementation

    {$R *.dfm}

    procedure TMainForm.FormCreate(Sender: TObject);
    begin
      Self.Color := clYellow;
      Self.DoubleBuffered := …

如本文所示,可以在C#中定义:

public class MyTreeNode<T> where T: MyTreeNode<T>
{

}

但是,在Delphi中,以下代码无法编译并抱怨"E2003 Undeclared identifier:'MyTreeNode <>'":

type
    TMyTreeNode<T: TMyTreeNode<T>> = class
    end;

正式术语似乎是"自我引用泛型约束".我想知道如何在Delphi中这样做？

PS:

David指出的另一篇有用的文章.

关于Delphi和协方差/逆变的相关SO帖子.

维基百科的co/contra-variance页面.

第一个入门示例中的“货物运行”处显示错误

C:\Users\HiWin10\hello-rust>cargo run --verbose
   Compiling hello-rust v0.1.0 (C:\Users\HiWin10\hello-rust)
     Running `rustc --edition=2018 --crate-name hello_rust src\main.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=888d1f7b91fb6e4a -C extra-filename=-888d1f7b91fb6e4a --out-dir C:\Users\HiWin10\hello-rust\target\debug\deps -C incremental=C:\Users\HiWin10\hello-rust\target\debug\incremental -L dependency=C:\Users\HiWin10\hello-rust\target\debug\deps`
error: linking with `link.exe` failed: exit code: 1181
  |
  = note: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\VC\\Tools\\MSVC\\14.12.25827\\bin\\HostX64\\x64\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\HiWin10\\hello-rust\\target\\debug\\deps\\hello_rust-888d1f7b91fb6e4a.1twe2j0sf4nhwv0v.rcgu.o" "C:\\Users\\HiWin10\\hello-rust\\target\\debug\\deps\\hello_rust-888d1f7b91fb6e4a.1vsfetqgdl2mm9ku.rcgu.o" "C:\\Users\\HiWin10\\hello-rust\\target\\debug\\deps\\hello_rust-888d1f7b91fb6e4a.2b2k1el9ge2t96a7.rcgu.o" "C:\\Users\\HiWin10\\hello-rust\\target\\debug\\deps\\hello_rust-888d1f7b91fb6e4a.2wy84pmiszi6o3fj.rcgu.o" "C:\\Users\\HiWin10\\hello-rust\\target\\debug\\deps\\hello_rust-888d1f7b91fb6e4a.51bmf9dki30948b3.rcgu.o" "C:\\Users\\HiWin10\\hello-rust\\target\\debug\\deps\\hello_rust-888d1f7b91fb6e4a.q67qbh00yussp5o.rcgu.o" "/OUT:C:\\Users\\HiWin10\\hello-rust\\target\\debug\\deps\\hello_rust-888d1f7b91fb6e4a.exe" "C:\\Users\\HiWin10\\hello-rust\\target\\debug\\deps\\hello_rust-888d1f7b91fb6e4a.11f4ns4fn9v6i7z4.rcgu.o" "/OPT:REF,NOICF" "/DEBUG" "/NATVIS:C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\libcore.natvis" "/LIBPATH:C:\\Users\\HiWin10\\hello-rust\\target\\debug\\deps" "/LIBPATH:C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-c418a1c7c96bdbae.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-740e55ec30ec9b42.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_demangle-4e3d4b2c73be2130.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libhashbrown-e03c95365300773b.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_std_workspace_alloc-9b63ec27f8df7123.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-cc811f306714ba24.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-dee84a63f4b90027.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-7d070a58cfb70fe0.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_std_workspace_core-10ec18f1dfe36e70.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-e0e69d50f48d4667.rlib" "C:\\Users\\HiWin10\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-45eb0e961cc324b2.rlib" "advapi32.lib" "ws2_32.lib" …