Wow, like I didn't see that coming! Borland/CodeGear sure like to drop products. They handed the .NET part over to RemObjects. Their porfolio sure can't look any worse even if they tried. Than God for Free Pascal!!! You guys have been a life saver to our company. We took a hard knock after we invested in Kylix and that got tanked. At least now with Free Pascal we know where we stand and don't have to worry about the product being dropped due to bad marketing decisions.

Long live Free Pascal! :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

And some links for your reading pleasure... ;-)

http://www.remobjects.com/oxygene.aspx
http://www.codegear.com/products/delphi/prism

Graeme.

I may have misread or may be misinformed. But: divergence between win32 and .net was on the roadmap..
And what's wrong with buying in to a dedicated project. It is sound business if the product is tops. Sounder than Kylix at the time. (although imho that business was - still is -sound, but technically poorly implemented)

Just to add my 2cents

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.4/1751 - Release Date: 27-10-2008 22:44

For me this is the start of the end of Embarcadero's Delphi product.

Since years Delphi is following a route into .NET. (you can't install Delphi without running .NOT on that PC. Borland/Codegear created "Delphi for .NET as a migration path. This productproducrt does not seem to be very successful though. (I did not try it but I did hear that it is not very nice.) Now they cut away the future they themselves had chosen.

OTOH with Oxygen/Prism in place for .NET and FPC with Lazarus or MSEGUI in place for native code, the users are not in a too bad situation.

I feel that CLR (call it CIL, .NET, Mono or whatever) enhanced by Silverlight/Moonlight for remote GUI applications, and CLR enabled stored procedures (e.g. created with Oxygen/Prism) in modern databases and a lot more possibilities for remote procedure execution enabled by CLR, is the foreseeable future of a great part of the software world, on PCs big Iron and even for embedded devices. So concentrating on Oxygen instead of the seemingly problematic "Delphi for .NET" is a good idea.

-Michael

Graeme Geldenhuys wrote

And some links for your reading pleasure... ;-) http://www.remobjects.com/oxygene.aspx

A pleasure indeed ;-)
I did not know Oxigene/Prism syntax has evolved fo far ahead of Delphi/FPC. While browsing their wiki, I found at least following items which are IMO worthy to add to FPC:

1) http://prismwiki.codegear.com/en/With_(keyword) but without 'matching' clause.

2) http://prismwiki.codegear.com/en/Properties#Property_Access_Modifiers

Also, following, while being a mere syntactic sugar, are also 'good-to-have':

1) 'case' by string and type http://prismwiki.codegear.com/en/Case_(keyword) Although I would spell it 'case obj.ClassType of', not 'class obj type of' -- no need for new syntax here.

2) Local variables initialization during declaration -- but with constants only.

3) http://prismwiki.codegear.com/en/Exception_Handling#Combining_except_and_finally_blocks

Alexander Klenin wrote

1) http://prismwiki.codegear.com/en/With_(keyword) but without 'matching' clause.

The following code is just confusing as hell...

with b: Button := new Button do
  with c: Color := b.BackColor do begin
    ...
    b.Text := 'Hello World';
    self.Text := c.ToString;
    ...
  end;
end;

1) 'case' by string and type http://prismwiki.codegear.com/en/Case_(keyword)

Did you not know that this is supported in FPC (for some time now). ;-) And it's not just limited to ordinal or string types.... I'll share my code. We have been using this for some time in our projects. :-)

Example usage:

  case CaseObject(Action, [BackAction, ForwardAction]) of
    0: BackAction.Enabled := FTreeViewAdapter.BackStack.Count > 0;
    1: ForwardAction.Enabled := FTreeViewAdapter.ForwardStack.Count > 0;
  end;
---------------------[ m2utils.pas ]-------------------------
  // case statement support methods
  function CaseObject(AObject: TObject; AObjectArray: array of
TObject): Integer;
  function CaseClass(AClass: TClass; AClassArray: array of TClass):
Integer; overload;
  function CaseClass(AObject: TObject; AClassArray: array of TClass):
Integer; overload;
  function CaseGUID(GUID: TGUID; GUIDArray: array of TGUID): Integer;
  function CaseInterface(AInterface: IInterface; AClassArray: array of
IInterface): Integer;
  function CaseString(S: string; SArray: array of string): Integer;
  function CasePointer(P: Pointer; PArray: array of Pointer): Integer;

{ Case statement support methods }

function CaseObject(AObject: TObject; AObjectArray: array of TObject): Integer;
var
  Counter: Integer;
begin
  Result := -1;
  for Counter := 0 to Length(AObjectArray)-1 do
  begin
    if AObject = AObjectArray[Counter] then
    begin
      Result := Counter;
      Exit; //==>
    end;
  end;
end;
function CaseClass(AClass: TClass; AClassArray: array of TClass): Integer;
var
  Counter: Integer;
begin
  Result := -1;
  for Counter := 0 to Length(AClassArray)-1 do
  begin
    if AClass = AClassArray[Counter] then
    begin
      Result := Counter;
      Exit; //==>
    end;
  end;
end;
function CaseClass(AObject: TObject; AClassArray: array of TClass): Integer;
begin
  Result := CaseClass(AObject.ClassType, AClassArray);
end;
function CaseGUID(GUID: TGUID; GUIDArray: array of TGUID): Integer;
var
  Counter: Integer;
begin
  Result := -1;
  for Counter := 0 to Length(GUIDArray)-1 do
  begin
    if IsEqualGUID(GUID, GUIDArray[Counter]) then
    begin
      Result := Counter;
      Exit; //==>
    end;
  end;
end;
function CaseInterface(AInterface: IInterface; AClassArray: array of
IInterface): Integer;
var
  Counter: Integer;
begin
  Result := -1;
  for Counter := 0 to Length(AClassArray)-1 do
  begin
    if AInterface = AClassArray[Counter] then
    begin
      Result := Counter;
      Exit; //==>
    end;
  end;
end;
function CaseString(S: string; SArray: array of string): Integer;
var
  Counter: Integer;
begin
  Result := -1;
  for Counter := 0 to Length(SArray)-1 do
  begin
    if S = SArray[Counter] then
    begin
      Result := Counter;
      Exit; //==>
    end;
  end;
end;
function CasePointer(P: Pointer; PArray: array of Pointer): Integer;
var
  Counter: Integer;
begin
  Result := -1;
  for Counter := 0 to Length(PArray)-1 do
  begin
    if P = PArray[Counter] then
    begin
      Result := Counter;
      Exit; //==>
    end;
  end;
end;
-----------------------------[ end ]---------------------------

3) http://prismwiki.codegear.com/en/Exception_Handling#Combining_except_and_finally_blocks

Now that would be very handy!! Saves on typing and saves on indentation.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2008/11/6 Graeme Geldenhuys :

no, fpc only supports case of ordinal, enum and char types. your example just shows the most common way to get around that.

henry

I know that! You clearly missed the smiley face. :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2008/11/6 Graeme Geldenhuys :

I know that! You clearly missed the smiley face. :-)

heh, sorry about that. must've had my serious hat on :)

henry

Henry Vermaak wrote

> > I know that! You clearly missed the smiley face. :-) heh, sorry about that. must've had my serious hat on :)

No problems. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Op Thu, 6 Nov 2008, schreef Graeme Geldenhuys:

Another not-exact solution, supported in FPC since version 2.3 is:

type colour=(red,green,blue);
var s:string;
     c:colour;
begin
   val(s,c);
   case c of:
     red:
       writeln('s contained "red"');
     green:
       writeln('s contained "green"');
     blue:
       writeln('s contained "blue"');
   end;
end;

Daniël

Maybe, but consider the alternative in today's FPC:
with Button.Create do
  with BackColor do begin
    Text := 'Hello World';
    Self.Text := ToString;
  end;

It is easy to miss which properties refer to which objects, and hard to read the code even if you manage to remember it correctly. Another common usage would be:

with p := MyForm.Canvas.ClipRect do
   Draw(p.Right - p.Left, p);

I.e. referring to object itself inside the 'with' statement. Now it requires a temporary variable.

Note that I would prefer abbreviated form without explicit type. Full syntax has IMO too little advantage over the temporary.

And a perfect example of why I DON'T user the 'with' statement! Hard to read, hard to understand and hard to debug (tooltip expressions cannot evaluate it even in Delphi v7 at least). :)

I feel strongly against the WITH statement as I do against the GOTO statement. The only time you will ever see me use the WITH statement is in auto generate UI code as shown below:

  cbType := TfpgComboBox.Create(self);
  with cbType do
  begin
    Name := 'cbType';
    SetPosition(8, 24, 272, 22);
    FontDesc := '#List';
  end;

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I agree to some extend. Nested with statements are evil. A single with should be allowed because it actually adds value.

WITH is also usefull to initialize records

with rec do begin
  field1 := 1;
  field2 := 2;
  field3 := 3;
  field4 := 4;
  // and so on
end;

rather than c'sh style:

rec.field1 := 1;
rec.field2 := 2;
rec.field3 := 3;
rec.field4 := 4;
I also like to use with structure in bigger 'if' statement: with rec do if
(field1 = 0) and (field2  field3) or (field4  0) then {...};
instead of: if (rec.field1 = 0) and (rec.field2  rec.field3) or
(rec.field4  0) then {...};

though, i don't like usinng nested withs, or with for multiple records (with rec1, rec2 do). It can make like easier, but it can also bring some bug in the code :)

Anyway. All libs are written, using old-style syntax. So is it realyl necessary, to add these new syntax changes to FPC? may be it's better to clean then bugs first, and start changing syntax after that? Besides, these changes are designed for .NET IDE, the code that would use new delphi syntax would not be used with FPC, anyway.

Graeme Geldenhuys wrote

And a perfect example of why I DON'T user the 'with' statement! Hard to read, hard to understand and hard to debug (tooltip expressions cannot evaluate it even in Delphi v7 at least). :)

Proposed change can potentially fix all the issues, including debuggability (since the object will be named, and thus accessible to debugger).

So when you write such code by hand, you do not use 'with' ? Anyway, this is all just my opinion, and not too strong at that ;-)

I try to prevent the 'with' statement as much as possible. I'll consider it for a single with statement, but never for a nested with statement.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/