uopl-architect — Discuss the direction and architecture of the project

Re: [UOPL-Architect] Interested in the project

[Tom M. <mad...@gm...>]

Currently this is a dormant project.  If anyone else on the list wants 
to help you, please speak up.

Thanks.

mario alejandro wrote:
> Hi,
>
> I'm the main developer of http://sourceforge.net/projects/mutis.
>
> I have the challenge to let MUTIS compile in Win325, .NET and 
> FreePascal. Currently, all the codebase is .NET 1.1 from a direct port 
> of DotLucene.
>
> I have done a very basic attemp to build the portability layer: 
> http://mutis.svn.sourceforge.net/viewvc/mutis/trunk/Mutis/src/PortableCode/ 
> <http://mutis.svn.sourceforge.net/viewvc/mutis/trunk/Mutis/src/PortableCode/>
>
> but lack of understanding in FreePascal and some help.
>
> I have this portability "problems", that is, things in .NET that not 
> have a direct relation to VCL:
>
> http://mutis.svn.sourceforge.net/viewvc/mutis/trunk/Mutis/src/PortableCode/PortingIssues.txt?view=markup
>
>
> I think the first step is have the non-visual aspect covered.
>
> We can merge forces?
>
> -- 
> Mario A.Montoya
> Gerente
> http://www.elmalabarista.com
>
> La mejor guía de los lugares donde estar y disfrutar
> http://www.paradondevamos.com <http://www.paradondevamos.com>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ------------------------------------------------------------------------
>
> _______________________________________________
> UOPL-architect mailing list
> UOP...@li...
> https://lists.sourceforge.net/lists/listinfo/uopl-architect
>   

Re: [UOPL-Architect] Interested in the project

[Dennis L. <dla...@ya...>]

Sorry Mario, I don't work on UOPL.  My name shouldn't be there.  Contact Th=
omas Miller,=0A=0ARegards,=0A=0ADennis Landi=0Ahttp://www.allied-data.com=
=0A=0A----- Original Message ----=0AFrom: mario alejandro <mamcx@elmalabari=
sta.com>=0ATo: uop...@li...=0ASent: Thursday, May 1=
0, 2007 9:51:22 PM=0ASubject: [UOPL-Architect] Interested in the project=0A=
=0AHi,=0A=0AI'm the main developer of http://sourceforge.net/projects/mutis=
.=0A=0AI have the challenge to let MUTIS compile in Win325, .NET and FreePa=
scal. Currently, all the codebase is .NET =0A1.1 from a direct port of DotL=
ucene.=0A=0AI have done a very basic attemp to build the portability layer:=
 http://mutis.svn.sourceforge.net/viewvc/mutis/trunk/Mutis/src/PortableCode=
/=0A=0A=0Abut lack of understanding in FreePascal and some help.=0A=0AI hav=
e this portability "problems", that is, things in .NET that not have a dire=
ct relation to VCL:=0A=0A=0Ahttp://mutis.svn.sourceforge.net/viewvc/mutis/t=
runk/Mutis/src/PortableCode/PortingIssues.txt?view=3Dmarkup=0A=0A=0AI think=
 the first step is have the non-visual aspect covered.=0A=0AWe can merge fo=
rces?=0A=0A=0A-- =0AMario A.Montoya=0AGerente=0Ahttp://www.elmalabarista.co=
m=0A=0ALa mejor gu=EDa de los lugares donde estar y disfrutar=0Ahttp://www.=
paradondevamos.com=0A=0A---------------------------------------------------=
----------------------=0AThis SF.net email is sponsored by DB2 Express=0ADo=
wnload DB2 Express C - the FREE version of DB2 express and take=0Acontrol o=
f your XML. No limits. Just data. Click to get it now.=0Ahttp://sourceforge=
.net/powerbar/db2/=0A_______________________________________________=0AUOPL=
-architect mailing lis...@li...=0Ahttps://li=
sts.sourceforge.net/lists/listinfo/uopl-architect=0A=0A=0A=0A=0A

[UOPL-Architect] Interested in the project

[mario a. <ma...@el...>]

Hi,

I'm the main developer of http://sourceforge.net/projects/mutis.

I have the challenge to let MUTIS compile in Win325, .NET and FreePascal.
Currently, all the codebase is .NET 1.1 from a direct port of DotLucene.

I have done a very basic attemp to build the portability layer:
http://mutis.svn.sourceforge.net/viewvc/mutis/trunk/Mutis/src/PortableCode/

but lack of understanding in FreePascal and some help.

I have this portability "problems", that is, things in .NET that not have a
direct relation to VCL:

http://mutis.svn.sourceforge.net/viewvc/mutis/trunk/Mutis/src/PortableCode/=
PortingIssues.txt?view=3Dmarkup


I think the first step is have the non-visual aspect covered.

We can merge forces?

--=20
Mario A.Montoya
Gerente
http://www.elmalabarista.com

La mejor gu=EDa de los lugares donde estar y disfrutar
http://www.paradondevamos.com

Re: [UOPL-Architect] Maybe Helper Classes would help.

[Thomas M. <tm...@bs...>]

Let me see if Lazarus has this capability.  Maybe we can ask for this 
feature in the compiler.
At a certain point in the hierarchy I want us to go our own way.  There 
is so much code
out there that we can merge to create much better components, it isn't 
funny.  Jedi has
tried to do this, but they are hampered by only being able to inherit.  
We will be able to
go in and fix and expand private areas.  So keep coming with the ideas 
but I like most of
them, especially in the base of the hierarchy of the object tree.  The 
more I think about it,
the more I like the idea of starting with the TNT stuff. 

I am hoping to start the tree by mid January, so if you are going to put 
your 2 cents in,
please do it soon.  I am still hoping for some 64bit input.

I hope everyone has a safe and happy holiday.

Richard B Winston wrote:

>There is a new language feature in Delphi2005 for Win32 that might be
>useful for some of the things we would like to do with UOPL: Helper
>Classes.  One thing you can do with them is replace an existing procedure
>of a class with a new procedure from a different class that is not the
>descendent of the first class.
>
>Although helper classes are only documented for Delphi for .NET, they work
>in Delphi for Win32 too.
>
>See http://www.aspfree.com/c/a/.NET/The-Delphi-Language-Part-2/9/ for more
>information.
>
>Here is an example.
>
>unit Unit5;
>
>interface
>
>uses
>  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls,
>Forms,
>  Dialogs, StdCtrls;
>
>type
>  TFoo = class
>  strict protected
>    procedure AProc; virtual;
>  end;
>
>  TFooDescendent = class(TFoo)
>    procedure AProc; override;
>  end;
>
>  TFooHelper = class helper for TFoo
>    procedure AProc;
>  end;
>
>type
>  TForm5 = class(TForm)
>    Button1: TButton;
>    procedure Button1Click(Sender: TObject);
>  private
>    { Private declarations }
>  public
>    { Public declarations }
>  end;
>
>var
>  Form5: TForm5;
>
>implementation
>
>{$R *.dfm}
>
>{ TFoo }
>
>procedure TFoo.AProc;
>begin
>  ShowMessage('TFoo');
>end;
>
>{ TFooHelper }
>
>procedure TFooHelper.AProc;
>begin
>  ShowMessage('TFooHelper');
>end;
>
>{ TFooDescendent }
>
>procedure TFooDescendent.AProc;
>begin
>  inherited;
>  ShowMessage('TFooDescendent');
>end;
>
>
>procedure TForm5.Button1Click(Sender: TObject);
>var
>  Foo: TFoo;
>  FooDescendent: TFooDescendent;
>begin
>  FooDescendent := TFooDescendent.Create;
>  try
>    // TFooHelper.AProc and TFooDescendent.AProc get called here
>    // but not TFoo.AProc!
>    FooDescendent.AProc;
>    Foo := FooDescendent;
>    // Only  TFooHelper.AProc gets called here. :-(
>    Foo.AProc;
>  finally
>    FooDescendent.Free;
>  end;
>end;
>
>end.
>
>Richard B. Winston
>rb...@us...
>http://water.usgs.gov/nrp/gwsoftware/
>703-648-5988
>on Fridays: 301 474-2762
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>  
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

[UOPL-Architect] Maybe Helper Classes would help.

[Richard B W. <rb...@us...>]

There is a new language feature in Delphi2005 for Win32 that might be
useful for some of the things we would like to do with UOPL: Helper
Classes.  One thing you can do with them is replace an existing procedure
of a class with a new procedure from a different class that is not the
descendent of the first class.

Although helper classes are only documented for Delphi for .NET, they work
in Delphi for Win32 too.

See http://www.aspfree.com/c/a/.NET/The-Delphi-Language-Part-2/9/ for more
information.

Here is an example.

unit Unit5;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls,
Forms,
  Dialogs, StdCtrls;

type
  TFoo = class
  strict protected
    procedure AProc; virtual;
  end;

  TFooDescendent = class(TFoo)
    procedure AProc; override;
  end;

  TFooHelper = class helper for TFoo
    procedure AProc;
  end;

type
  TForm5 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form5: TForm5;

implementation

{$R *.dfm}

{ TFoo }

procedure TFoo.AProc;
begin
  ShowMessage('TFoo');
end;

{ TFooHelper }

procedure TFooHelper.AProc;
begin
  ShowMessage('TFooHelper');
end;

{ TFooDescendent }

procedure TFooDescendent.AProc;
begin
  inherited;
  ShowMessage('TFooDescendent');
end;


procedure TForm5.Button1Click(Sender: TObject);
var
  Foo: TFoo;
  FooDescendent: TFooDescendent;
begin
  FooDescendent := TFooDescendent.Create;
  try
    // TFooHelper.AProc and TFooDescendent.AProc get called here
    // but not TFoo.AProc!
    FooDescendent.AProc;
    Foo := FooDescendent;
    // Only  TFooHelper.AProc gets called here. :-(
    Foo.AProc;
  finally
    FooDescendent.Free;
  end;
end;

end.

Richard B. Winston
rb...@us...
http://water.usgs.gov/nrp/gwsoftware/
703-648-5988
on Fridays: 301 474-2762

Re: [UOPL-Architect] how design uopl gui applications

[Thomas M. <tm...@bs...>]

Yes they do, but he fixes things in other places where they need to be 
fixed.  Some of the stuff he
has done, I would prefer to make our own components from scratch taking 
some code from
Turbo Power and this suite and coming up with a whole new component.  
But we can figure
that out later.  The important thing is coming up with a game plan on 
where to start and making
sure we are not painting ourselves into a corner.

Anyone else have an opinion on where we should start?

Richard B Winston wrote:

>It looks like all of his controls descend from VCL controls.  For example,
>TTntButton descends from TButton.  In each control, string properties are
>replaced with WideString properties with the same names.  Thus the caption
>of TButton is declared as property Caption: TWideCaption;  (TWideCaption =
>WideString.)  Thus, his controls do not form a separate hierarchy from the
>VCL controls.
>
>An important function is the following from TntWindows which is used for
>things like setting the caption of a control.  This function is platform
>specific so it would need to be extended to use it on other platforms such
>as Linux.
>
>function Tnt_SetWindowTextW(hWnd: HWND; lpString: PWideChar): BOOL;
>begin
>  if Win32PlatformIsUnicode then
>    Result := SetWindowTextW(hWnd, lpString)
>  else
>    Result := SetWindowTextA(hWnd, PAnsiChar(AnsiString(lpString)));
>end;
>
>Richard B. Winston
>rb...@us...
>http://water.usgs.gov/nrp/gwsoftware/
>703-648-5988
>on Fridays: 301 474-2762
>
>
>                                                                                                                                      
>                      Thomas Miller                                                                                                   
>                      <tm...@bs...>             To:       uop...@li...                           
>                      Sent by:                               cc:                                                                      
>                      uop...@li...        Subject:  Re: [UOPL-Architect] how design uopl gui applications          
>                      ceforge.net                                                                                                     
>                                                                                                                                      
>                                                                                                                                      
>                      12/21/2004 02:34 PM                                                                                             
>                      Please respond to                                                                                               
>                      uopl-architect                                                                                                  
>                                                                                                                                      
>                                                                                                                                      
>  
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

Re: [UOPL-Architect] how design uopl gui applications

[Richard B W. <rb...@us...>]

It looks like all of his controls descend from VCL controls.  For example,
TTntButton descends from TButton.  In each control, string properties are
replaced with WideString properties with the same names.  Thus the caption
of TButton is declared as property Caption: TWideCaption;  (TWideCaption =
WideString.)  Thus, his controls do not form a separate hierarchy from the
VCL controls.

An important function is the following from TntWindows which is used for
things like setting the caption of a control.  This function is platform
specific so it would need to be extended to use it on other platforms such
as Linux.

function Tnt_SetWindowTextW(hWnd: HWND; lpString: PWideChar): BOOL;
begin
  if Win32PlatformIsUnicode then
    Result := SetWindowTextW(hWnd, lpString)
  else
    Result := SetWindowTextA(hWnd, PAnsiChar(AnsiString(lpString)));
end;

Richard B. Winston
rb...@us...
http://water.usgs.gov/nrp/gwsoftware/
703-648-5988
on Fridays: 301 474-2762


                                                                                                                                      
                      Thomas Miller                                                                                                   
                      <tm...@bs...>             To:       uop...@li...                           
                      Sent by:                               cc:                                                                      
                      uop...@li...        Subject:  Re: [UOPL-Architect] how design uopl gui applications          
                      ceforge.net                                                                                                     
                                                                                                                                      
                                                                                                                                      
                      12/21/2004 02:34 PM                                                                                             
                      Please respond to                                                                                               
                      uopl-architect                                                                                                  
                                                                                                                                      
                                                                                                                                      




Richard,

Did you get a chance to look at TNT?  I just got done looking at it and
it resides side by side with
the VCL, not replacing it.  All of the units, objects, etc start with
TNT.  I have contacted the author
to see if he has any words of wisdom for us.  So we still need to answer
the question, where do we
start?  It is obvious we need to be careful about how we do things
around Persistent and Component,
but we may still be able to extend both.

Richard B Winston wrote:

>When I tried to use this technique, the component compiled OK but I got an
>access violation when I tried to install the component.  This is what I
>expected. I believe that this means if UOPL starts from anything below
>TComponent, it will not be possible to place the UOPL components on the
>component palette.
>
>Here is what I did.
>
>1. I copied a Classes into a new unit called MyClasses
>2. In MyClasses, I changed the ancestor of TComponent from TPersistent to
>TInterfacedPersistent.
>3. I changed the declaration of QueryInterface to override the declaration
>in TInterfacedPersistent.
>
>before
>    function QueryInterface(const IID: TGUID; out Obj): HResult; virtual;
>stdcall;
>after
>    function QueryInterface(const IID: TGUID; out Obj): HResult; override;
>stdcall;
>
>4. I created a component in a new unit that used the version of TComponent
>in MyClasses.
>
>Here is a copy of that unit.
>
>unit ExperimentUnit;
>
>interface
>
>uses Classes, MyClasses;
>
>type
>  TExperimentComponent = class(TComponent)
>  private
>    FInt1: integer;
>    procedure SetInt1(const Value: integer);
>  published
>    property Int1: integer read FInt1 write SetInt1;
>  end;
>
>procedure Register;
>
>implementation
>
>procedure Register;
>begin
>  Classes.RegisterComponents('Experiments',
>    [Classes.TComponentClass(TExperimentComponent)]);
>end;
>
>{ TExperimentComponent }
>
>procedure TExperimentComponent.SetInt1(const Value: integer);
>begin
>  FInt1 := Value;
>end;
>
>end.
>
>Richard B. Winston
>rb...@us...
>http://water.usgs.gov/nrp/gwsoftware/
>703-648-5988
>on Fridays: 301 474-2762
>
>
>

>                      "Dennis Landi"

>                      <de...@de...>               To:
<uop...@li...>
>                      Sent by:                               cc:

>                      uop...@li...        Subject:  Re:
[UOPL-Architect] how design uopl gui applications
>                      ceforge.net

>

>

>                      12/03/2004 01:48 PM

>                      Please respond to

>                      uopl-architect

>

>

>
>
>
>
>Re: the tInterfacedPersistent -->> tInterfacedComponent descendants being
>registerable.
>
>It will be interesting to see if a tInterfacedComponent replica of the
>TComponent interface is registerable.
>
>I don't see why it wouldn't be...  It will be an easy enough experiment to
>run.
>
>You would simply have to typecast it in the Registration proc.
>
>The registration syntax would be:
>
>  RegisterComponents('MyComponentPage',[tComponentClass(TMyComponent)]);
>
>The interfaces of both artifacts would have to match; and if so, the IDE
>registration mechanism probably won't notice.
>
>This means that would have to hack the original source of tComponent; and
>clone a tInterfaceComponent version; which we would probably have to only
>be
>able to distribute as a DCU...  But, I don't see that as a show-stopper.
>
>If the technique works, then we can actually introduce it to the delphi
>community, as it will allow them to unify artificacts at the component
>level, which will come in really handy for things like plug-ins.
>
>
>
>Dennis Landi
>Allied Data, Inc.
>800 204 2722
>http://www.dennislandi.com
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>
>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>
>

--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
UOPL-architect mailing list
UOP...@li...
https://lists.sourceforge.net/lists/listinfo/uopl-architect

Re: [UOPL-Architect] how design uopl gui applications

[Thomas M. <tm...@bs...>]

Richard,

Did you get a chance to look at TNT?  I just got done looking at it and 
it resides side by side with
the VCL, not replacing it.  All of the units, objects, etc start with 
TNT.  I have contacted the author
to see if he has any words of wisdom for us.  So we still need to answer 
the question, where do we
start?  It is obvious we need to be careful about how we do things 
around Persistent and Component,
but we may still be able to extend both.

Richard B Winston wrote:

>When I tried to use this technique, the component compiled OK but I got an
>access violation when I tried to install the component.  This is what I
>expected. I believe that this means if UOPL starts from anything below
>TComponent, it will not be possible to place the UOPL components on the
>component palette.
>
>Here is what I did.
>
>1. I copied a Classes into a new unit called MyClasses
>2. In MyClasses, I changed the ancestor of TComponent from TPersistent to
>TInterfacedPersistent.
>3. I changed the declaration of QueryInterface to override the declaration
>in TInterfacedPersistent.
>
>before
>    function QueryInterface(const IID: TGUID; out Obj): HResult; virtual;
>stdcall;
>after
>    function QueryInterface(const IID: TGUID; out Obj): HResult; override;
>stdcall;
>
>4. I created a component in a new unit that used the version of TComponent
>in MyClasses.
>
>Here is a copy of that unit.
>
>unit ExperimentUnit;
>
>interface
>
>uses Classes, MyClasses;
>
>type
>  TExperimentComponent = class(TComponent)
>  private
>    FInt1: integer;
>    procedure SetInt1(const Value: integer);
>  published
>    property Int1: integer read FInt1 write SetInt1;
>  end;
>
>procedure Register;
>
>implementation
>
>procedure Register;
>begin
>  Classes.RegisterComponents('Experiments',
>    [Classes.TComponentClass(TExperimentComponent)]);
>end;
>
>{ TExperimentComponent }
>
>procedure TExperimentComponent.SetInt1(const Value: integer);
>begin
>  FInt1 := Value;
>end;
>
>end.
>
>Richard B. Winston
>rb...@us...
>http://water.usgs.gov/nrp/gwsoftware/
>703-648-5988
>on Fridays: 301 474-2762
>
>
>                                                                                                                                      
>                      "Dennis Landi"                                                                                                  
>                      <de...@de...>               To:       <uop...@li...>                         
>                      Sent by:                               cc:                                                                      
>                      uop...@li...        Subject:  Re: [UOPL-Architect] how design uopl gui applications          
>                      ceforge.net                                                                                                     
>                                                                                                                                      
>                                                                                                                                      
>                      12/03/2004 01:48 PM                                                                                             
>                      Please respond to                                                                                               
>                      uopl-architect                                                                                                  
>                                                                                                                                      
>                                                                                                                                      
>
>
>
>
>Re: the tInterfacedPersistent -->> tInterfacedComponent descendants being
>registerable.
>
>It will be interesting to see if a tInterfacedComponent replica of the
>TComponent interface is registerable.
>
>I don't see why it wouldn't be...  It will be an easy enough experiment to
>run.
>
>You would simply have to typecast it in the Registration proc.
>
>The registration syntax would be:
>
>  RegisterComponents('MyComponentPage',[tComponentClass(TMyComponent)]);
>
>The interfaces of both artifacts would have to match; and if so, the IDE
>registration mechanism probably won't notice.
>
>This means that would have to hack the original source of tComponent; and
>clone a tInterfaceComponent version; which we would probably have to only
>be
>able to distribute as a DCU...  But, I don't see that as a show-stopper.
>
>If the technique works, then we can actually introduce it to the delphi
>community, as it will allow them to unify artificacts at the component
>level, which will come in really handy for things like plug-ins.
>
>
>
>Dennis Landi
>Allied Data, Inc.
>800 204 2722
>http://www.dennislandi.com
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>
>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>  
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

Re: [UOPL-Architect] Back ground work

[Thomas M. <tm...@bs...>]

Anyone get a chance to look at this yet?  With the work Robert has
already done, it is obvious that we need to be very careful about
where we start.  Over the holidays, I will dive into this library and
see what I can pick up on how this guy gets around the Control
issue.  It seems that he add both his own units and the standard
Delphi units to all his examples.  So there is a UniForm (I believe
it is TnTForm) and a Form unit in the uses clause. 



Thomas Miller wrote:

> Just ran across this.  It is completely open to use all of this code.
>
> http://www.tntware.com/delphicontrols/unicode/
>
> Thomas Miller wrote:
>
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

Re: [UOPL-Architect] Back ground work

[Thomas M. <tm...@bs...>]

Just ran across this.  It is completely open to use all of this code.

http://www.tntware.com/delphicontrols/unicode/

Thomas Miller wrote:

> We still have lots of back ground work to do for the project. Here is 
> some stuff
> to read
>
> http://www.freepascal.org/docs.html
>
> User.pdf
>
> Chapter 9
> Units that come with Free Pascal
> Here we list the units that come with the Free Pascal distribution. 
> Since there is a difference in the
> supplied units per operating system, we first describe the generic 
> ones, then describe those which are
> operating specific.
> 9.1 Standard units
> The following units are standard and are meant to be ported to all 
> supported platforms by Free Pascal.
> A brief description of each unit is also given.
> crt This unit is similar to the unit of the same name of Turbo Pascal. 
> It implements writing to the
> console in color, moving the text cursor around and reading from the 
> keyboard.
> dos This unit provides basic routines for accessing the operating 
> system. This includes file searching,
> environment variables access, getting the operating system version, 
> getting and setting
> the system time. It is to note that some of these routines are 
> duplicated in functionality in the
> sysutils unit.
> getopts This unit gives you the GNU getopts command-line arguments 
> handling mechanism. It
> also supports long options.
> graph This unit provides basic graphics handling, with routines to 
> draw lines on the screen, display
> texts etc. It provides the same functions as the Turbo Pascal unit.
> keyboard provides basic keyboard handling routines in a platform 
> independent way, and supports
> writing custom drivers.
> math This unit contains common mathematical routines (trigonometric 
> functions, logarithms, etc.)
> as well as more complex ones (summations of arrays, normalization 
> functions, etc.).
> mmx This unit provides support for mmx extensions in your code.
> mouse provides basic mouse handling routines in a platform independent 
> way, and supports writing
> custom drivers.
> objects This unit provides the base object for standard Turbo Pascal 
> objects. It also implements File
> and Memory stream objects, as well as sorted and non-sorted 
> collections, and string streams.
> objpas is used for Delphi compatibility; you should never load this 
> unit explicitly; it is automatically
> loaded if you request Delphi mode.
> 99
> CHAPTER 9. UNITS THAT COME WITH FREE PASCAL
> printer This unit provides all you need for rudimentary access to the 
> printer using standard I/O
> routines.
> sockets This gives the programmer access to sockets and TCP/IP 
> programming.
> strings This unit provides basic string handling routines for the 
> pchar type, comparable to similar
> routines in standard C libraries.
> system This unit is available for all supported platforms, even though 
> the unit name may be different
> (e.g : syslinux, sysos2). It includes among others, basic file I/O 
> routines, memory management
> routines, all compiler helper routines, and directory services routines.
> sysutils is an alternative implementation of the sysutils unit of 
> Delphi. It includes file I/O access
> routines which takes care of file locking, date and string handling 
> routines, file search, date
> and string conversion routines.
> typinfo Provides functions to acces Run-Time Type Information, just 
> like Delphi.
> video provides basic screen handling in a platform independent way, 
> and supports writing custom
> drivers.
> 9.2 Under DOS
> emu387 This unit provides support for the coprocessor emulator.
> go32 This unit provides access to possibilities of the GO32 DOS extender.
> 9.3 UnderWindows
> wincrt This implements a console in a standard GUI window, contrary to 
> the crt unit which is for
> the Windows console only.
> Windows This unit provides access to al Win32 API calls. Effort has 
> been taken to make sure that
> it is compatible to the Delphi version of this unit, so code for 
> Delphi is easily ported to Free
> Pascal.
> opengl provides access to the low-level opengl functions in WINDOWS.
> winmouse provides access to the mouse in WINDOWS.
> ole2 provides access to the OLE capabilities of WINDOWS.
> winsock provides acces to the WINDOWS sockets API Winsock.
> 9.4 Under Linux
> linux This unit provides access to the LINUX operating system. It 
> provides most file and I/O handling
> routines that you may need. It implements most of the standard C 
> library constructs that you
> will find on a Unix system. If you do a lot of disk/file operations, 
> the use of this unit is
> recommended over the one you use under Dos.
> graph Is an implementation of Borlands graph unit, which works on the 
> Linux console. Its implementation
> is as complete as on the other platforms (it shares the same code). It 
> uses the
> libvga and libvgagl graphics libraries, so you need these installed 
> for this unit to work. Also,
> programs using this library need to be run as root, or setuid root, 
> and hence are a potential
> security risk.
> 100
> CHAPTER 9. UNITS THAT COME WITH FREE PASCAL
> ports This implements the various port[] constructs. These are 
> provided for compatibility only,
> and it is not recommended to use them extensively. Programs using this 
> construct must be run
> as ruit or setuid root, and are a serious security risk on your system.
> 9.5 Under OS/2
> doscalls interface to doscalls.dll.
> dive interface to dive.dll
> emx provides access to the EMX extender.
> pm* interface units for the program manager functions.
> viocalls interface to viocalls.dll screen handling library.
> moucalls interface to moucalls.dll mouse handling library.
> kbdcalls interface to kbdcalls.dll keyboard handling library.
> moncalls interface to moncalls.dll monitoring handling library.
> 9.6 Unit availability
> Standard unit availability for each of the supported platforms is 
> given in the FAQ / Knowledge base.
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

Re: [UOPL-Architect] how design uopl gui applications

[Richard B W. <rb...@us...>]

When I tried to use this technique, the component compiled OK but I got an
access violation when I tried to install the component.  This is what I
expected. I believe that this means if UOPL starts from anything below
TComponent, it will not be possible to place the UOPL components on the
component palette.

Here is what I did.

1. I copied a Classes into a new unit called MyClasses
2. In MyClasses, I changed the ancestor of TComponent from TPersistent to
TInterfacedPersistent.
3. I changed the declaration of QueryInterface to override the declaration
in TInterfacedPersistent.

before
    function QueryInterface(const IID: TGUID; out Obj): HResult; virtual;
stdcall;
after
    function QueryInterface(const IID: TGUID; out Obj): HResult; override;
stdcall;

4. I created a component in a new unit that used the version of TComponent
in MyClasses.

Here is a copy of that unit.

unit ExperimentUnit;

interface

uses Classes, MyClasses;

type
  TExperimentComponent = class(TComponent)
  private
    FInt1: integer;
    procedure SetInt1(const Value: integer);
  published
    property Int1: integer read FInt1 write SetInt1;
  end;

procedure Register;

implementation

procedure Register;
begin
  Classes.RegisterComponents('Experiments',
    [Classes.TComponentClass(TExperimentComponent)]);
end;

{ TExperimentComponent }

procedure TExperimentComponent.SetInt1(const Value: integer);
begin
  FInt1 := Value;
end;

end.

Richard B. Winston
rb...@us...
http://water.usgs.gov/nrp/gwsoftware/
703-648-5988
on Fridays: 301 474-2762


                                                                                                                                      
                      "Dennis Landi"                                                                                                  
                      <de...@de...>               To:       <uop...@li...>                         
                      Sent by:                               cc:                                                                      
                      uop...@li...        Subject:  Re: [UOPL-Architect] how design uopl gui applications          
                      ceforge.net                                                                                                     
                                                                                                                                      
                                                                                                                                      
                      12/03/2004 01:48 PM                                                                                             
                      Please respond to                                                                                               
                      uopl-architect                                                                                                  
                                                                                                                                      
                                                                                                                                      




Re: the tInterfacedPersistent -->> tInterfacedComponent descendants being
registerable.

It will be interesting to see if a tInterfacedComponent replica of the
TComponent interface is registerable.

I don't see why it wouldn't be...  It will be an easy enough experiment to
run.

You would simply have to typecast it in the Registration proc.

The registration syntax would be:

  RegisterComponents('MyComponentPage',[tComponentClass(TMyComponent)]);

The interfaces of both artifacts would have to match; and if so, the IDE
registration mechanism probably won't notice.

This means that would have to hack the original source of tComponent; and
clone a tInterfaceComponent version; which we would probably have to only
be
able to distribute as a DCU...  But, I don't see that as a show-stopper.

If the technique works, then we can actually introduce it to the delphi
community, as it will allow them to unify artificacts at the component
level, which will come in really handy for things like plug-ins.



Dennis Landi
Allied Data, Inc.
800 204 2722
http://www.dennislandi.com




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
UOPL-architect mailing list
UOP...@li...
https://lists.sourceforge.net/lists/listinfo/uopl-architect

Re: [UOPL-Architect] how design uopl gui applications

[Thomas M. <tm...@bs...>]

Cool!!!   So now this is one less issue.  FPC does support interfaces 
and we are going
to initially target D7.  I think where possible, we should make it D2005 
friendly, but not
a high priority.

So with that solved, we are down to

#1  - Start with TObject.
#2  - Use same Class Names but use unit names like    uoplClass.pas
        (like qClass.pas for QT)
#3 -  We need to come up with a folder hierarchy.  I am not thrilled with
         the one FPC and Lazarus use.  I do like the one Delphi uses.  What
         do you all think of this.


uoplSource
    rtl
       uoplClass.pas
       uoplClassDWin.inc
       uoplClassFPWin.inc
       uoplClassFPGTK.inc
       uoplClassFPColbal.inc
    uopl
       uoplDB.pas
       uoplDBDWin.inc
       uoplDBFPWin.inc
       uoplDBFPGTK.inc
       uoplDBFPColbal.inc

I don't have a problem with having one include file with IfDef in it for
a particular OS and library.  So we would have one Win include.  For
the GTK interface, FP has a different include for each OS.

"D" - Delphi
"FP" - FreePascal
GTK - GTK cross OS library (Qt replacement) for Linux
Cobalt - Mac native Library

Comments???

Dennis Landi wrote:

>OK.
>
>I just had a look at the D7 implementations of tInterfacedPersisent and
>tComponent.  There have been quite a few changes since D5.
>
>TComponent and TInterfacedPersistent are declared, respectively:
>
>TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)
>
>and
>
>TInterfacedPersistent = class(TPersistent, IInterface)
>
>The definition of IInterface is
>
>  IInterface = interface
>    ['{00000000-0000-0000-C000-000000000046}']
>    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
>    function _AddRef: Integer; stdcall;
>    function _Release: Integer; stdcall;
>  end;
>
>IOW, both classes have functional parity in regard to the QueryInterface
>functionality (They share IInterface).
>
>We simply need to duplicate these on the FreePascal side. (This is assuming
>the FP support interfaces at all, otherwise its all moot).
>
>We can leave the choice up to individual developers wether or not to descend
>from TInterfacedPersistent or TPersistent, we should just alert them to the
>benefit of using TInterfacedPersistent.  If they descend from tComponent,
>then they automatically get the "IInterface" functionality for free...
>
>So you get all this for free, if you use D7 as the "porting target".
>(Another issue, I suppose).
>
>Dennis Landi
>Allied Data, Inc.
>800 204 2722
>http://www.dennislandi.com
>
>
>
>----- Original Message ----- 
>From: "Dennis Landi" <de...@de...>
>To: <uop...@li...>
>Sent: Tuesday, December 07, 2004 1:02 PM
>Subject: Re: [UOPL-Architect] how design uopl gui applications
>
>
>  
>
>>    
>>
>>>True, but I think the point that was trying to be made is that these
>>>private variables often
>>>get surfaced as Public properties.
>>>      
>>>
>>You would do that in descendants.
>>
>>That has nothing to do with the TComponentClass classtype which is the
>>typecast, and all the streaming mechanism sees.
>>
>>
>>Dennis Landi
>>Allied Data, Inc.
>>800 204 2722
>>http://www.dennislandi.com
>>----- Original Message ----- 
>>From: "Thomas Miller" <tm...@bs...>
>>To: <uop...@li...>
>>Sent: Tuesday, December 07, 2004 12:24 PM
>>Subject: Re: [UOPL-Architect] how design uopl gui applications
>>
>>
>>  We could have both Owner and
>>    
>>
>>>OwnerInterface as
>>>a property or function.
>>>
>>>I think the sooner we work some of these little detail out and can start
>>>the CVS tree,
>>>the better.  I will continue working on website stuff for you.
>>>
>>>Dennis Landi wrote:
>>>
>>>      
>>>
>>>>>By the way, couldn't we have both an FOwner and FOwnerInterface?
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>Private fields shouldn't interfere with the RTTI streaming system at
>>>>        
>>>>
>all.
>  
>
>>I
>>    
>>
>>>>doubt its an issue, but the experiment needs to happen.
>>>>
>>>>Three or four years ago I created my own tInterfacedComponent.  I'll
>>>>        
>>>>
>see
>  
>
>>if
>>    
>>
>>>>I can find it.
>>>>
>>>>Dennis Landi
>>>>Allied Data, Inc.
>>>>800 204 2722
>>>>http://www.dennislandi.com
>>>>
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>SF email is sponsored by - The IT Product Guide
>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>        
>>>>
>users.
>  
>
>>>>Discover which products truly live up to the hype. Start reading now.
>>>>http://productguide.itmanagersjournal.com/
>>>>_______________________________________________
>>>>UOPL-architect mailing list
>>>>UOP...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>-- 
>>>Thomas Miller
>>>Wash DC Delphi SIG Chairperson
>>>Delphi Client/Server Certified Developer
>>>BSS Accounting & Distribution Software
>>>BSS Enterprise Accounting FrameWork
>>>
>>>http://www.bss-software.com
>>>http://www.cpcug.org/user/delphi/index.html
>>>https://sourceforge.net/projects/uopl/
>>>http://sourceforge.net/projects/dbexpressplus
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>Discover which products truly live up to the hype. Start reading now.
>>>http://productguide.itmanagersjournal.com/
>>>_______________________________________________
>>>UOPL-architect mailing list
>>>UOP...@li...
>>>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>>>      
>>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>UOPL-architect mailing list
>>UOP...@li...
>>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>>    
>>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>  
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

Re: [UOPL-Architect] how design uopl gui applications

[Thomas M. <tm...@bs...>]

Dennis Landi wrote:

>Can anyone tell me if these declarations
>
>TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)
>  
>
Yes

>and
>
>TInterfacedPersistent = class(TPersistent, IInterface)
>  
>

Yes

>
>- are also present in Delphi 6?  I don't have D6 installed at the moment.
>
>
>
>Dennis Landi
>Allied Data, Inc.
>800 204 2722
>http://www.dennislandi.com
>
>
>----- Original Message ----- 
>From: "Dennis Landi" <de...@de...>
>To: <uop...@li...>
>Sent: Tuesday, December 07, 2004 1:44 PM
>Subject: Re: [UOPL-Architect] how design uopl gui applications
>
>
>  
>
>>OK.
>>
>>I just had a look at the D7 implementations of tInterfacedPersisent and
>>tComponent.  There have been quite a few changes since D5.
>>
>>TComponent and TInterfacedPersistent are declared, respectively:
>>
>>TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)
>>
>>and
>>
>>TInterfacedPersistent = class(TPersistent, IInterface)
>>
>>The definition of IInterface is
>>
>>  IInterface = interface
>>    ['{00000000-0000-0000-C000-000000000046}']
>>    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
>>    function _AddRef: Integer; stdcall;
>>    function _Release: Integer; stdcall;
>>  end;
>>
>>IOW, both classes have functional parity in regard to the QueryInterface
>>functionality (They share IInterface).
>>
>>We simply need to duplicate these on the FreePascal side. (This is
>>    
>>
>assuming
>  
>
>>the FP support interfaces at all, otherwise its all moot).
>>
>>We can leave the choice up to individual developers wether or not to
>>    
>>
>descend
>  
>
>>from TInterfacedPersistent or TPersistent, we should just alert them to
>>    
>>
>the
>  
>
>>benefit of using TInterfacedPersistent.  If they descend from tComponent,
>>then they automatically get the "IInterface" functionality for free...
>>
>>So you get all this for free, if you use D7 as the "porting target".
>>(Another issue, I suppose).
>>
>>Dennis Landi
>>Allied Data, Inc.
>>800 204 2722
>>http://www.dennislandi.com
>>
>>
>>
>>----- Original Message ----- 
>>From: "Dennis Landi" <de...@de...>
>>To: <uop...@li...>
>>Sent: Tuesday, December 07, 2004 1:02 PM
>>Subject: Re: [UOPL-Architect] how design uopl gui applications
>>
>>
>>    
>>
>>>      
>>>
>>>>True, but I think the point that was trying to be made is that these
>>>>private variables often
>>>>get surfaced as Public properties.
>>>>        
>>>>
>>>You would do that in descendants.
>>>
>>>That has nothing to do with the TComponentClass classtype which is the
>>>typecast, and all the streaming mechanism sees.
>>>
>>>
>>>Dennis Landi
>>>Allied Data, Inc.
>>>800 204 2722
>>>http://www.dennislandi.com
>>>----- Original Message ----- 
>>>From: "Thomas Miller" <tm...@bs...>
>>>To: <uop...@li...>
>>>Sent: Tuesday, December 07, 2004 12:24 PM
>>>Subject: Re: [UOPL-Architect] how design uopl gui applications
>>>
>>>
>>>  We could have both Owner and
>>>      
>>>
>>>>OwnerInterface as
>>>>a property or function.
>>>>
>>>>I think the sooner we work some of these little detail out and can
>>>>        
>>>>
>start
>  
>
>>>>the CVS tree,
>>>>the better.  I will continue working on website stuff for you.
>>>>
>>>>Dennis Landi wrote:
>>>>
>>>>        
>>>>
>>>>>>By the way, couldn't we have both an FOwner and FOwnerInterface?
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>Private fields shouldn't interfere with the RTTI streaming system at
>>>>>          
>>>>>
>>all.
>>    
>>
>>>I
>>>      
>>>
>>>>>doubt its an issue, but the experiment needs to happen.
>>>>>
>>>>>Three or four years ago I created my own tInterfacedComponent.  I'll
>>>>>          
>>>>>
>>see
>>    
>>
>>>if
>>>      
>>>
>>>>>I can find it.
>>>>>
>>>>>Dennis Landi
>>>>>Allied Data, Inc.
>>>>>800 204 2722
>>>>>http://www.dennislandi.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>SF email is sponsored by - The IT Product Guide
>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>          
>>>>>
>>users.
>>    
>>
>>>>>Discover which products truly live up to the hype. Start reading now.
>>>>>http://productguide.itmanagersjournal.com/
>>>>>_______________________________________________
>>>>>UOPL-architect mailing list
>>>>>UOP...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>-- 
>>>>Thomas Miller
>>>>Wash DC Delphi SIG Chairperson
>>>>Delphi Client/Server Certified Developer
>>>>BSS Accounting & Distribution Software
>>>>BSS Enterprise Accounting FrameWork
>>>>
>>>>http://www.bss-software.com
>>>>http://www.cpcug.org/user/delphi/index.html
>>>>https://sourceforge.net/projects/uopl/
>>>>http://sourceforge.net/projects/dbexpressplus
>>>>
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>SF email is sponsored by - The IT Product Guide
>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>        
>>>>
>users.
>  
>
>>>>Discover which products truly live up to the hype. Start reading now.
>>>>http://productguide.itmanagersjournal.com/
>>>>_______________________________________________
>>>>UOPL-architect mailing list
>>>>UOP...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>>>>        
>>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>Discover which products truly live up to the hype. Start reading now.
>>>http://productguide.itmanagersjournal.com/
>>>_______________________________________________
>>>UOPL-architect mailing list
>>>UOP...@li...
>>>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>>>      
>>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>UOPL-architect mailing list
>>UOP...@li...
>>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>>    
>>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>  
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

Re: [UOPL-Architect] how design uopl gui applications

[Dennis L. <de...@de...>]

Can anyone tell me if these declarations

TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)

and

TInterfacedPersistent = class(TPersistent, IInterface)


- are also present in Delphi 6?  I don't have D6 installed at the moment.



Dennis Landi
Allied Data, Inc.
800 204 2722
http://www.dennislandi.com


----- Original Message ----- 
From: "Dennis Landi" <de...@de...>
To: <uop...@li...>
Sent: Tuesday, December 07, 2004 1:44 PM
Subject: Re: [UOPL-Architect] how design uopl gui applications


> OK.
>
> I just had a look at the D7 implementations of tInterfacedPersisent and
> tComponent.  There have been quite a few changes since D5.
>
> TComponent and TInterfacedPersistent are declared, respectively:
>
> TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)
>
> and
>
> TInterfacedPersistent = class(TPersistent, IInterface)
>
> The definition of IInterface is
>
>   IInterface = interface
>     ['{00000000-0000-0000-C000-000000000046}']
>     function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
>     function _AddRef: Integer; stdcall;
>     function _Release: Integer; stdcall;
>   end;
>
> IOW, both classes have functional parity in regard to the QueryInterface
> functionality (They share IInterface).
>
> We simply need to duplicate these on the FreePascal side. (This is
assuming
> the FP support interfaces at all, otherwise its all moot).
>
> We can leave the choice up to individual developers wether or not to
descend
> from TInterfacedPersistent or TPersistent, we should just alert them to
the
> benefit of using TInterfacedPersistent.  If they descend from tComponent,
> then they automatically get the "IInterface" functionality for free...
>
> So you get all this for free, if you use D7 as the "porting target".
> (Another issue, I suppose).
>
> Dennis Landi
> Allied Data, Inc.
> 800 204 2722
> http://www.dennislandi.com
>
>
>
> ----- Original Message ----- 
> From: "Dennis Landi" <de...@de...>
> To: <uop...@li...>
> Sent: Tuesday, December 07, 2004 1:02 PM
> Subject: Re: [UOPL-Architect] how design uopl gui applications
>
>
> >
> >
> > > True, but I think the point that was trying to be made is that these
> > > private variables often
> > > get surfaced as Public properties.
> >
> > You would do that in descendants.
> >
> > That has nothing to do with the TComponentClass classtype which is the
> > typecast, and all the streaming mechanism sees.
> >
> >
> > Dennis Landi
> > Allied Data, Inc.
> > 800 204 2722
> > http://www.dennislandi.com
> > ----- Original Message ----- 
> > From: "Thomas Miller" <tm...@bs...>
> > To: <uop...@li...>
> > Sent: Tuesday, December 07, 2004 12:24 PM
> > Subject: Re: [UOPL-Architect] how design uopl gui applications
> >
> >
> >   We could have both Owner and
> > > OwnerInterface as
> > > a property or function.
> > >
> > > I think the sooner we work some of these little detail out and can
start
> > > the CVS tree,
> > > the better.  I will continue working on website stuff for you.
> > >
> > > Dennis Landi wrote:
> > >
> > > >>By the way, couldn't we have both an FOwner and FOwnerInterface?
> > > >>
> > > >>
> > > >>
> > > >
> > > >Private fields shouldn't interfere with the RTTI streaming system at
> all.
> > I
> > > >doubt its an issue, but the experiment needs to happen.
> > > >
> > > >Three or four years ago I created my own tInterfacedComponent.  I'll
> see
> > if
> > > >I can find it.
> > > >
> > > >Dennis Landi
> > > >Allied Data, Inc.
> > > >800 204 2722
> > > >http://www.dennislandi.com
> > > >
> > > >
> > > >
> > > >
> > > >-------------------------------------------------------
> > > >SF email is sponsored by - The IT Product Guide
> > > >Read honest & candid reviews on hundreds of IT Products from real
> users.
> > > >Discover which products truly live up to the hype. Start reading now.
> > > >http://productguide.itmanagersjournal.com/
> > > >_______________________________________________
> > > >UOPL-architect mailing list
> > > >UOP...@li...
> > > >https://lists.sourceforge.net/lists/listinfo/uopl-architect
> > > >
> > > >
> > > >
> > >
> > > -- 
> > > Thomas Miller
> > > Wash DC Delphi SIG Chairperson
> > > Delphi Client/Server Certified Developer
> > > BSS Accounting & Distribution Software
> > > BSS Enterprise Accounting FrameWork
> > >
> > > http://www.bss-software.com
> > > http://www.cpcug.org/user/delphi/index.html
> > > https://sourceforge.net/projects/uopl/
> > > http://sourceforge.net/projects/dbexpressplus
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF email is sponsored by - The IT Product Guide
> > > Read honest & candid reviews on hundreds of IT Products from real
users.
> > > Discover which products truly live up to the hype. Start reading now.
> > > http://productguide.itmanagersjournal.com/
> > > _______________________________________________
> > > UOPL-architect mailing list
> > > UOP...@li...
> > > https://lists.sourceforge.net/lists/listinfo/uopl-architect
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > UOPL-architect mailing list
> > UOP...@li...
> > https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> UOPL-architect mailing list
> UOP...@li...
> https://lists.sourceforge.net/lists/listinfo/uopl-architect

Re: [UOPL-Architect] how design uopl gui applications

[Dennis L. <de...@de...>]

OK.

I just had a look at the D7 implementations of tInterfacedPersisent and
tComponent.  There have been quite a few changes since D5.

TComponent and TInterfacedPersistent are declared, respectively:

TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)

and

TInterfacedPersistent = class(TPersistent, IInterface)

The definition of IInterface is

  IInterface = interface
    ['{00000000-0000-0000-C000-000000000046}']
    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
    function _AddRef: Integer; stdcall;
    function _Release: Integer; stdcall;
  end;

IOW, both classes have functional parity in regard to the QueryInterface
functionality (They share IInterface).

We simply need to duplicate these on the FreePascal side. (This is assuming
the FP support interfaces at all, otherwise its all moot).

We can leave the choice up to individual developers wether or not to descend
from TInterfacedPersistent or TPersistent, we should just alert them to the
benefit of using TInterfacedPersistent.  If they descend from tComponent,
then they automatically get the "IInterface" functionality for free...

So you get all this for free, if you use D7 as the "porting target".
(Another issue, I suppose).

Dennis Landi
Allied Data, Inc.
800 204 2722
http://www.dennislandi.com



----- Original Message ----- 
From: "Dennis Landi" <de...@de...>
To: <uop...@li...>
Sent: Tuesday, December 07, 2004 1:02 PM
Subject: Re: [UOPL-Architect] how design uopl gui applications


>
>
> > True, but I think the point that was trying to be made is that these
> > private variables often
> > get surfaced as Public properties.
>
> You would do that in descendants.
>
> That has nothing to do with the TComponentClass classtype which is the
> typecast, and all the streaming mechanism sees.
>
>
> Dennis Landi
> Allied Data, Inc.
> 800 204 2722
> http://www.dennislandi.com
> ----- Original Message ----- 
> From: "Thomas Miller" <tm...@bs...>
> To: <uop...@li...>
> Sent: Tuesday, December 07, 2004 12:24 PM
> Subject: Re: [UOPL-Architect] how design uopl gui applications
>
>
>   We could have both Owner and
> > OwnerInterface as
> > a property or function.
> >
> > I think the sooner we work some of these little detail out and can start
> > the CVS tree,
> > the better.  I will continue working on website stuff for you.
> >
> > Dennis Landi wrote:
> >
> > >>By the way, couldn't we have both an FOwner and FOwnerInterface?
> > >>
> > >>
> > >>
> > >
> > >Private fields shouldn't interfere with the RTTI streaming system at
all.
> I
> > >doubt its an issue, but the experiment needs to happen.
> > >
> > >Three or four years ago I created my own tInterfacedComponent.  I'll
see
> if
> > >I can find it.
> > >
> > >Dennis Landi
> > >Allied Data, Inc.
> > >800 204 2722
> > >http://www.dennislandi.com
> > >
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >SF email is sponsored by - The IT Product Guide
> > >Read honest & candid reviews on hundreds of IT Products from real
users.
> > >Discover which products truly live up to the hype. Start reading now.
> > >http://productguide.itmanagersjournal.com/
> > >_______________________________________________
> > >UOPL-architect mailing list
> > >UOP...@li...
> > >https://lists.sourceforge.net/lists/listinfo/uopl-architect
> > >
> > >
> > >
> >
> > -- 
> > Thomas Miller
> > Wash DC Delphi SIG Chairperson
> > Delphi Client/Server Certified Developer
> > BSS Accounting & Distribution Software
> > BSS Enterprise Accounting FrameWork
> >
> > http://www.bss-software.com
> > http://www.cpcug.org/user/delphi/index.html
> > https://sourceforge.net/projects/uopl/
> > http://sourceforge.net/projects/dbexpressplus
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > UOPL-architect mailing list
> > UOP...@li...
> > https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> UOPL-architect mailing list
> UOP...@li...
> https://lists.sourceforge.net/lists/listinfo/uopl-architect

Re: [UOPL-Architect] how design uopl gui applications

[Dennis L. <de...@de...>]

> True, but I think the point that was trying to be made is that these
> private variables often
> get surfaced as Public properties.

You would do that in descendants.

That has nothing to do with the TComponentClass classtype which is the
typecast, and all the streaming mechanism sees.


Dennis Landi
Allied Data, Inc.
800 204 2722
http://www.dennislandi.com
----- Original Message ----- 
From: "Thomas Miller" <tm...@bs...>
To: <uop...@li...>
Sent: Tuesday, December 07, 2004 12:24 PM
Subject: Re: [UOPL-Architect] how design uopl gui applications


  We could have both Owner and
> OwnerInterface as
> a property or function.
>
> I think the sooner we work some of these little detail out and can start
> the CVS tree,
> the better.  I will continue working on website stuff for you.
>
> Dennis Landi wrote:
>
> >>By the way, couldn't we have both an FOwner and FOwnerInterface?
> >>
> >>
> >>
> >
> >Private fields shouldn't interfere with the RTTI streaming system at all.
I
> >doubt its an issue, but the experiment needs to happen.
> >
> >Three or four years ago I created my own tInterfacedComponent.  I'll see
if
> >I can find it.
> >
> >Dennis Landi
> >Allied Data, Inc.
> >800 204 2722
> >http://www.dennislandi.com
> >
> >
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from real users.
> >Discover which products truly live up to the hype. Start reading now.
> >http://productguide.itmanagersjournal.com/
> >_______________________________________________
> >UOPL-architect mailing list
> >UOP...@li...
> >https://lists.sourceforge.net/lists/listinfo/uopl-architect
> >
> >
> >
>
> -- 
> Thomas Miller
> Wash DC Delphi SIG Chairperson
> Delphi Client/Server Certified Developer
> BSS Accounting & Distribution Software
> BSS Enterprise Accounting FrameWork
>
> http://www.bss-software.com
> http://www.cpcug.org/user/delphi/index.html
> https://sourceforge.net/projects/uopl/
> http://sourceforge.net/projects/dbexpressplus
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> UOPL-architect mailing list
> UOP...@li...
> https://lists.sourceforge.net/lists/listinfo/uopl-architect

Re: [UOPL-Architect] how design uopl gui applications

[Thomas M. <tm...@bs...>]

True, but I think the point that was trying to be made is that these 
private variables often
get surfaced as Public properties.  We could have both Owner and 
OwnerInterface as
a property or function. 

I think the sooner we work some of these little detail out and can start 
the CVS tree,
the better.  I will continue working on website stuff for you.

Dennis Landi wrote:

>>By the way, couldn't we have both an FOwner and FOwnerInterface?
>>
>>    
>>
>
>Private fields shouldn't interfere with the RTTI streaming system at all.  I
>doubt its an issue, but the experiment needs to happen.
>
>Three or four years ago I created my own tInterfacedComponent.  I'll see if
>I can find it.
>
>Dennis Landi
>Allied Data, Inc.
>800 204 2722
>http://www.dennislandi.com
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>  
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

Re: [UOPL-Architect] how design uopl gui applications

[Dennis L. <de...@de...>]

> By the way, couldn't we have both an FOwner and FOwnerInterface?
>

Private fields shouldn't interfere with the RTTI streaming system at all.  I
doubt its an issue, but the experiment needs to happen.

Three or four years ago I created my own tInterfacedComponent.  I'll see if
I can find it.

Dennis Landi
Allied Data, Inc.
800 204 2722
http://www.dennislandi.com

Re: [UOPL-Architect] how design uopl gui applications

[Thomas M. <tm...@bs...>]

Dennis and Richard,

Can you guys take the lead on experimenting with all of this stuff. 

Issues List:

#1)  To make the entire system UNICODE friendly, we will need to probably
start from TObject because we need to update the Exception class, which 
inherits
from TObject.

#2)  Some of the changes we are talking about, like 
TInterfacedPersistent, will that
prevent the IDE's from using our new library.

By the way, couldn't we have both an FOwner and FOwnerInterface?

Richard B Winston wrote:

>That would be an interesting experiment.  TInterfacedPersistent has a
>private field
>
>FOwnerInterface: IInterface;
>
>Its possible that the private field will mess up the typecasting mechanism.
>When you typecast, the compiler may expect FOwner, the first private field
>in TComponent to
>be in the position that is really occupied by FOwnerInterface.
>
>Richard B. Winston
>rb...@us...
>http://water.usgs.gov/nrp/gwsoftware/
>703-648-5988
>on Fridays: 301 474-2762
>
>  
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

[UOPL-Architect] Back ground work

[Thomas M. <tm...@bs...>]

We still have lots of back ground work to do for the project. Here is 
some stuff
to read

http://www.freepascal.org/docs.html

User.pdf

Chapter 9
Units that come with Free Pascal
Here we list the units that come with the Free Pascal distribution. 
Since there is a difference in the
supplied units per operating system, we first describe the generic ones, 
then describe those which are
operating specific.
9.1 Standard units
The following units are standard and are meant to be ported to all 
supported platforms by Free Pascal.
A brief description of each unit is also given.
crt This unit is similar to the unit of the same name of Turbo Pascal. 
It implements writing to the
console in color, moving the text cursor around and reading from the 
keyboard.
dos This unit provides basic routines for accessing the operating 
system. This includes file searching,
environment variables access, getting the operating system version, 
getting and setting
the system time. It is to note that some of these routines are 
duplicated in functionality in the
sysutils unit.
getopts This unit gives you the GNU getopts command-line arguments 
handling mechanism. It
also supports long options.
graph This unit provides basic graphics handling, with routines to draw 
lines on the screen, display
texts etc. It provides the same functions as the Turbo Pascal unit.
keyboard provides basic keyboard handling routines in a platform 
independent way, and supports
writing custom drivers.
math This unit contains common mathematical routines (trigonometric 
functions, logarithms, etc.)
as well as more complex ones (summations of arrays, normalization 
functions, etc.).
mmx This unit provides support for mmx extensions in your code.
mouse provides basic mouse handling routines in a platform independent 
way, and supports writing
custom drivers.
objects This unit provides the base object for standard Turbo Pascal 
objects. It also implements File
and Memory stream objects, as well as sorted and non-sorted collections, 
and string streams.
objpas is used for Delphi compatibility; you should never load this unit 
explicitly; it is automatically
loaded if you request Delphi mode.
99
CHAPTER 9. UNITS THAT COME WITH FREE PASCAL
printer This unit provides all you need for rudimentary access to the 
printer using standard I/O
routines.
sockets This gives the programmer access to sockets and TCP/IP programming.
strings This unit provides basic string handling routines for the pchar 
type, comparable to similar
routines in standard C libraries.
system This unit is available for all supported platforms, even though 
the unit name may be different
(e.g : syslinux, sysos2). It includes among others, basic file I/O 
routines, memory management
routines, all compiler helper routines, and directory services routines.
sysutils is an alternative implementation of the sysutils unit of 
Delphi. It includes file I/O access
routines which takes care of file locking, date and string handling 
routines, file search, date
and string conversion routines.
typinfo Provides functions to acces Run-Time Type Information, just like 
Delphi.
video provides basic screen handling in a platform independent way, and 
supports writing custom
drivers.
9.2 Under DOS
emu387 This unit provides support for the coprocessor emulator.
go32 This unit provides access to possibilities of the GO32 DOS extender.
9.3 UnderWindows
wincrt This implements a console in a standard GUI window, contrary to 
the crt unit which is for
the Windows console only.
Windows This unit provides access to al Win32 API calls. Effort has been 
taken to make sure that
it is compatible to the Delphi version of this unit, so code for Delphi 
is easily ported to Free
Pascal.
opengl provides access to the low-level opengl functions in WINDOWS.
winmouse provides access to the mouse in WINDOWS.
ole2 provides access to the OLE capabilities of WINDOWS.
winsock provides acces to the WINDOWS sockets API Winsock.
9.4 Under Linux
linux This unit provides access to the LINUX operating system. It 
provides most file and I/O handling
routines that you may need. It implements most of the standard C library 
constructs that you
will find on a Unix system. If you do a lot of disk/file operations, the 
use of this unit is
recommended over the one you use under Dos.
graph Is an implementation of Borlands graph unit, which works on the 
Linux console. Its implementation
is as complete as on the other platforms (it shares the same code). It 
uses the
libvga and libvgagl graphics libraries, so you need these installed for 
this unit to work. Also,
programs using this library need to be run as root, or setuid root, and 
hence are a potential
security risk.
100
CHAPTER 9. UNITS THAT COME WITH FREE PASCAL
ports This implements the various port[] constructs. These are provided 
for compatibility only,
and it is not recommended to use them extensively. Programs using this 
construct must be run
as ruit or setuid root, and are a serious security risk on your system.
9.5 Under OS/2
doscalls interface to doscalls.dll.
dive interface to dive.dll
emx provides access to the EMX extender.
pm* interface units for the program manager functions.
viocalls interface to viocalls.dll screen handling library.
moucalls interface to moucalls.dll mouse handling library.
kbdcalls interface to kbdcalls.dll keyboard handling library.
moncalls interface to moncalls.dll monitoring handling library.
9.6 Unit availability
Standard unit availability for each of the supported platforms is given 
in the FAQ / Knowledge base.

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

Re: [UOPL-Architect] how design uopl gui applications

[Richard B W. <rb...@us...>]

That would be an interesting experiment.  TInterfacedPersistent has a
private field

FOwnerInterface: IInterface;

Its possible that the private field will mess up the typecasting mechanism.
When you typecast, the compiler may expect FOwner, the first private field
in TComponent to
be in the position that is really occupied by FOwnerInterface.

Richard B. Winston
rb...@us...
http://water.usgs.gov/nrp/gwsoftware/
703-648-5988
on Fridays: 301 474-2762


|---------+------------------------------------------>
|         |           "Dennis Landi"                 |
|         |           <de...@de...>       |
|         |           Sent by:                       |
|         |           uop...@li...|
|         |           ceforge.net                    |
|         |                                          |
|         |                                          |
|         |           12/03/2004 01:48 PM            |
|         |           Please respond to              |
|         |           uopl-architect                 |
|         |                                          |
|---------+------------------------------------------>
  >--------------------------------------------------------------------------------------------------------|
  |                                                                                                        |
  |       To:       <uop...@li...>                                                 |
  |       cc:                                                                                              |
  |       Subject:  Re: [UOPL-Architect] how design uopl gui applications                                  |
  >--------------------------------------------------------------------------------------------------------|




Re: the tInterfacedPersistent -->> tInterfacedComponent descendants being
registerable.

It will be interesting to see if a tInterfacedComponent replica of the
TComponent interface is registerable.

I don't see why it wouldn't be...  It will be an easy enough experiment to
run.

You would simply have to typecast it in the Registration proc.

The registration syntax would be:

  RegisterComponents('MyComponentPage',[tComponentClass(TMyComponent)]);

The interfaces of both artifacts would have to match; and if so, the IDE
registration mechanism probably won't notice.

This means that would have to hack the original source of tComponent; and
clone a tInterfaceComponent version; which we would probably have to only
be
able to distribute as a DCU...  But, I don't see that as a show-stopper.

If the technique works, then we can actually introduce it to the delphi
community, as it will allow them to unify artificacts at the component
level, which will come in really handy for things like plug-ins.



Dennis Landi
Allied Data, Inc.
800 204 2722
http://www.dennislandi.com




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
UOPL-architect mailing list
UOP...@li...
https://lists.sourceforge.net/lists/listinfo/uopl-architect

Re: [UOPL-Architect] how design uopl gui applications

[Dennis L. <de...@de...>]

Re: the tInterfacedPersistent -->> tInterfacedComponent descendants being
registerable.

It will be interesting to see if a tInterfacedComponent replica of the
TComponent interface is registerable.

I don't see why it wouldn't be...  It will be an easy enough experiment to
run.

You would simply have to typecast it in the Registration proc.

The registration syntax would be:

  RegisterComponents('MyComponentPage',[tComponentClass(TMyComponent)]);

The interfaces of both artifacts would have to match; and if so, the IDE
registration mechanism probably won't notice.

This means that would have to hack the original source of tComponent; and
clone a tInterfaceComponent version; which we would probably have to only be
able to distribute as a DCU...  But, I don't see that as a show-stopper.

If the technique works, then we can actually introduce it to the delphi
community, as it will allow them to unify artificacts at the component
level, which will come in really handy for things like plug-ins.



Dennis Landi
Allied Data, Inc.
800 204 2722
http://www.dennislandi.com

Re: [UOPL-Architect] how design uopl gui applications

[Richard B W. <rb...@us...>]

Although both the VCL and CLX versions of TForm descend from an object
named TCustomForm, they actually diverge from one another at the level of
TComponent. (The VCL and CLX versions of TControl are declared in different
units.)

VCL
TForm -> TCustomForm -> TScrollingWinControl -> TWinControl -> TControl ->
TComponent -> TPersistent -> TObject

CLX
TForm -> TCustomForm -> TScrollingWidgetControl -> TFrameControl ->
TWidgetControl -> TControl -> TComponent -> TPersistent -> TObject

I don't have access to the source code of Delphi so I don't know for sure
whether the form designers for VCL and CLX are different but the VCL and
CLX versions of TForm are very different beasts.

Richard B. Winston
rb...@us...
http://water.usgs.gov/nrp/gwsoftware/
703-648-5988
on Fridays: 301 474-2762


|---------+------------------------------------------>
|         |           Thomas Miller                  |
|         |           <tm...@bs...>     |
|         |           Sent by:                       |
|         |           uop...@li...|
|         |           ceforge.net                    |
|         |                                          |
|         |                                          |
|         |           12/03/2004 01:03 PM            |
|         |           Please respond to              |
|         |           uopl-architect                 |
|         |                                          |
|---------+------------------------------------------>
  >--------------------------------------------------------------------------------------------------------|
  |                                                                                                        |
  |       To:       uop...@li...                                                   |
  |       cc:                                                                                              |
  |       Subject:  Re: [UOPL-Architect] how design uopl gui applications                                  |
  >--------------------------------------------------------------------------------------------------------|




Richard B Winston wrote:

<snip>

>You might object that CLX works and its TForm is not the same as the VCL
>TForm.  I suspect that the only reason the form designer for CLX works is
>because Borland created a new form designer to work with the CLX TForm.  I
>suspect that the two form designers (if that is really what is going on)
>share a lot of code and act the same way but they are not identical.  It
>might be worth looking at the CLX community project to see what is in
there
>that might be relevant to this question.
>
>
I am almost positive they are the same.  As long as the form descends
from TCustomForm, I would
expect that it will work.

Re: [UOPL-Architect] how design uopl gui applications

[Thomas M. <tm...@bs...>]

Richard B Winston wrote:

>You've talked about starting all your classes from TInterfacedPersistent
>rather than from TPersistent.  That means that the UOPL version of
>TComponent will not be the same as the VCL version of TComponent.  I think
>that opens up a whole can of worms.
>
>1. You would have to have a replacement for the Component Pallette to hold
>UOPL components.
>  
>
I didn't think of this.  After reading this, we might have to take the 
same tact as Kylix.  Each unit
name would start each uopl instead of "Q".

>2. The Delphi Form designer would not work because the UOPL version of
>TForm would not be the VCL TForm.  You would have to provide a replacement.
>  
>
Another good point.

>3. None of the VCL component editors would work either and you would have
>to provide replacements.
>  
>
I am not as worried about that as we can always use the Lazarus 
versions.  I haven't written a
few myself too.

>You might object that CLX works and its TForm is not the same as the VCL
>TForm.  I suspect that the only reason the form designer for CLX works is
>because Borland created a new form designer to work with the CLX TForm.  I
>suspect that the two form designers (if that is really what is going on)
>share a lot of code and act the same way but they are not identical.  It
>might be worth looking at the CLX community project to see what is in there
>that might be relevant to this question.
>  
>
I am almost positive they are the same.  As long as the form descends 
from TCustomForm, I would
expect that it will work.

>Richard B. Winston
>rb...@us...
>http://water.usgs.gov/nrp/gwsoftware/
>703-648-5988
>on Fridays: 301 474-2762
>
>
>|---------+------------------------------------------>
>|         |           Thomas Miller                  |
>|         |           <tm...@bs...>     |
>|         |           Sent by:                       |
>|         |           uop...@li...|
>|         |           ceforge.net                    |
>|         |                                          |
>|         |                                          |
>|         |           12/03/2004 11:55 AM            |
>|         |           Please respond to              |
>|         |           uopl-architect                 |
>|         |                                          |
>|---------+------------------------------------------>
>  >--------------------------------------------------------------------------------------------------------|
>  |                                                                                                        |
>  |       To:       uop...@li...                                                   |
>  |       cc:                                                                                              |
>  |       Subject:  Re: [UOPL-Architect] how design uopl gui applications                                  |
>  >--------------------------------------------------------------------------------------------------------|
>
>
>
>
>Vincent Snijders wrote:
>
>  
>
>>Do you it is possible to create uopl gui applications in the Delphi
>>form designer? How would you tackle this issue?
>>
>>    
>>
>The UOPL will be a third parth VCL in Delphi and the third party LCL in
>Lazarus.  You
>would use it like any other component in either IDE.
>
>--
>Thomas Miller
>Wash DC Delphi SIG Chairperson
>Delphi Client/Server Certified Developer
>BSS Accounting & Distribution Software
>BSS Enterprise Accounting FrameWork
>
>http://www.bss-software.com
>http://www.cpcug.org/user/delphi/index.html
>https://sourceforge.net/projects/uopl/
>http://sourceforge.net/projects/dbexpressplus
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>
>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>UOPL-architect mailing list
>UOP...@li...
>https://lists.sourceforge.net/lists/listinfo/uopl-architect
>
>  
>

-- 
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus

Re: [UOPL-Architect] how design uopl gui applications

[Richard B W. <rb...@us...>]

You've talked about starting all your classes from TInterfacedPersistent
rather than from TPersistent.  That means that the UOPL version of
TComponent will not be the same as the VCL version of TComponent.  I think
that opens up a whole can of worms.

1. You would have to have a replacement for the Component Pallette to hold
UOPL components.
2. The Delphi Form designer would not work because the UOPL version of
TForm would not be the VCL TForm.  You would have to provide a replacement.
3. None of the VCL component editors would work either and you would have
to provide replacements.

You might object that CLX works and its TForm is not the same as the VCL
TForm.  I suspect that the only reason the form designer for CLX works is
because Borland created a new form designer to work with the CLX TForm.  I
suspect that the two form designers (if that is really what is going on)
share a lot of code and act the same way but they are not identical.  It
might be worth looking at the CLX community project to see what is in there
that might be relevant to this question.

Richard B. Winston
rb...@us...
http://water.usgs.gov/nrp/gwsoftware/
703-648-5988
on Fridays: 301 474-2762


|---------+------------------------------------------>
|         |           Thomas Miller                  |
|         |           <tm...@bs...>     |
|         |           Sent by:                       |
|         |           uop...@li...|
|         |           ceforge.net                    |
|         |                                          |
|         |                                          |
|         |           12/03/2004 11:55 AM            |
|         |           Please respond to              |
|         |           uopl-architect                 |
|         |                                          |
|---------+------------------------------------------>
  >--------------------------------------------------------------------------------------------------------|
  |                                                                                                        |
  |       To:       uop...@li...                                                   |
  |       cc:                                                                                              |
  |       Subject:  Re: [UOPL-Architect] how design uopl gui applications                                  |
  >--------------------------------------------------------------------------------------------------------|




Vincent Snijders wrote:

> Do you it is possible to create uopl gui applications in the Delphi
> form designer? How would you tackle this issue?
>
The UOPL will be a third parth VCL in Delphi and the third party LCL in
Lazarus.  You
would use it like any other component in either IDE.

--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
UOPL-architect mailing list
UOP...@li...
https://lists.sourceforge.net/lists/listinfo/uopl-architect