Finally tried it by Delphi2005. I experienced some new features of the IDE two days ago. It was pretty good, but the speed was a little slow. The key is that my laboratory machine was not good either, it was only 256M, and the dormitory was better than 512M. It is much smoother to use, but the startup speed is still not as fast as VS2005. Speaking of stability, it is much better than D8, but I still heard people say that there are many bugs. I haven't found any serious bugs yet. Maybe it's not used in depth enough, but in terms of stability, it can still be used. People have accepted that although there is no good stability as D7, I think it will reach at least about 90% of the stability of D7. After all, it doesn't take long for Borland to develop compilers using .net.
I won’t mention the new features of Delphi2005, it’s everywhere on the Internet. These new features such as: Refactoring is quite good.
But: I really don’t understand. Together is a borland’s own thing, but it insists on not supporting Delphi. Even if it is supported, it is still integrated into delphi2005, and many functions have been removed. The second point is that the UML diagram can directly generate code. I used the UML diagram to directly generate the diagram, but I didn't get it from the diagram to the code. However, I did not use ECO, I don't know if this is the reason, but Delphi2005 Didn’t you say that you can do it without ECO? I really don’t understand what’s going on. The last point is that maybe the Borland compiler is of high level, but the code editor is far from Vs2005. In VS2005, if I type a letter, I will automatically display all the code prompts that match, including the key. All words are OK, and the speed is extremely fast, and it comes out instantly. In d2005, I have to press ctrl+space to get it out. And if I use the code prompt for the first time, I have to wait for the hard disk to rush around for a while before coming out. But to be fair, the prompts for using vs are directly based on the code. The d's has been analyzed in syntax. I suspect that the previous one must be precompiled in advance, which is more accurate, but if the machine is not good, it will be really a disaster. No, and if there is an error in the previous code, it is often impossible to prompt. Speaking of automatic indentation of code, borland is really incomparable. VS can automatically indent 2 spaces or other formats will also be automatically judged, but Delphi2005 still doesn't work, there is really no way. The last thing I don’t like is that I will automatically generate an annotation template by 3 // in VS, but Delphi does not provide the corresponding functions, so it is really not easy to comment in this way.
Back to the topic, Delphi for.net has made some syntax adjustments to adapt to some requirements of .net, but there are few related books and they are not able to write them well. Even if the compiler continues like this, no one knows how to write them. The delph program of net is also useless. I really don’t know when the good books of delphi.net will be released. Now that you have delphi2005, you can’t wait, just keep exploring yourself.
Today I will take a look at the help and learn namespace
namespace
Declare namespace
In delphi's project file, a namespace is implicitly declared, called the project default namespace. Assume that the project file header is defined as follows:
PRogram MyCompany.Programs.MyProgram; (the header of keywords such as library package)
Then the default namespace of the project is MyCompany.Programs
If a Unit header is defined as Unit ****; it is equivalent to writing it as Unit MyCompany.Programs.****
If a Unit header is defined as Unit ***.****.***; it is equivalent to declaring a namespace ***.****
Unit declared in the first way is called generic unit, which is always a subspace of the project default namespace
Namespace naming is case-insensitive. In other words, among the several segments of words divided by ., the last part is not counted as a name and is not compiled into assembly. For example, Unit AAA.BB.Unit3 is written, which only declares a namespace AAA.BB, Unit3. It can be regarded as a distinction between different file names, which cannot be seen by the outside world. Of course, within Delphi, they are still divided into two different parts. Using this feature, if a large Namespace needs to be divided into several files to write, you can make the entire part of these Units the same, just different in this section of the last one.
References to namespaces
Use the Uses statement. Suppose there is the following statement:
uses aaa.bbb.unit1,unit2;
It has been clearly specified for aaa.bbb.unit1. The Unit2 compiler will search for the namespace Unit2 in the following three orders
1 The current unit namespace (if any)
2 The project default namespace (if any)
3 Namespaces specified by compiler options
Although the last section of the Unit name cannot be seen and indistinguishable for external compilers, the last section is still indispensable in Delphi, so the last section needs to be included in the uses statement, for example, Class1 is defined in Unit1 AAA.BB.Unit1. In Unit AAA.BB.Unit2, you must refer to the full name of uses AAA.BB.Unit1 in the uses or if the default namespace of the project is AAA.BB.BB. You can also use Unit1 directly. No matter what, Unit1 is essential in uses.
In Delphi's help, it says:
Multiple units can be grouped together into one namespace using an extension of the in clause in the project source file. The file name string can list multiple unit source files in a semicolon-delimited list.
uses MyProgram.MyNamespace in 'filepath/unit1.pas;otherpath/unit2.pas';
In this example, the namespace MyProgram.MyNamespace logically contains all the interface symbols from unit1 and unit2. Symbol names in a namespace must be unique, across all units in the namespace. In the example above, if unit1 and unit2 both define a global interface symbol named mySymbol, the compiler will report an error in the uses clause.
But no matter how I experiment, I pay attention to compilation errors, and it cannot be implemented.
So far I haven't found a way to reference the dll generated by delphi. Because when I add a dll compiled by delphi for .net in the new project of delphi project, and then compile, I will say a fatal error, I can't import anything, please use packages, etc. However, there is no problem with adding dlls in VS.net, and the program can run normally.
So far, I have only found a temporary solution, which is to not generate library and replace it with package, so that the final target file is also a dll, and I can also call it normally in VS.