Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - greygor

Pages: [1] 2
1
General Board / Re: Setting "Run By" in Test Details
« on: February 09, 2005, 03:01:15 am »
My Eval Verison is 744, a recent fix????

2
General Board / Setting "Run By" in Test Details
« on: February 09, 2005, 02:19:29 am »
The drop down box in the Test details window doesn't offer the choice of any "persons" that have been entered for the project, nor can you write in it.

How do you set this or is it disabled in the Evaluation Copy ???

3
General Board / Delphi - Generated Code
« on: March 28, 2002, 04:38:04 am »
I think this will be the last request as it is now virtually working.  Just one little niggle.

Here is the source that was reverse engineered;

  TMammal = class(TObject, ICommunicate)
 private
   FEyeColour: TColor;
   FEyeColour2: TColor;
   procedure SetEyeColour(const Value: TColor);
   procedure SetEyeColour2(const Value: TColor);
 protected
   function Agree(Message: string): Boolean;
 published
   property EyeColour: TColor read FEyeColour write SetEyeColour;
   procedure Testing;
 public
   procedure Speak(Message: string);
   property EyeColour2: TColor read FEyeColour2 write SetEyeColour2;
 end;

Code Generated after import into EA

 TMammal = class (ICommunicate)

private
     FEyeColour: TColor;
     FEyeColour2: TColor;
     procedure   SetEyeColour(Value: TColor);
     procedure   SetEyeColour2(Value: TColor);

protected
     function    Agree(Message: string): Boolean;

public
     procedure   Speak(Message: string);

published
     procedure   Testing;
     property EyeColour:TColor read FEyeColour write SetEyeColour;

 end;

Two things;

1: A class Type is required so

  TMammal = class(TObject, ICoomunicate) should have been generated.

2: The public property EyeColour 2 was missed, but not the private field or procedure relating to it.


BTW, can I just congratulate you on the speed of response to these delphi issues, it is very much appreciated.

Mark Stansfield
Senior Developer/Trainer
www.runtimetechnology.co.uk

4
General Board / Re: Delphi Support - Close, but no Kewpie Doll
« on: March 20, 2002, 07:37:06 am »
Fair Enough;

How about this;

Include an option on the Delphi Option screen that allows you to set default visibility which will apply to all Reverse Engineered pas units with classes that have an un-named first section.

KISS  ;D

5
General Board / Re: Delphi Support - Close, but no Kewpie Doll
« on: March 20, 2002, 04:43:04 am »
I was just going off the following

Delphi in a Nutshell pg 45

"Unless you use the $M+ directive (See Chapter 8, Compiler Directives, for details), the default access level is public."

followed by this from Borland's Component Creation Course pg 12 which is talking about default visibility,

"The default depends upon how the class was compiled and which class it inherits from. Classes which are compiled with the {$M-} compiler setting which excludes runtime type information (RTTI) have a default visibility of Public. Classes which are compiled with the {$M+} compiler setting which includes runtime type information have a default visibility of Published. In addition to this any class which inherits either directly or indirectly from a class which includes runtime type information automatically includes runtime type information regardless of the {$M} compiler setting and so these classes also have a default visibility of Published"

I don't think EA are bothered about RTTI and whether it is included or not they just need to know the rules of default visibility.

However something quirky is going on which I'll have to address when I have more time  :-/

Mark Stansfield
Senior Developer/Trainer
Runtime Technology




6
General Board / Re: Delphi Support - Close, but no Kewpie Doll
« on: March 20, 2002, 02:20:46 am »
That's what I get for oversimplyfying the situation to try and make things easier.  However mh is quite right, so lets do this properly.

The default scoping is controlled by the {$M} directive.

{$M+} default Published
{$M-} default Public

However in many cases this is not found in a unit so how can EA tell what it should be.

These are some guidelines.

1. Anything derived directly from TObject, i.e. TMyObject = class or TMyObject = class(TObject) will have a default scoping of Public unless {$M+} is used.

2. Anything derived from TPersistant or its descendents will have a default scoping of Published (Because TPersistant is compiled with {$M+}) unless the {$M-} is used.

3. As TForm is derived from TComponent, which is derived from TPersistant, it has a default scoping of Published. Thus as I was trying to say, albeit badly, you would be right the majority of the time to assume a default scoping of published for Units with Forms in the Uses clause.  However this would not cater for the times when other classes may be declared in the same unit and derived from TObject (Case 1 above).

Mind you, this is according to Borland.  However in experimentation I have found that if I derive a class from TObject and declare a field then it automatically becomes Published - There's probably something I'm missing here and I will come back to it.

Is this any clearer  ???

Mark Stansfield
Senior Developer/Trainer
Runtime Technology

7
General Board / Delphi Support - Close, but no Kewpie Doll
« on: March 19, 2002, 03:57:52 am »
Ok, you're nearly there with the Delphi Import/Export, but there are some major problems.

Let's deal with Interfaces first.


INTERFACE SOURCE

 ICommunicate = interface
   procedure Speak(Message: string);
   function Agree(Message: string): Boolean;
 end;

When imported the procedure and function is protected scope rather than public scope.  There is no scoping for interfaces.

When we forward engineer this from EA then the following is generated


GENERATED INTERFACE SOURCE

unit InterfaceTestGen;

interface

uses
     system, graphics;;

type
 ICommunicate = interface (TObject)

protected
     procedure   Speak(Message: string);
     function    Agree(Message: string): Boolean;

 end;

implementation

procedure   ICommunicate.Speak(Message: string);
begin

end;

function    ICommunicate.Agree(Message: string): Boolean;
begin

end;



end.

1. There should only be one semi-colon after the Uses Clause.
2. The ultimate ancestor of Interface is IInterface, not TObject.
3. Interfaces are implemented in classes and so have no implementation.
4. There is no scoping allowed as Public is the default.

what should be generated is

unit InterfaceTestGen;

interface

uses System;

Type

 ICommunicate = interface
   procedure Speak(Message: string);
   function Agree(Message: string): Boolean;
 end;

implementation

end.





Now for Classes


CLASS SOURCE


unit ClassTest;

interface

uses system, graphics;

Type

 TMammal = class(TObject, ICommunicate)
 private
   FEyeColour: TColor;
   procedure SetEyeColour(const Value: TColor);
 protected
   function Agree(Message: string): Boolean;
 published
   property EyeColour: TColor read FEyeColour write SetEyeColour;
   procedure Testing;
 public
   procedure Speak(Message: string);
 end;

 THuman = class(TMammal)
 automated
   procedure Test2(MyOtherTest: TFont);
 end;

 TAlmostHuman = class(TMammal)
   procedure Test3(MyLastTest: Boolean);
 end;

implementation

function Test1(MyTest: integer): string;
begin
 //code
end;

{ TMammal }

function TMammal.Agree(Message: string): Boolean;
begin
 //code
end;

procedure TMammal.SetEyeColour(const Value: TColor);
begin
 FEyeColour := Value;
end;

procedure TMammal.Speak(Message: string);
begin
 //code
end;

procedure TMammal.Testing;
begin
 //code
end;

{ THuman }

procedure THuman.Test2(MyOtherTest: TFont);
begin
 //code
end;

{ TAlmostHuman }

procedure TAlmostHuman.Test3(MyLastTest: Boolean);
begin
 //code
end;

end.



As we can See TMammal is descended from TObject and Implements the Interface ICommunicate.  It uses the 4 main scoping directives of Delphi; Private, Protected, Published and Public.

when we reverse engineer the TMammal class we get the following.

unit classTestGen;

interface

type
 TMammal = class (TObject)

public
     procedure   Speak(Message: string);

protected
     function    Agree(Message: string): Boolean;

private
     FEyeColour: TColor;
     procedure   SetEyeColour(Value: TColor);

 end;

implementation

procedure   TMammal.Speak(Message: string);
begin

end;

function    TMammal.Agree(Message: string): Boolean;
begin

end;

procedure   TMammal.SetEyeColour(Value: TColor);
begin

end;



end.


As you can see neither the published method Testing nor the published property has been generated. Thinking that this was a problem with recognising Published scoping I put a property in the public section and resynchronised and then forward engineered the class.  This resulted in the following.

type
 TMammal = class (TObject)

public
     procedure   Speak(Message: string);

protected
     function    Agree(Message: string): Boolean;

private
     FEyeColour: TColor;
     FEyeColour2: TColor;
     procedure   SetEyeColour(Value: TColor);
     procedure   SetEyeColour2(Value: TColor);

public
     property +EyeColour2:TColor read FEyeColour2 write SetEyeColour2;


 end;

As you can see we now have the property generated but in a separate public section from the other public procedure and we have a '+' concatenated on the fromt of the property name.  So apart from that it is right.



Next, Delphi default scoping.

If in a Delphi unit 'Forms' is in the Interface uses clause then the default scoping is Published, else it is Public.  Thus


 TAlmostHuman = class(TMammal)
   procedure Test3(MyLastTest: Boolean);
 protected
   procedure Test4;
 end;

If 'Forms' in the uses clause then Test3 is Published, otherwise it is Public.


Finally, Automated.  This is legacy so you may not want to bother but

 THuman = class(TMammal)
 automated
   procedure Test2(MyOtherTest: TFont);
 end;

is a perfectly valid piece of Delphi code.  Not sure how you would identify this in UML or EA.


I hope this has been some help, if you have any questions please don't hesitate to contact me.


Mark Stansfield
Senior Developer/Trainer
Runtime Technology
www.runtime.co.uk
mark@runtime.co.uk

8
General Board / Re: Delphi Support
« on: March 17, 2002, 03:17:23 pm »
The two should work side by side, EA has more features than modelmaker, but modelmaker can do things that EA just can't.  We use both on-site.

9
General Board / Re: Delphi Support (Class Scoping)
« on: March 15, 2002, 05:30:53 am »
That was excellent news, and we look forward to it immensely. Just a quick question.

Will you be catering for Private, Protected, Public and Published Attributes and Methods.  

For backward Delphi compatability it may also be worth including Automated although I don't think it was used much after Delphi 3.

10
General Board / Re: Delphi Support
« on: March 12, 2002, 07:22:30 am »
Great so I can recommend EA to my students w/o the Delphi provisos that I normally add. ;)

Mark Stansfield
Delphi 6 Product and Instructor Certified
www.runtime.co.uk

11
General Board / Delphi Support
« on: March 12, 2002, 04:39:57 am »
I've noticed that you have been doing a lot to enhance the support of VB and C++.

Do you have any plans to tackle the problems with Delphi yet.  

Currently we are supported poorly by Rose and well by the costly Bold package so it is a large base of users that are crying out for good support.

My own requirements would be proper Property and Interface Support.

Mark Stansfield
Delphi 6 Product and Instructor Certified

12
General Board / Re: Re-Importing Classes
« on: March 15, 2002, 05:25:35 am »
Yes, but if you make changes to an existing method or attribute then any notes that you have made about that method are cleared thus negating the usefulness of it. :-[

13
General Board / Re-Importing Classes
« on: March 14, 2002, 02:48:08 am »
As we are all aware development is a dynamic process and things change.

When documenting attributes and operations is there a way you could re-import a class and by so doing, preserve what is already entered for that class, add any new items and remove items that no longer exist in that class.

As all the data is stored in a database I would have thought this was possible.


14
General Board / Re: Issues Report
« on: March 12, 2002, 07:18:38 am »
If you can automate Word and produce a *.doc then you have a winner.   ;D

15
General Board / Issues Report
« on: March 12, 2002, 04:42:45 am »
We had to issue an Open Issues report as part of our project and found this script useful to strip out the closed ones.  If anyone elese wishes to use it feel free.

P.S. Would be nice to have tis option via EA.



Sub delclosed()
'
' delclosed Macro
' Macro recorded 11/03/02 by Joe Otten
'
   Do
   
   Selection.Find.ClearFormatting
   With Selection.Find
       .Text = "Closed:"
       .Replacement.Text = ""
       .Forward = True
       .Wrap = wdFindContinue
       .Format = False
       .MatchCase = True
       .MatchWholeWord = True
       .MatchWildcards = False
       .MatchSoundsLike = False
       .MatchAllWordForms = False
   End With
   Found = Selection.Find.Execute
   If Found Then
     Selection.Rows.Delete
   End If
   
   Loop While Found
   
   
   
End Sub

Pages: [1] 2