山
山东好汉
Unregistered / Unconfirmed
GUEST, unregistred user!
http://delphi.weblogs.com/stories/storyReader$373#WhatsNewInDelphiCompiler
Delphi for .NET
Ray Konopka - Creating Custom Components for the Microsoft .NET Framework
Danny Thorpe - Using Delphi for Microsoft .NET Framework Development
Danny Thorpe - What's New in the Delphi Compiler: .NET and Win32
Eddie Churchill - Overview of VCL for the Microsoft .NET Framework
Meet the .NET Team
Creating Custom Components for the Microsoft .NET Framework
On Sunday morning Ray Konopka presented Creating Custom Components for the Microsoft .NET Framework. Ray started his class by saying, "It's 1995 all over again." We have a new framework to learn and extend with features that are wowing folks using Microsoft development tools, and it looks a whole lot like Delphi.
Ray has been busy developing controls for the .NET framework using both C# and Delphi for .NET and while he finds the framework technically impressive, it isn't always easy to find the information needed to make your components work well. The System.Component.Events property, for example, is critical for designers of components with a large number of events, but is very poorlydo
cumented. So Ray focused on the process of creating components and some gotchas that he's encountered along the way.
Users of most .NET languages have at least three visual frameworks to deal with -- WinForms, ASP.NET, and the new Microsoft Avalon, which appears to be a future successor to WinForms. Delphi for .NET developers have an additional option: the VCL for .NET. While an argument can be made that choice is a good thing, the many frameworks available introduce some questions and confusion. For example, will WinForms be deprecated when Avalon is ready for prime time? And for Delphi developers used to the conventions of the VCL, event handling in .NET has some important differences which will be confusing.
Events in .NET
Since most of the audience for this tutorial were Delphi developers, Ray spent a lot of time discussing the .NET framework's event model. One of the most important features of .NET events is built-in support for multicasting -- having a list of event handling methods called in sequence instead of limiting the component user to a single method. Developers familiar with the observer pattern will appreciate this feature. The really good news for Delphi for .NET users porting existing code from Win32 is that your existing event handling code will probably work with no changes at all -- except that you have the option of adding multiple event handling methods for a single event.
Multiscast events in .NET are handled within the control generating them via a Delegate, which is simply a list of method pointers.
However, there is a convention in .NET which is going to confuse developers with VCL experience. In the VCL, event names are usually prefixed with "On" (e.g., "OnClick"). It's also common to have a dispatch method -- a method of a class used to fire the event. When this method is public, it's generally named the same as the event name, but without the "On." For example, the Click method might fire the OnClick event. When the method is protected, it's generally named with a "Do" prefix, e.g., "DoClick." Developers who subclass the component can override the methods to get notification when the parent class fires the event instead of actually wiring up an event handling method.
.NET reverses this convention. In .NET, the dispatch method would be called OnClick and the event itself called Click. So when writing WinForms components using Delphi for .NET you would override OnClick instead of Click when your subclass needs todo
something to implement this property. That's confusing enough, but what makes it worse is that the VCL for .NET method and event names cannot change -- otherwise porting existing VCL for Win32 code would be very difficult. So VCL for Win32 and .NET FCL components will use opposite conventions. That's even more confusing. Ray said, "Every day I stumble on this."
But wait, it gets worse: There is a lot of literature -- including books from Microsoft Press -- which gets this convention wrong! (I guess they were used to using Delphi!) You will see statements like, "take a look at the OnPaint handler...." But OnPaint, in the FCL, isn't an event. The event is Paint. OnPaint is the dispatch method.
The icing on the cake is that developers who override OnPaint when subclassing a control instead of adding a handler to the Paint delegate list often forget to call inherited, which means the real event will never fire at all!
Another terminology difference between .NET conventions and what we're used to with the Delphi VCL is the word "handler." In Delphi's VCL we think of a "handler" as a method which responds to a component event. In .NET a "handler" is the method signature of the method used to respond to the event. So the "TNotifyEvent" type is fairly similar to the "EventHandler" class in .NET, and when writing a new event type for consumption by other .NET languages you should follow the same convention.
Events pass a sender and a single object which contains all other values passed as a part of the event notification instead of a (potentially) long list of arguments. However, the regular Delphi event syntax is supported in Delphi for .NET, and the compiler will generate code to make this look like a standard .NET event to non-Delphi users of your component.
When writing .NET controls which you intend to make available to C# developers, it's a good idea to use lower-case names for the arguments in the event "handler" type. So you might write:
MyEventHandler = procedure(sender: System.Object, e.ValueChangingEventArgs) of object;
Note that sender and e are lower-case. This is because C# is case-sensitive, and you will confuse C# developers if you make the arguments upper-case, because you're violating C# convention. Since Delphi isn't case-sensitive, this difference shouldn't bother Delphi developers very much.
Some Significant Differences Between the VCL and the .NET UI Controls
There is no concept of Ownership, since the garbage collectordo
es lifetime management.
There is no Notification concept since there is no ownership. Instead you add an event handing method to the referenced object's Disposed event.
There are no control messages (CM_SOMETHING). Instead there is a separate event which is called when a given property changes. So a component with an Enabled property will have a public EnabledChanged event. And note that if the property is data-bound the "Changed" event must be present and must follow this naming convention, or data binding won't work correctly.
Tag is an Object, not an integer. Fontdo
esn't have a Color property -- instead controls with text typically have a "ForeColor" property. This means that if you want different text on your component to have different colors you need to introduce separate properties for each, separate from the font properties.
There is no "ParentFont," ParentColor," etc. properties. Instead, there are "ambient properties" which take their values from the component on which they are contained, unless specifically changed.
Many things that Delphi developers are used todo
with directives or code when writing components are replaced with attributes. For example, there are attributes for OI categories, whether or not a property appears in the OI at all (since reflection means there is no distinction between public and published in .NET), default values, etc.
Gotchas
The FCL equivalent of TControl.ControlStyle in the VCL is the GetStyle/SetStyle method pair. One of the attributes you can set is ControlStyles.ResizeRedraw. This determines whether or not the control is repainted when it is resized in code. The value that most developers will want, true, is not the default! So nearly every .NET visual control written has SetStyle( ControlStyles.ResizeRedraw, true) in its constructor.
GDI+ code is very different from GDI code in Win32. So different, in fact, that it's much too big of a topic to get into here. If youdo
a lot of direct calls to the Windows API and expect todo
this in .NET as well, start reading about GDI+ and the encapsulation of it in the FCL as soon as possible.
There are important gotchas with data binding;
see below for details.
Building "Data-Aware" controls
Any property on a .NET control can be data bound;
just ass the Bindable(true) attribute.
However, there are some things you need to know:
For data binding to work correctly, you must define an event that is raised when the property value changes.
The event must be named in a certain way: <property_name>Changed. For example, the Value property must have a ValueChanged event.
If youdo
n't follow this convention you may find the value reverting when youdo
n't expect it to.
Using Delphi for Microsoft .NET Framework Development
Disclaimer: These are my notes, not official statements from Borland. All quotes are as accurate as possible, but I was typing really quickly, so there are probably errors. Especially in the sections not in quotes it is probable that I have made errors transcribing what Danny said.
This was a preconference tutorial, and it was packed. If you're ever at BorCon, and you should be,do
not miss a chance to hear Danny Thorpe speak. His sessions always have an extremely high information density. The following long but hurried notes convey a small fraction of what Danny presented.
Quotes
"You're going to hear me say this a lot: 'Very similar to Delphi.'" Anders H: "Good ideas justdo
n't go away."
"If you ever run into a codegen bug in the JITter then
you have a JITterbug."
"Surprisingly compatible [with Delphi for Win32] -- even to me, and I wrote it."
"If you were here last year you might remember a 'things we weren't sure we'd be able todo
' slide. Every item on it is nowdo
ne! Typeless var params work, and they are type safe -- in Delphi for .NET. You should have seen the look on Anders H.'s face when I told him that!"
"We must have went through four or five different implementations before we settled on [the Variants implementation] we have now. But what we have now works. Really well. It's scary.... As bizarre and painful as Variant has been, I'm particularly proud of this one.... No, there's not a chance in hell that this code runs faster than Win32. But it's not how well the bear dances but that the bear dances at all. And this bear, my friends, can waltz."
"Every time Ido
an RTL update someone comes up to me and says, 'Hey, Randomdo
esn't produce the same stream of numbers it did before.' That's right;
it's random."
"Just as with VCL for Win32, one of the best places to see how to use the new syntax is to look at the code we wrote. And unlike .NET, we actually ship the source code."
"The first question that always comes up with [nested types] thing is 'What if I inherit from my container?' The sick part is that it might just work. It's still an open issue. It will probably carry a compiler warning like 'This is illegal in seven states.'"
"The Delphi compiler was built by an astrophysicist. He got into compilers because the tools for analyzing his stellar data were not good enough. Wonderful man to work with."
"While it is valid syntax to declare operators on class types, it seems significant that there is not one class in the entire .NET framework that implements operators. Coincidence? Highly unlikely. Stick with records until we find out why. The only way that that could happen within the Microsoft developer group is if there was an edict comingdo
wn from above saying, 'Do notdo
this under penalty of death,' because nothing else
in .NET is that consistent."
"A couple weeks ago there was a newsgroup thread on what you cando
with ilasm that you cannotdo
in C#. Ah ha! I like these conversations"
Delphi for .NET Features Unavailable in C#
Significant items:
Can link assemblies into EXE without having source code for the assemblies (using Delphi package syntax).
Functions in a managed Delphi for .NET code assembly can be called directly by unmanaged Win32 x86 code with no COM interop or .NET awareness.
Stored symbol information for faster compile time
Virtual constructors
Named constructors
Virtual calls from class methods
Resourcestrings
Delphi for .NET includes all CLS features, but includes features not included in CLS, such as virtual constructors. So you can use virtual constructors in your Delphi code, but clients using your assemblies from C# have no concept of virtual constructors, so they'll look like normal .NET constructors.
Calling assembly exports from Win32 code with no COM interop: One of the things that IL cando
which C# cannot is to produce unmanaged exports. On the .NET side you have to declare that your code is marked for unsafe, because the compiler has to build a table with platform-specific pointers to the methods in an undocumented section of the PE file. Your assembly is marked as specific for Win32 (obviously, since the exports are not useful to anything but Win32).
When Delphi for .NET sees a package, it imports the symbols from metadata and then
streams them to disk in native Delphi format. The compiler can then
load these about 100 times faster than importing from metadata. Delphi package syntax will allow you to link assemblies into your EXE without having the source code. In C# you have to have the source code todo
this.
Delphi for .NET will support class virtual methods, but calling them from C# is a bit unusual, since C#do
esn't support that. For maximum C# support, use class static methods instead. However, class static methods can't call class virtual methods.
Performance
Use of NGEN has a performance penalty right now since there are some things that the compiler can't resolve on the first path. The Whidbey release will fix this, but there will still probably be a performance penalty due to lack of profile-guided reoptimization, which is expected to be in future versions of .NET.
.NET is implemented as a bytecode system which learned from mistakes Java made along the way. .NET CIL opcodes generally have no type associated with them, unlike Java. This makes the instruction table very compact. What the ADD opcode means depends upon what is on the stack (integer, float). The JITter figures out what assembly code to used based both on what is on the stack and the opcode. IL is easier to compile than interpret.
JITted code is never cached to disk. The JITter is fast enough that itdo
esn't make a big difference. JITterdo
es things at runtime which are hard todo
at compile time with Delphi, such as function call inlining.
JITter will optimize compiled code for your CPU architecture.do
esn't support MMX yet, but it will next year. Delphi for .NET code has run on 64 bit architecture (and exposed many bugs in the JITter when they first tried it!). Choose types carefully -- CLS integer is always the same size, but NativeInt will change size depending upon hardware. Can't cast a pointer to an integer because pointers for your current platform might not be 32 bits.
Microsoft is working on profile-guided optimization. The teamdo
ing this uses IL as the input language, so the stuff theydo
will work with any .NET language.
Performance of GDI+ " borderline sucks" because it isn't implemented in hardware yet.
Format is a shim around the .NET formatter, which uses a different format syntax. So the format will be translated to .NET format and handed off. If you'redo
ing something performance-intensive with Format you should look at using the .NET formatter directly.
String index is by character, not by byte, just like WideString in Win32. Strings are immutable in .NET, so if you'redo
ing lots of string manipulations you should look at StringBuilder for performance reasons. String modifications really need to be reviewed in performance-critical areas, especially concatenation.
In general files on disk in .NET are larger than for Win32 because there is more symbol information stored. But the working set will be smaller because only code in use is JITted.
Delphi for .NET supports sealed classes. Microsoft has sealed a lot of classes in the .NET framework, and they're getting a lot more grief about it than Borland ever got for private members, so they're looking into opening some of those up. However, sealed classes provide some optimization opportunities for the JITter. Same thing for final methods.
Operator overloading support made the compiler faster because they were able to remove all knowledge of Variants from the compiler.
Security Restrictions
Code running in browsers has reduced privileges (sandbox). If you run an executable that is on a network share in .NET 1.1 it runs at a reduced security level (can'tdo
as much), just as if it was running in a browser.do
n't be surprised if there is more of this in the future.
Compatibility with Other .NET Languages
For the most part there's little to note about this since Delphi for .NETdo
es what .NET languages are required todo
. When you use some of the non-CLS features that Delphi for .NET provides, however, you can't be sure that other languages will understand them. When Delphi for .NET implements features outside of CLS itdo
es so in a way which is compatible with C#'s non-CLS features when possible.
Operator overloading: You can define operators on reference and value types. Delphi for .NET, for example, implements Variants using operator overloading and class helpers. Implicit cast operators are always used in preference to explicit cast operators since explicit casts are presumed to carry the risk of information loss. So if you have an implicit and explicit operator overload with the same signature then
the explicit operator will probably (definitely?) never be called. Operator overloading is not CLS compliant and is not specified in any standard;
it's a convention. Delphi's internal implementation follows C#'s.
Delphi currently will consume anything it recognizes in an imported assembly, even if it's not CLS. They may have to pull back on this a little, but for the time being it seems to work. CLS is more restrictive than CIL.
Custom attributes are supported, but probably not in Win32. Won't be implementing garbage collection in Win32, either.
Compatibility with Delphi for Win32
You can't convert an object reference to an integer (e.g., with TList) because you can't convert it back -- due to garbage collection and managed code you can'tdo
these tricks with pointers and funny casts. Also there's no guarantee that integer and pointer are the same type on a given platform.
There is no guarantee that destructors or finalizations will ever execute. But calling TObject.Free runs the "destructor," as long as its name is Destroy and it overrides the inherited Destroy.
Extendeddo
wngrades todo
uble, because itdo
esn't exist outside of Intel hardware. Range of Currency "has been trimmed a bit."
Namespace prefixes mean youdo
n't need an IFDEF in your uses clause to move your code from Win32 to .NET and back.
What won't work in .NET:
absolute directive
Real48 six byte floats
File of <type> (but TextFile is supported). File of type won't work because it would produce different memory dumps on different platforms, and memory in .NET can shift.
GetMem, FreeMem, ReallocMem (use dynamic arrays or New() and Dispose() instead)
ExitProcs
Old object syntax (type TFoo = object)
TVarData and Variant internals. (But variants themselves are implemented.)
AfterConstructor and BeforeDestructor -- no place for them in CLR. But no big deal since you can make virtual calls from a constructor.
@, Addr() are available -- they produce a delegate. TMethod is also a delegate. PChars are implemented if you declare that the routine using them is unsafe. This marks the class as unsafe and may disqualify the class from use in certain environments.
Implementation of Currency is as a record with operator overloading and support for certain .NET interfaces such as IConvertible. It's a pretty big type, which gives you an idea of just how much is behind the scenes with Delphi PODs. This implementation made it possible to remove all knowledge of the Currency type from the compiler.
Value types (records) must be declared packed if you want to support PInvoke marshalling to Win32, because it tells the runtime not to rearrange the internals.
Variants: Implemented with class helpers. Can apply all the methods we expect to see for Variants on any object. Variants have no implementation in CLR -- it's all compiler magic. Delphi Variants will show up in C# as System.Object. OLEVariant is also supported -- that was extremely painful [to implement].
For better or worse, Delphi cracker classes are supported, even though .NET has no such concept. Delphi protected methods are emitted as family or assembly visibility in CLR. The compiler will prevent you from accessing private and protected members in other units outside of the cracker class hack. This means that cracker classes will work if you're in the same assembly. Since .NETdo
esn't support cracker classes, the compiler recognizes what you'redo
ing (weird cast followed by ado
t and a protected member), ignores the cast, and allows access to the protected member. "This is solely to support that hack." Cracker classes won't work across assembly boundaries, though -- you'll get a runtime, not compile time, error. New strict private and strict protected visibilities also disallow "unit friendship."
Events and Properties
Must use add and remove methods for events instead of read and write if you want multicast support. Delphi read/write events also support add/remove for compatibility with CLR, but the result is still single assignment. Use add/remove assessors for multicast. You cannot use := assignment on CLR event properties, you must use add/remove, since they're multicast anddo
n't have getters/setters. Every time you add an event to a multicast list the runtime copies the list to avoid threading errors. There's a lot of stuff in the framework for single-cast events, but support was pulled from the JITter just before 1.0 shipped.
All property assessors must be as methods, not fields, because of remoting. Delphi syntax for properties implemented as fields is still allowed, but getter/setter methods will be added by the compiler.
Event sample code:
type
TClickEvent = procedure of object;
TFoo = class
private
FOnClick: TClickEvent;
public
property OnClick: TClickEvent add FOnClick remove FOnClick;
end;
Include(F.OnClick, MyObject.HandleClick);
Miscellaneous Tips and Information
Assembly filenames often look like namespaces, but the filenamedo
esn't necessarily reflect the namespace(s) that the assembly contributes to. For example, System.Windows.Forms.dll contributes to several namespaces other than System.Windows.Forms.
Delphi for .NET is much more than a port. Much harder than Kylix since Kylix was for x86, and Delphi for .NET is not. First new codegen since Delphi 2.0. New linker. Syntax expansion comparable to Delphi 1 vs. BP 7.
dbExpress drivers for .NET plug into ADO.NET. Borland providers plug in to cover servers that Microsoft won't (e.g., InterBase) cover or has no incentive todo
well (e.g., Oracle).
We're considering including auto boxing (converting, for example, 1 to an object without an explicit cast) under a compiler directive, but feel that it isn't appropriate for a type safe language. What if you intend to write i and instead put 1 in an assignment to object -- it will compile.
Class helper rule #1: Class helpers are for binding the language and class library foundations to new platforms while preserving name expectations for existing portable code. Class helpers are not intended for application or component development. "Don't you dare use this stuff! Ido
not recommend this for applications, and Ido
not recommend this for component writers."
"Memory leaks are still possible in a garbage collected system. How? You leave a global variable lying around. Everything it refers to, and everything they refer to, stay around. That's a bad memory leak."
What's New in the Delphi Compiler: .NET and Win32
Danny Thorpe said that Delphi will be the most portable, most platform-independent language supported on .NET. Furthermore, it will offer everything that .NET offers -- if it fails todo
that then
Delphi developers would be boxed out of that feature area.
Quotes
"CLR and Delphido
vetail like they were made for each other. Because they were."
"No iconographs in identifiers. This means no Chinese characters. Tangentially it also means no Klingon. There is a Klingon page in Unicode. It's right up there next to hieroglyphics. Seriously."
"I have this big division between the systems group at Microsoft [gestures left] and the applications group at Microsoft [gestures right]. [Gestures left again] I like these guys."
Much of this course covered the same ground as Using Delphi for Microsoft .NET Framework Development, above, so I won't repeat that information here.
If there's one thing that CLS imposes on a language implementer, it's that you are a single-implementation-inheritance language.
Modules: A module is an assembly which contains code but cannot be loaded by the CLR. You can, however link against them. It's like a DCU in Win32. Modules are not fully implemented in the framework at this point, but the Delphi team is watching this feature with interest.
Delphi for .NET is to Delphi 7 for Win32 as Delphi 1 was to Borland Pascal 7. We are at the cusp of a new Delphi.
Records with methods will be implemented in Win32. Operator overloading will be implemented in Win32 with restrictions -- you will not be able todo
operator overloading on a record which contains fields whose memory is maintained by the compiler. Operator overloading on both .NET and Win32 will not allow you to define new operators -- this would have been a significant change to the parser, which the team did not modify at all. Changing the parser to support definition of new operators would have significantly slowed itdo
wn.
Overview of VCL for the Microsoft .NET Framework
Eddie Churchill presented this course late Monday afternoon.
Quotes
"At the end of the day when you compile all of your objects it just magically works, OK?"
Delphi VCL. "Is anybody... from marketing here? OK." In Delphi 1 VCL was everything. In D2 VCL was broken up into RTL, VCL, DB, etc. In D6-7 VCL became part of CLX framework. In Delphi 8, VCL is back with a vengence! At no point are you going to use "CLX." "I actually in a fit of insanity one day sent one of the engineers to port VisualCLX to .NET. She came back in an hour and asked, 'Are you absolutely sure?' I asked her, 'Who the heck told you todo
that?'"
"DB.pas got changed a little bit just because it had some really bad code in it."
[On bringing the language changes to Win32] "It's really not going to feel that different;
it's just going to have a lot more features."
"Talk to Danny. He's the guy who actually comments out things inside the compiler."
"That won't be in the first round. We had to leave something so we could charge you for it later."
System Unit
Int, Frac, Exp no longer magic. The language has been rich enough to support this for some time, but they finally got around to taking these out of compiler magic.
Trunc, Round are still magic but value types can override just like an operator.
There is no extended type in .NET, so Extended maps to typedo
uble. But for compatibility with old streaming system it's still streamed as 12 bytes, in and out. Naturally when streaming out of VCL for .NET four of those bytes are zero.
All new VCL classes use strict private and strict protected. None of the old abuse of the rules. Would like to go back and fix the old code butdo
ing it wrong would cause total chaos.
"We have a nice new System unit, it has very little stuff in it, it's nice and skinny. The only thing you need to write Delphi code is System. Youdo
n't need the VCL. No Variants, none of those weird types." Borland.Delphi assembly contains only System unit.
Packages are going to contribute to a much simpler namespace scheme. Only two namespaces are planned: Borland.Delphi and Borland.VCL. DB stuff is in Borland.VCL, since non-ADO.NET datasets can only be used with VCL components. Result is a clean separtion between the Delphi language and the VCL framework. Plus it makes things easy to find. "If it's not System, it's probably in the other place."
DB is a great use for Variants. In fact, .NET actually has variants, but all they're used for is DB stuff, and they're only containers. You can'tdo
perform operations on them. But Delphi has to support Win32 code, so implementing them couldn't simply use this.
Complex, Convert, FmtBCD, and SQLTimeStamp have been converted into value types. SQLTimeStamp was created by accident because the person who created it didn't think that TDateTime worked in a certain way, and now we're stuck with it. FmtBCD shouldn't exist either since there's a type of Variant called decimal. But all these types are supported and usable without bringing in Variants.
Classes Unit
TPersistent is an alias to System.MarshallByRefObject for no real reason other than to distinguish it from, say, TObject and TComponent.
TypInfo Unit
Since Delphi types are .NET types, TypInfo completely rewritten with System.Reflection. Beware when using this in conjunction with obfuscators! Internal data structures have been marked as deprecated, but easy functions like GetOrdProp work more or less as they always have.
WinForm connector/importer
Similar to how you use ActiveX in Delphi 7, this tool allows you to import WinForm controls into your VCL form application. But it's much thinner then
the ActiveX container since WinForm controls use the same type system. More of a property mapper.
Database Components
TCustomDataset and the rest is still there. BDE (for desktop DBs), dbExpress, InterBase Express, and ClientDataset have been ported. "We didn't port all of CDS. There are some things inside of CDS which were very difficult to port. So anything that was difficult we didn't." Client tier only has been ported -- server components not ported yet. DataSnap servers will need to be compiled in dcc32 for the time being.
There is an ADO.NET connector/importer. This component allows you to connect an ADO.NET data table to your existing VCL/DB application. It exposes the data table via a custom TDataset. Connect a TDataSource and away you go.
ADOExpress not ported. ADO and ADO.NET are completely different. Probably wouldn't be impossible todo
, but notdo
ne yet.
Bringing These Changes to Win32
The Delphi team wants to make dcc32 know about value types, strict private and protected, pull the magic functions out of the compiler and use the exact same RTL, etc., packages that dccil uses. Hoping todo
this within two quarters. Goal is to use the exact same RTL source with Win32 and .NET.
There's no reason why the team can't bring Decimal to Win32.
Eeek! Things to watch out for.
String is now wide.
Pointer -- There is a Pointer type, but in safe code Pointer is a reference to an object. You can'tdo
pointer math on it.
Sizes of types and order of fields is different. You cannot depend on sizes or the order of fields, period.
Tag is a variant. This is because most of the people who used Tag were cramming objects into it. Works like you'd expect, but youdo
have to use the Variant unit.
PChar is supported in unsafe code. Delphido
esn't use it in the VCL at all.
Use TBytes instead of GetMem, FreeMem, etc.
File of <type> gone. Instead use .NET XML streaming.
Old TP objects gone. Use new value types with methods and properties instead.
Language is now totally isolated from the VCL framework so that youdo
n't have to pull in User32 if youdo
n't want to. VCL is not dead, though. Far from it.
Existing code should just work. Many units haven't changed at all, and the worst mistakes they made in bringing VCL to .NET was to try and change things too much, because it broke the VCL in other places.
There is now a list of things that are needed for full support of Compact Framework, but Microsoft didn't get the SDK fast enough to get it into the first release. But you can pretty much expect it for the next release.
Meet the .NET Team
Simon Thornhill began the presentation by excluding a lot of what, I suspect based on experience at previous BorCons, people were likely to say. He requested no soap boxing, no marketing questions, no specific issues. Well, you were allowed to ask about specific issues if you cornered one of the team personally, but this was a packed session, so there was little room for questions about things not of interest to everyone. Simon then
announced that there will be updates to Win32.
The situation with Kylix is that they are continuing to sell and support the version which is out in the field. They are continually evaluating the situation. At present there is no plan for an update to Kylix in 2004. That isn't to say there won't be another release, but it's not on the horizon at present.
Members of the team were asked to share the first Borland product they worked on and their most embarrassing moment. Here are the highlights:
Chuck J. "The first product I had any of my codeship on was Turbo Prolog."
Danny Thorpe "I was the one person who worked on Turbo Pascal for Windows 1.5."
Ramesh T. "My embarrassing moments are basically when someone comes and asks me to fix BDE bugs."
John Keegan "I've been with Borland since 1962. My first product was Borland Turbo COBOL."
Allen Bauer "My most embarrassing moment was moving BGI to protected mode."
Eddie Churchill "Ido
stuff. Normally Danny and I and Chuck go out to lunch together and I drive. We were instructed that we're not allowed to drive together anymore. Variants would be embarrassing. Variants were bad."
Chuck J.: The original design of the VCL was designed for portability, because 32 bit code was in mind from the outset. It was difficult to deliver on Windows to begin
with, so effort to port to other platforms was no surprise.
Simon Thornhill: "The great thing about business unit names is that we can change them at random. Tomorrow we could be the COBOL business unit. The '.NET Business Unit' also upset our legal department."
Namable, recordable macros: "It'sdo
cumented in the online Help that theydo
n't work right."
"We want to have CF support in the next year. Microsoft is anxious to work with us on this. This release of Delphi for .NETdo
esn't have a button in the IDE which says 'deploy to CF' but you should be able to copy the right files in the right place and it should work." Expect an article on this. You can't build a desktop app and take it to CF, but you can build a CF app and take it to desktop.
Eddie Churchill ".NET was actually built for Delphi. .NET has features that Microsoftdo
esn't even use, like sets and things of that nature. They have our string, for Pete's sake, because their string was broken." John Kaster: "I was at PDC last week and mentioned that Anders has been working for Borland for all this time and wants to know where his back pay is."
Chuck J. "Some of the justification for things we didn'tdo
... When .NET did something really well we didn't feel it was worth it to duplicate something that .NET already did."
Corbin Dunn: "Everything you see in the [Galileo] IDE is componentized, so we will probably be delivering [these new IDE features] as components."
Delphi for .NET
Ray Konopka - Creating Custom Components for the Microsoft .NET Framework
Danny Thorpe - Using Delphi for Microsoft .NET Framework Development
Danny Thorpe - What's New in the Delphi Compiler: .NET and Win32
Eddie Churchill - Overview of VCL for the Microsoft .NET Framework
Meet the .NET Team
Creating Custom Components for the Microsoft .NET Framework
On Sunday morning Ray Konopka presented Creating Custom Components for the Microsoft .NET Framework. Ray started his class by saying, "It's 1995 all over again." We have a new framework to learn and extend with features that are wowing folks using Microsoft development tools, and it looks a whole lot like Delphi.
Ray has been busy developing controls for the .NET framework using both C# and Delphi for .NET and while he finds the framework technically impressive, it isn't always easy to find the information needed to make your components work well. The System.Component.Events property, for example, is critical for designers of components with a large number of events, but is very poorlydo
cumented. So Ray focused on the process of creating components and some gotchas that he's encountered along the way.
Users of most .NET languages have at least three visual frameworks to deal with -- WinForms, ASP.NET, and the new Microsoft Avalon, which appears to be a future successor to WinForms. Delphi for .NET developers have an additional option: the VCL for .NET. While an argument can be made that choice is a good thing, the many frameworks available introduce some questions and confusion. For example, will WinForms be deprecated when Avalon is ready for prime time? And for Delphi developers used to the conventions of the VCL, event handling in .NET has some important differences which will be confusing.
Events in .NET
Since most of the audience for this tutorial were Delphi developers, Ray spent a lot of time discussing the .NET framework's event model. One of the most important features of .NET events is built-in support for multicasting -- having a list of event handling methods called in sequence instead of limiting the component user to a single method. Developers familiar with the observer pattern will appreciate this feature. The really good news for Delphi for .NET users porting existing code from Win32 is that your existing event handling code will probably work with no changes at all -- except that you have the option of adding multiple event handling methods for a single event.
Multiscast events in .NET are handled within the control generating them via a Delegate, which is simply a list of method pointers.
However, there is a convention in .NET which is going to confuse developers with VCL experience. In the VCL, event names are usually prefixed with "On" (e.g., "OnClick"). It's also common to have a dispatch method -- a method of a class used to fire the event. When this method is public, it's generally named the same as the event name, but without the "On." For example, the Click method might fire the OnClick event. When the method is protected, it's generally named with a "Do" prefix, e.g., "DoClick." Developers who subclass the component can override the methods to get notification when the parent class fires the event instead of actually wiring up an event handling method.
.NET reverses this convention. In .NET, the dispatch method would be called OnClick and the event itself called Click. So when writing WinForms components using Delphi for .NET you would override OnClick instead of Click when your subclass needs todo
something to implement this property. That's confusing enough, but what makes it worse is that the VCL for .NET method and event names cannot change -- otherwise porting existing VCL for Win32 code would be very difficult. So VCL for Win32 and .NET FCL components will use opposite conventions. That's even more confusing. Ray said, "Every day I stumble on this."
But wait, it gets worse: There is a lot of literature -- including books from Microsoft Press -- which gets this convention wrong! (I guess they were used to using Delphi!) You will see statements like, "take a look at the OnPaint handler...." But OnPaint, in the FCL, isn't an event. The event is Paint. OnPaint is the dispatch method.
The icing on the cake is that developers who override OnPaint when subclassing a control instead of adding a handler to the Paint delegate list often forget to call inherited, which means the real event will never fire at all!
Another terminology difference between .NET conventions and what we're used to with the Delphi VCL is the word "handler." In Delphi's VCL we think of a "handler" as a method which responds to a component event. In .NET a "handler" is the method signature of the method used to respond to the event. So the "TNotifyEvent" type is fairly similar to the "EventHandler" class in .NET, and when writing a new event type for consumption by other .NET languages you should follow the same convention.
Events pass a sender and a single object which contains all other values passed as a part of the event notification instead of a (potentially) long list of arguments. However, the regular Delphi event syntax is supported in Delphi for .NET, and the compiler will generate code to make this look like a standard .NET event to non-Delphi users of your component.
When writing .NET controls which you intend to make available to C# developers, it's a good idea to use lower-case names for the arguments in the event "handler" type. So you might write:
MyEventHandler = procedure(sender: System.Object, e.ValueChangingEventArgs) of object;
Note that sender and e are lower-case. This is because C# is case-sensitive, and you will confuse C# developers if you make the arguments upper-case, because you're violating C# convention. Since Delphi isn't case-sensitive, this difference shouldn't bother Delphi developers very much.
Some Significant Differences Between the VCL and the .NET UI Controls
There is no concept of Ownership, since the garbage collectordo
es lifetime management.
There is no Notification concept since there is no ownership. Instead you add an event handing method to the referenced object's Disposed event.
There are no control messages (CM_SOMETHING). Instead there is a separate event which is called when a given property changes. So a component with an Enabled property will have a public EnabledChanged event. And note that if the property is data-bound the "Changed" event must be present and must follow this naming convention, or data binding won't work correctly.
Tag is an Object, not an integer. Fontdo
esn't have a Color property -- instead controls with text typically have a "ForeColor" property. This means that if you want different text on your component to have different colors you need to introduce separate properties for each, separate from the font properties.
There is no "ParentFont," ParentColor," etc. properties. Instead, there are "ambient properties" which take their values from the component on which they are contained, unless specifically changed.
Many things that Delphi developers are used todo
with directives or code when writing components are replaced with attributes. For example, there are attributes for OI categories, whether or not a property appears in the OI at all (since reflection means there is no distinction between public and published in .NET), default values, etc.
Gotchas
The FCL equivalent of TControl.ControlStyle in the VCL is the GetStyle/SetStyle method pair. One of the attributes you can set is ControlStyles.ResizeRedraw. This determines whether or not the control is repainted when it is resized in code. The value that most developers will want, true, is not the default! So nearly every .NET visual control written has SetStyle( ControlStyles.ResizeRedraw, true) in its constructor.
GDI+ code is very different from GDI code in Win32. So different, in fact, that it's much too big of a topic to get into here. If youdo
a lot of direct calls to the Windows API and expect todo
this in .NET as well, start reading about GDI+ and the encapsulation of it in the FCL as soon as possible.
There are important gotchas with data binding;
see below for details.
Building "Data-Aware" controls
Any property on a .NET control can be data bound;
just ass the Bindable(true) attribute.
However, there are some things you need to know:
For data binding to work correctly, you must define an event that is raised when the property value changes.
The event must be named in a certain way: <property_name>Changed. For example, the Value property must have a ValueChanged event.
If youdo
n't follow this convention you may find the value reverting when youdo
n't expect it to.
Using Delphi for Microsoft .NET Framework Development
Disclaimer: These are my notes, not official statements from Borland. All quotes are as accurate as possible, but I was typing really quickly, so there are probably errors. Especially in the sections not in quotes it is probable that I have made errors transcribing what Danny said.
This was a preconference tutorial, and it was packed. If you're ever at BorCon, and you should be,do
not miss a chance to hear Danny Thorpe speak. His sessions always have an extremely high information density. The following long but hurried notes convey a small fraction of what Danny presented.
Quotes
"You're going to hear me say this a lot: 'Very similar to Delphi.'" Anders H: "Good ideas justdo
n't go away."
"If you ever run into a codegen bug in the JITter then
you have a JITterbug."
"Surprisingly compatible [with Delphi for Win32] -- even to me, and I wrote it."
"If you were here last year you might remember a 'things we weren't sure we'd be able todo
' slide. Every item on it is nowdo
ne! Typeless var params work, and they are type safe -- in Delphi for .NET. You should have seen the look on Anders H.'s face when I told him that!"
"We must have went through four or five different implementations before we settled on [the Variants implementation] we have now. But what we have now works. Really well. It's scary.... As bizarre and painful as Variant has been, I'm particularly proud of this one.... No, there's not a chance in hell that this code runs faster than Win32. But it's not how well the bear dances but that the bear dances at all. And this bear, my friends, can waltz."
"Every time Ido
an RTL update someone comes up to me and says, 'Hey, Randomdo
esn't produce the same stream of numbers it did before.' That's right;
it's random."
"Just as with VCL for Win32, one of the best places to see how to use the new syntax is to look at the code we wrote. And unlike .NET, we actually ship the source code."
"The first question that always comes up with [nested types] thing is 'What if I inherit from my container?' The sick part is that it might just work. It's still an open issue. It will probably carry a compiler warning like 'This is illegal in seven states.'"
"The Delphi compiler was built by an astrophysicist. He got into compilers because the tools for analyzing his stellar data were not good enough. Wonderful man to work with."
"While it is valid syntax to declare operators on class types, it seems significant that there is not one class in the entire .NET framework that implements operators. Coincidence? Highly unlikely. Stick with records until we find out why. The only way that that could happen within the Microsoft developer group is if there was an edict comingdo
wn from above saying, 'Do notdo
this under penalty of death,' because nothing else
in .NET is that consistent."
"A couple weeks ago there was a newsgroup thread on what you cando
with ilasm that you cannotdo
in C#. Ah ha! I like these conversations"
Delphi for .NET Features Unavailable in C#
Significant items:
Can link assemblies into EXE without having source code for the assemblies (using Delphi package syntax).
Functions in a managed Delphi for .NET code assembly can be called directly by unmanaged Win32 x86 code with no COM interop or .NET awareness.
Stored symbol information for faster compile time
Virtual constructors
Named constructors
Virtual calls from class methods
Resourcestrings
Delphi for .NET includes all CLS features, but includes features not included in CLS, such as virtual constructors. So you can use virtual constructors in your Delphi code, but clients using your assemblies from C# have no concept of virtual constructors, so they'll look like normal .NET constructors.
Calling assembly exports from Win32 code with no COM interop: One of the things that IL cando
which C# cannot is to produce unmanaged exports. On the .NET side you have to declare that your code is marked for unsafe, because the compiler has to build a table with platform-specific pointers to the methods in an undocumented section of the PE file. Your assembly is marked as specific for Win32 (obviously, since the exports are not useful to anything but Win32).
When Delphi for .NET sees a package, it imports the symbols from metadata and then
streams them to disk in native Delphi format. The compiler can then
load these about 100 times faster than importing from metadata. Delphi package syntax will allow you to link assemblies into your EXE without having the source code. In C# you have to have the source code todo
this.
Delphi for .NET will support class virtual methods, but calling them from C# is a bit unusual, since C#do
esn't support that. For maximum C# support, use class static methods instead. However, class static methods can't call class virtual methods.
Performance
Use of NGEN has a performance penalty right now since there are some things that the compiler can't resolve on the first path. The Whidbey release will fix this, but there will still probably be a performance penalty due to lack of profile-guided reoptimization, which is expected to be in future versions of .NET.
.NET is implemented as a bytecode system which learned from mistakes Java made along the way. .NET CIL opcodes generally have no type associated with them, unlike Java. This makes the instruction table very compact. What the ADD opcode means depends upon what is on the stack (integer, float). The JITter figures out what assembly code to used based both on what is on the stack and the opcode. IL is easier to compile than interpret.
JITted code is never cached to disk. The JITter is fast enough that itdo
esn't make a big difference. JITterdo
es things at runtime which are hard todo
at compile time with Delphi, such as function call inlining.
JITter will optimize compiled code for your CPU architecture.do
esn't support MMX yet, but it will next year. Delphi for .NET code has run on 64 bit architecture (and exposed many bugs in the JITter when they first tried it!). Choose types carefully -- CLS integer is always the same size, but NativeInt will change size depending upon hardware. Can't cast a pointer to an integer because pointers for your current platform might not be 32 bits.
Microsoft is working on profile-guided optimization. The teamdo
ing this uses IL as the input language, so the stuff theydo
will work with any .NET language.
Performance of GDI+ " borderline sucks" because it isn't implemented in hardware yet.
Format is a shim around the .NET formatter, which uses a different format syntax. So the format will be translated to .NET format and handed off. If you'redo
ing something performance-intensive with Format you should look at using the .NET formatter directly.
String index is by character, not by byte, just like WideString in Win32. Strings are immutable in .NET, so if you'redo
ing lots of string manipulations you should look at StringBuilder for performance reasons. String modifications really need to be reviewed in performance-critical areas, especially concatenation.
In general files on disk in .NET are larger than for Win32 because there is more symbol information stored. But the working set will be smaller because only code in use is JITted.
Delphi for .NET supports sealed classes. Microsoft has sealed a lot of classes in the .NET framework, and they're getting a lot more grief about it than Borland ever got for private members, so they're looking into opening some of those up. However, sealed classes provide some optimization opportunities for the JITter. Same thing for final methods.
Operator overloading support made the compiler faster because they were able to remove all knowledge of Variants from the compiler.
Security Restrictions
Code running in browsers has reduced privileges (sandbox). If you run an executable that is on a network share in .NET 1.1 it runs at a reduced security level (can'tdo
as much), just as if it was running in a browser.do
n't be surprised if there is more of this in the future.
Compatibility with Other .NET Languages
For the most part there's little to note about this since Delphi for .NETdo
es what .NET languages are required todo
. When you use some of the non-CLS features that Delphi for .NET provides, however, you can't be sure that other languages will understand them. When Delphi for .NET implements features outside of CLS itdo
es so in a way which is compatible with C#'s non-CLS features when possible.
Operator overloading: You can define operators on reference and value types. Delphi for .NET, for example, implements Variants using operator overloading and class helpers. Implicit cast operators are always used in preference to explicit cast operators since explicit casts are presumed to carry the risk of information loss. So if you have an implicit and explicit operator overload with the same signature then
the explicit operator will probably (definitely?) never be called. Operator overloading is not CLS compliant and is not specified in any standard;
it's a convention. Delphi's internal implementation follows C#'s.
Delphi currently will consume anything it recognizes in an imported assembly, even if it's not CLS. They may have to pull back on this a little, but for the time being it seems to work. CLS is more restrictive than CIL.
Custom attributes are supported, but probably not in Win32. Won't be implementing garbage collection in Win32, either.
Compatibility with Delphi for Win32
You can't convert an object reference to an integer (e.g., with TList) because you can't convert it back -- due to garbage collection and managed code you can'tdo
these tricks with pointers and funny casts. Also there's no guarantee that integer and pointer are the same type on a given platform.
There is no guarantee that destructors or finalizations will ever execute. But calling TObject.Free runs the "destructor," as long as its name is Destroy and it overrides the inherited Destroy.
Extendeddo
wngrades todo
uble, because itdo
esn't exist outside of Intel hardware. Range of Currency "has been trimmed a bit."
Namespace prefixes mean youdo
n't need an IFDEF in your uses clause to move your code from Win32 to .NET and back.
What won't work in .NET:
absolute directive
Real48 six byte floats
File of <type> (but TextFile is supported). File of type won't work because it would produce different memory dumps on different platforms, and memory in .NET can shift.
GetMem, FreeMem, ReallocMem (use dynamic arrays or New() and Dispose() instead)
ExitProcs
Old object syntax (type TFoo = object)
TVarData and Variant internals. (But variants themselves are implemented.)
AfterConstructor and BeforeDestructor -- no place for them in CLR. But no big deal since you can make virtual calls from a constructor.
@, Addr() are available -- they produce a delegate. TMethod is also a delegate. PChars are implemented if you declare that the routine using them is unsafe. This marks the class as unsafe and may disqualify the class from use in certain environments.
Implementation of Currency is as a record with operator overloading and support for certain .NET interfaces such as IConvertible. It's a pretty big type, which gives you an idea of just how much is behind the scenes with Delphi PODs. This implementation made it possible to remove all knowledge of the Currency type from the compiler.
Value types (records) must be declared packed if you want to support PInvoke marshalling to Win32, because it tells the runtime not to rearrange the internals.
Variants: Implemented with class helpers. Can apply all the methods we expect to see for Variants on any object. Variants have no implementation in CLR -- it's all compiler magic. Delphi Variants will show up in C# as System.Object. OLEVariant is also supported -- that was extremely painful [to implement].
For better or worse, Delphi cracker classes are supported, even though .NET has no such concept. Delphi protected methods are emitted as family or assembly visibility in CLR. The compiler will prevent you from accessing private and protected members in other units outside of the cracker class hack. This means that cracker classes will work if you're in the same assembly. Since .NETdo
esn't support cracker classes, the compiler recognizes what you'redo
ing (weird cast followed by ado
t and a protected member), ignores the cast, and allows access to the protected member. "This is solely to support that hack." Cracker classes won't work across assembly boundaries, though -- you'll get a runtime, not compile time, error. New strict private and strict protected visibilities also disallow "unit friendship."
Events and Properties
Must use add and remove methods for events instead of read and write if you want multicast support. Delphi read/write events also support add/remove for compatibility with CLR, but the result is still single assignment. Use add/remove assessors for multicast. You cannot use := assignment on CLR event properties, you must use add/remove, since they're multicast anddo
n't have getters/setters. Every time you add an event to a multicast list the runtime copies the list to avoid threading errors. There's a lot of stuff in the framework for single-cast events, but support was pulled from the JITter just before 1.0 shipped.
All property assessors must be as methods, not fields, because of remoting. Delphi syntax for properties implemented as fields is still allowed, but getter/setter methods will be added by the compiler.
Event sample code:
type
TClickEvent = procedure of object;
TFoo = class
private
FOnClick: TClickEvent;
public
property OnClick: TClickEvent add FOnClick remove FOnClick;
end;
Include(F.OnClick, MyObject.HandleClick);
Miscellaneous Tips and Information
Assembly filenames often look like namespaces, but the filenamedo
esn't necessarily reflect the namespace(s) that the assembly contributes to. For example, System.Windows.Forms.dll contributes to several namespaces other than System.Windows.Forms.
Delphi for .NET is much more than a port. Much harder than Kylix since Kylix was for x86, and Delphi for .NET is not. First new codegen since Delphi 2.0. New linker. Syntax expansion comparable to Delphi 1 vs. BP 7.
dbExpress drivers for .NET plug into ADO.NET. Borland providers plug in to cover servers that Microsoft won't (e.g., InterBase) cover or has no incentive todo
well (e.g., Oracle).
We're considering including auto boxing (converting, for example, 1 to an object without an explicit cast) under a compiler directive, but feel that it isn't appropriate for a type safe language. What if you intend to write i and instead put 1 in an assignment to object -- it will compile.
Class helper rule #1: Class helpers are for binding the language and class library foundations to new platforms while preserving name expectations for existing portable code. Class helpers are not intended for application or component development. "Don't you dare use this stuff! Ido
not recommend this for applications, and Ido
not recommend this for component writers."
"Memory leaks are still possible in a garbage collected system. How? You leave a global variable lying around. Everything it refers to, and everything they refer to, stay around. That's a bad memory leak."
What's New in the Delphi Compiler: .NET and Win32
Danny Thorpe said that Delphi will be the most portable, most platform-independent language supported on .NET. Furthermore, it will offer everything that .NET offers -- if it fails todo
that then
Delphi developers would be boxed out of that feature area.
Quotes
"CLR and Delphido
vetail like they were made for each other. Because they were."
"No iconographs in identifiers. This means no Chinese characters. Tangentially it also means no Klingon. There is a Klingon page in Unicode. It's right up there next to hieroglyphics. Seriously."
"I have this big division between the systems group at Microsoft [gestures left] and the applications group at Microsoft [gestures right]. [Gestures left again] I like these guys."
Much of this course covered the same ground as Using Delphi for Microsoft .NET Framework Development, above, so I won't repeat that information here.
If there's one thing that CLS imposes on a language implementer, it's that you are a single-implementation-inheritance language.
Modules: A module is an assembly which contains code but cannot be loaded by the CLR. You can, however link against them. It's like a DCU in Win32. Modules are not fully implemented in the framework at this point, but the Delphi team is watching this feature with interest.
Delphi for .NET is to Delphi 7 for Win32 as Delphi 1 was to Borland Pascal 7. We are at the cusp of a new Delphi.
Records with methods will be implemented in Win32. Operator overloading will be implemented in Win32 with restrictions -- you will not be able todo
operator overloading on a record which contains fields whose memory is maintained by the compiler. Operator overloading on both .NET and Win32 will not allow you to define new operators -- this would have been a significant change to the parser, which the team did not modify at all. Changing the parser to support definition of new operators would have significantly slowed itdo
wn.
Overview of VCL for the Microsoft .NET Framework
Eddie Churchill presented this course late Monday afternoon.
Quotes
"At the end of the day when you compile all of your objects it just magically works, OK?"
Delphi VCL. "Is anybody... from marketing here? OK." In Delphi 1 VCL was everything. In D2 VCL was broken up into RTL, VCL, DB, etc. In D6-7 VCL became part of CLX framework. In Delphi 8, VCL is back with a vengence! At no point are you going to use "CLX." "I actually in a fit of insanity one day sent one of the engineers to port VisualCLX to .NET. She came back in an hour and asked, 'Are you absolutely sure?' I asked her, 'Who the heck told you todo
that?'"
"DB.pas got changed a little bit just because it had some really bad code in it."
[On bringing the language changes to Win32] "It's really not going to feel that different;
it's just going to have a lot more features."
"Talk to Danny. He's the guy who actually comments out things inside the compiler."
"That won't be in the first round. We had to leave something so we could charge you for it later."
System Unit
Int, Frac, Exp no longer magic. The language has been rich enough to support this for some time, but they finally got around to taking these out of compiler magic.
Trunc, Round are still magic but value types can override just like an operator.
There is no extended type in .NET, so Extended maps to typedo
uble. But for compatibility with old streaming system it's still streamed as 12 bytes, in and out. Naturally when streaming out of VCL for .NET four of those bytes are zero.
All new VCL classes use strict private and strict protected. None of the old abuse of the rules. Would like to go back and fix the old code butdo
ing it wrong would cause total chaos.
"We have a nice new System unit, it has very little stuff in it, it's nice and skinny. The only thing you need to write Delphi code is System. Youdo
n't need the VCL. No Variants, none of those weird types." Borland.Delphi assembly contains only System unit.
Packages are going to contribute to a much simpler namespace scheme. Only two namespaces are planned: Borland.Delphi and Borland.VCL. DB stuff is in Borland.VCL, since non-ADO.NET datasets can only be used with VCL components. Result is a clean separtion between the Delphi language and the VCL framework. Plus it makes things easy to find. "If it's not System, it's probably in the other place."
DB is a great use for Variants. In fact, .NET actually has variants, but all they're used for is DB stuff, and they're only containers. You can'tdo
perform operations on them. But Delphi has to support Win32 code, so implementing them couldn't simply use this.
Complex, Convert, FmtBCD, and SQLTimeStamp have been converted into value types. SQLTimeStamp was created by accident because the person who created it didn't think that TDateTime worked in a certain way, and now we're stuck with it. FmtBCD shouldn't exist either since there's a type of Variant called decimal. But all these types are supported and usable without bringing in Variants.
Classes Unit
TPersistent is an alias to System.MarshallByRefObject for no real reason other than to distinguish it from, say, TObject and TComponent.
TypInfo Unit
Since Delphi types are .NET types, TypInfo completely rewritten with System.Reflection. Beware when using this in conjunction with obfuscators! Internal data structures have been marked as deprecated, but easy functions like GetOrdProp work more or less as they always have.
WinForm connector/importer
Similar to how you use ActiveX in Delphi 7, this tool allows you to import WinForm controls into your VCL form application. But it's much thinner then
the ActiveX container since WinForm controls use the same type system. More of a property mapper.
Database Components
TCustomDataset and the rest is still there. BDE (for desktop DBs), dbExpress, InterBase Express, and ClientDataset have been ported. "We didn't port all of CDS. There are some things inside of CDS which were very difficult to port. So anything that was difficult we didn't." Client tier only has been ported -- server components not ported yet. DataSnap servers will need to be compiled in dcc32 for the time being.
There is an ADO.NET connector/importer. This component allows you to connect an ADO.NET data table to your existing VCL/DB application. It exposes the data table via a custom TDataset. Connect a TDataSource and away you go.
ADOExpress not ported. ADO and ADO.NET are completely different. Probably wouldn't be impossible todo
, but notdo
ne yet.
Bringing These Changes to Win32
The Delphi team wants to make dcc32 know about value types, strict private and protected, pull the magic functions out of the compiler and use the exact same RTL, etc., packages that dccil uses. Hoping todo
this within two quarters. Goal is to use the exact same RTL source with Win32 and .NET.
There's no reason why the team can't bring Decimal to Win32.
Eeek! Things to watch out for.
String is now wide.
Pointer -- There is a Pointer type, but in safe code Pointer is a reference to an object. You can'tdo
pointer math on it.
Sizes of types and order of fields is different. You cannot depend on sizes or the order of fields, period.
Tag is a variant. This is because most of the people who used Tag were cramming objects into it. Works like you'd expect, but youdo
have to use the Variant unit.
PChar is supported in unsafe code. Delphido
esn't use it in the VCL at all.
Use TBytes instead of GetMem, FreeMem, etc.
File of <type> gone. Instead use .NET XML streaming.
Old TP objects gone. Use new value types with methods and properties instead.
Language is now totally isolated from the VCL framework so that youdo
n't have to pull in User32 if youdo
n't want to. VCL is not dead, though. Far from it.
Existing code should just work. Many units haven't changed at all, and the worst mistakes they made in bringing VCL to .NET was to try and change things too much, because it broke the VCL in other places.
There is now a list of things that are needed for full support of Compact Framework, but Microsoft didn't get the SDK fast enough to get it into the first release. But you can pretty much expect it for the next release.
Meet the .NET Team
Simon Thornhill began the presentation by excluding a lot of what, I suspect based on experience at previous BorCons, people were likely to say. He requested no soap boxing, no marketing questions, no specific issues. Well, you were allowed to ask about specific issues if you cornered one of the team personally, but this was a packed session, so there was little room for questions about things not of interest to everyone. Simon then
announced that there will be updates to Win32.
The situation with Kylix is that they are continuing to sell and support the version which is out in the field. They are continually evaluating the situation. At present there is no plan for an update to Kylix in 2004. That isn't to say there won't be another release, but it's not on the horizon at present.
Members of the team were asked to share the first Borland product they worked on and their most embarrassing moment. Here are the highlights:
Chuck J. "The first product I had any of my codeship on was Turbo Prolog."
Danny Thorpe "I was the one person who worked on Turbo Pascal for Windows 1.5."
Ramesh T. "My embarrassing moments are basically when someone comes and asks me to fix BDE bugs."
John Keegan "I've been with Borland since 1962. My first product was Borland Turbo COBOL."
Allen Bauer "My most embarrassing moment was moving BGI to protected mode."
Eddie Churchill "Ido
stuff. Normally Danny and I and Chuck go out to lunch together and I drive. We were instructed that we're not allowed to drive together anymore. Variants would be embarrassing. Variants were bad."
Chuck J.: The original design of the VCL was designed for portability, because 32 bit code was in mind from the outset. It was difficult to deliver on Windows to begin
with, so effort to port to other platforms was no surprise.
Simon Thornhill: "The great thing about business unit names is that we can change them at random. Tomorrow we could be the COBOL business unit. The '.NET Business Unit' also upset our legal department."
Namable, recordable macros: "It'sdo
cumented in the online Help that theydo
n't work right."
"We want to have CF support in the next year. Microsoft is anxious to work with us on this. This release of Delphi for .NETdo
esn't have a button in the IDE which says 'deploy to CF' but you should be able to copy the right files in the right place and it should work." Expect an article on this. You can't build a desktop app and take it to CF, but you can build a CF app and take it to desktop.
Eddie Churchill ".NET was actually built for Delphi. .NET has features that Microsoftdo
esn't even use, like sets and things of that nature. They have our string, for Pete's sake, because their string was broken." John Kaster: "I was at PDC last week and mentioned that Anders has been working for Borland for all this time and wants to know where his back pay is."
Chuck J. "Some of the justification for things we didn'tdo
... When .NET did something really well we didn't feel it was worth it to duplicate something that .NET already did."
Corbin Dunn: "Everything you see in the [Galileo] IDE is componentized, so we will probably be delivering [these new IDE features] as components."
