Comments for Mining Delphi's demo programs

Mining Delphi's demo programs

2001-12-18T23:51:39-08:00

Thank you for digging out some diamonds! Now I'm encouraged to look for more gems for myself!

re: and I may be wrong but I don't like the look of this either

2001-12-07T17:40:34-08:00

The statement Listbox1.Items := Screen.Fontsis completely safe. Look at the implementation of TListbox.SetItems. It calls Assign to transfer the contents of the string list into the internal stringlist. It does not acquire a reference to the Screen.Fonts object. This is one of many design patterns in VCL.-Danny

re: and I may be wrong but I don't like the look of this either

2001-12-05T02:54:47-08:00

sorry did'nt put a suggestion for improvement..procedure TForm1.FormCreate(Sender: TObject);begin Listbox1.Items.AddStrings(Screen.Fonts);end;or maybe procedure TForm1.FormCreate(Sender: TObject);begin Listbox1.Items.Assign(Screen.Fonts);end;

and I may be wrong but I don't like the look of this either

2001-12-05T02:50:16-08:00

{ Display the available fonts... }procedure TForm1.FormCreate(Sender: TObject);begin Listbox1.Items := Screen.Fonts;end;Now surely Listbox1.Items points to a TStrings object, that Listbox1 created, and Listbox1 will destroy Items when it is destroyed. This code moves this pointer to another TStrings object. This will result in a memory leak. Plus when Listbox1 is destroyed the memory Screen.Fonts refers to will be freed, resulting in possible AV's.

Well the first example is dodgy for a start...

2001-12-05T02:39:15-08:00

{ List all the fields in a dataset (from DBFilter) }for I := 0 to DM1.CustomerSource.Dataset.FieldCount - 1 do ListBox1.Items.Add(DM1.Customer.Fields[I].FieldName);Whilst DM1.CustomerSource.Dataset clearly is DM1.Customer it is not the best practice to refer to it in 2 different ways in a loop. Should DM1.CustomerSource.Dataset be changed to point to another dataset the code would fall over.

re: Some of this stuff is CRAP.

2001-11-30T13:11:14-08:00

That particular example is also less than ideal because the strings are not localizable. Strings displayed to the end user should be resourced so they can be translated into the end-user's language.Demo programs almost never have that degree of completeness. The RTL, VCL, and CLX sources are the code to study closely. That's the code that's actually used in production.-Danny

Some of this stuff is CRAP.

2001-11-29T11:11:17-08:00

I dunno, sometimes Borland goes out of it's way to write bad Pascal.Look at this supposed Gem:const Colors: array[0..6] of TColor = (clWhite, clBlue, clGreen, clRed, clTeal, clPurple, clLime); ColStr: array[0..6] of string = ('White', 'Blue', 'Green', 'Red', 'Teal', 'Purple', 'Lime');The problem here is that the relationship mapping is not explicitly maintained. That is if I change the Colors array to add clButtonFace, but don't update colStr, guess what code will fail with a range check (if that's turned on) or a GPF at run time?This code would have been better served with a sub range type such astype ColorRange = 0..6;const Colors: array[ColorRange] of TColor = (clWhite, clBlue, clGreen, clRed, clTeal, clPurple, clLime); ColStr: array[ColorRange] of string = ('White', 'Blue', 'Green', 'Red', 'Teal', 'Purple', 'Lime');Now I have explicitly linked the relationship in the number of elements between the two items. If I add elements without updating the range, the compiler will flag this with "number of elements differs fro declaraion" or I change the range, the compiler will tell me all the places I need to update

Mining Delphi's demo programs

2001-11-29T08:04:25-08:00

Interesting collection of tidbits. I knew those demos were good for something. ;-)

Now that you mention it...

2001-11-29T02:58:05-08:00

... I mean, C++ Builder demos, would you call this a good (or even, acceptable) piece of code?// The problem lies in the try/catch codevoid TMastData::UpdateParts(double PartNo, long Qty){ if ((PartNo > 0) && (Qty != 0)) try { Set flags; if (!Parts->Locate("PartNo", PartNo, flags)) Abort(); Parts->Edit(); PartsOnOrder->Value = PartsOnOrder->Value + Qty; Parts->Post(); } catch(Exception& E) { char msg[250]; sprintf(msg,"Error updating parts table for PartNo: %d", PartNo); ShowMessage(msg); }}The "translator" for the examples had followed the "C++ for applications without a message loop" style for exception handling. There's not a hint about the existence of a try/__finally instruction, and code is duplicated along several try/catch code instances. Moreover, those "try/catch imitating try/__finally" regularly finishes the catch clause with a blatant "return", instead of the more appropiated "rethrow".

Mining Delphi's demo programs

2001-11-28T16:12:57-08:00

C++Builder also has loads of demo's >= 117, also there is loads of source code in $(BCB)\Source, most of the property editors etc are there, in addition many 3rd party groups have example code using their stuff. Also there is loads of example code at code central, etc and finally for those like me who are fluent in both delphi and C++, you can always translate from one to the other, or just use the fact that builder compiles Delhi units. Happy Code mining PS Pity Delphi cannot use builder code as easily (but I dream of the day it will).