Delphi Prism Latest KB Comments

Shawn: Great approach! Very similar to coding for Win32/Win64 in Delphi and other such code base compiler if defs. Mike

Heres my approach, I dont say its the right approach or the best approach, but its what Ive done.  , , I went through my code and found all the instances where the syntax to do something in PRISM is different from Delphi syntax (e.g. file manipulation: reading, writing, opening or closing a file).  Ignoring syntax incompatibility for a moment, I duplicated the code segment using PRISM syntax (i.e. using all the PRISM/.NET methods that are illegal in Delphi).  I incorporated a hard-coded boolean variable to act as a switch between Delphi code block and the PRISM code block.  , , To get rid of the PRISM-syntax errors that arise when the code is compiled in Delphi, I create dummy methods that have the same name as the .NET methods, but theyre just empty, there is virtually no code in them; they are just there to suppress compiler errors.  , , It doesnt matter if theyre empty because they will never be called if the software is compiled using Delphi... because of t...

I used to like VCL.  Well, it is still okay, but the controls in WPF/Silverlight are just so much more flexible it makes the VCL really show their age.  Most of the .Net controls that I use can be TOTALLY CHANGED in their appears through either styles or templates.  That means if I want to make a button be round with a circular gradient and the text going in a circle around the perimeter of the button, I know I can.  And actually surprisingly easily. And similarly for a DataGrid compared to a DBGrid.  Have you ever tried to change the way a cell works in a DBGrid.  It is miserable.  With a DataGrid it is trivial.  The cell is a template, so it is easy to make it anything you want.  Check boxes, radiobuttons, custom controls, anything.  And you can do data binding in it.  That means it can be a collection of data entities from a database WCF call.  Or it can be an array of objects.  The data, whether it is an array, or a...

Two criticisms.  1. At the very beginning, I would SHOW the Type keyword before the type definition.  Otherwise it looks like it isn't required.  But it IS.  It is just part of the Type statement in later sample code.  And I would even put the Type in front of the class definition shown later.  It isn't required, but it helps readability.  Particularly if you indent the Type statements at the same level.  I would also use vertical white space to separate the types.  Again for readability. 2. Type definitions don't HAVE to go in the Interface section.  They can also go in the Implementation section.  Where it goes depends on scope.  If you want to expose the type, then put it in the Interface.  But, if it is just a type that is used within the scope of Implementation (like some sort of helper class, for instance), then put it in the Implementation. The description makes it sound too much like the Type declaration MUST g...

Now that I have done more .net and Delphi Prism, I also wouldn't do a concatenation just to convert to string. You can actually do: MessageBox.Show( 3.3.ToString );

Oops!  The spelling errors are fixed now. Thanks for letting me know.

A good tip for implementing interfaces is, after you have added the IHuman to the class that is implementing it, you can right click on that IHuman and choose the Implement Interface Members.  It will then stub out all the pieces/parts associated with that interface.  BIG time saver.

FWIW, there's a couple of Catcatenations in with the Concatentations ;-)

FWIW, good points. Nothing wrong with standards. I'll sweep thru and update all these examples. For what it's worth, I agree that private and protected probably could both be camel capped.

Although I don't think Microsoft makes it indisputably clear, this link:http://msdn.microsoft.com/en-us/library/x2dbyw72%28VS.71%29.aspx?ppud=4Says that Properties should be Pascal Case and Protected (non-public?) instance fields should be Camel Case.So I think in your example, CyborgName should be Pascal, as it is, but the backing field should be fcName or Camel Case.Admittedly, they DON'T specifically say what to do with PRIVATE instance fields so that muddies the waters.  But if the backing fields are Pascal and properties are Pascal, then it gets harder to read the code and tell which is which.Of course, personally, I think having case sensitivity in a language is dumb and the same thing goes for these kinds of "case conventions".However, I believe that camel case for the (non-public) fields is the recommendation.FWIW.,