BorlandTalk.com Forum Index BorlandTalk.com
Borland discussion newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Separating process from presentation and control
Goto page 1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi OO design
View previous topic :: View next topic  
Author Message
server
Guest





PostPosted: Fri Jan 27, 2006 9:48 pm    Post subject: Separating process from presentation and control Reply with quote



message unavailable
Back to top
Peter Morris [Droopy eyes
Guest





PostPosted: Fri Jan 27, 2006 9:48 pm    Post subject: Re: Separating process from presentation and control Reply with quote



Quote:
However, she has written an implementation, and that's what I was
referring
to.

Oh I see. I took the wrong double-meaning of the word "like" Smile
Back to top
David M
Guest





PostPosted: Sat Jan 28, 2006 3:52 am    Post subject: Re: interfaces questions Reply with quote



Quote:

Nor I.

Implementing an interface is a contract. It does not guarantee that any
other interface is also implemented--but it doesn't rule it out, either. You
just have to ask.

Isn't that what QueryInterface was provided for Wink


Cheers

David
Back to top
Jeremy
Guest





PostPosted: Sat Jan 28, 2006 7:11 am    Post subject: Re: Separating process from presentation and control Reply with quote

Thanks for pointing me to MVP. I'd seen this mentioned before, but somehow
couldn't help thinking it had something to do with the poster's
qualifications (g).

If I understand MVP's goal, it seems to be more than I want to do at the
moment. I don't mind if we need to rewrite the presentation layer stuff so
long as we don't have 2 code bases for the business logic. However, even
this simpler problem has proved to be too much for my little pea brain. It
sounds really simple -- just write some dlls and keep forms and dialogs out
of it, but the interactions begin to look like spaghetti. For the moment I
think I need to press on and get the functionality into final test and
production, and worry about this problem when the brain swelling goes down
and the toolset matures.

Jeremy

"Jeremy" <jeremy> wrote in message news:43d914ba$1 (AT) newsgroups (DOT) borland.com...
Quote:
I've got processes that run in windows, and I'd like to use this code
without modification to do the same thing in a web app. That means I
can't contaminate my process classes with gui stuff. On the other hand, I
don't want to duplicate common display functions (status, etc) in every
user-control screen. I do have onprogress event handlers. I'm talking here
about forms that show task-start decision info to the user and final
results summaries. So that leads me to some kind of UI mediator that
would be replaceable. A delphi one for windows apps, maybe a cold fusion
one for web apps.

Someone here has certainly addressed this issue; what answer did you come
up with?

Jeremy
Back to top
Graeme Geldenhuys
Guest





PostPosted: Sun Jan 29, 2006 12:06 pm    Post subject: Re: Interfaces Beginner Reply with quote

Joanna Carter [TeamB] wrote:
Quote:
You have to understand that Delphi interface, prior to .NET, use the COM
pattern, even if the interfaces are not for COM support.

Isn't this only for D5 and earlier. When Kylix was released, it used
the same technology as the Delphi 6 compiler. Kylix definately doesn't
have COM, and if I remeber correctly, Interfaces in D6 and up are not
bound to COM anymore. (I will see if I can find that link on BDN)

Regards,
- Graeme -
Back to top
Jim Cooper
Guest





PostPosted: Sun Jan 29, 2006 12:46 pm    Post subject: Re: Interfaces Beginner Reply with quote

Quote:
Interfaces in D6 and up are not bound to COM anymore.

That's not what she said Smile The *pattern* is that of COM interfaces. You can
override that, but it takes extra work. Compare that with the way interfaces
work in Java and .NET where they are a purer language feature.


Cheers,
Jim Cooper

_____________________________________________

Jim Cooper jcooper (AT) tabdee (DOT) ltd.uk
Skype : jim.cooper
Singapore mobile: +65 9345 0024
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Back to top
Dave Champion
Guest





PostPosted: Fri Feb 03, 2006 4:43 pm    Post subject: Re: interfaces questions Reply with quote

Quote:

I am working in C# at the minute, and that allows me to cast objects to
interfaces and back again, something Delphiites can only dream of.

Hi Joanna hows its going ? And thanks for your help in the past.


There are 2 points I'd like to make:-

1) There is a function in the Jcl library,
function GetImplementorOfInterface(const I: IInterface): TObject;
that does the casting from an interface to an object.
Code by Hallvard Vassbotn.

2) and in Delphi there is no need to implement an interface
using an object. See the Delphi demo qregister.dll.

one should not increase, beyond what is necessary, the number of entities required to explain anything - William of Occa

--- posted by geoForum on http://delphi.newswhat.com
Back to top
Andrea Raimondi
Guest





PostPosted: Sun Feb 12, 2006 1:16 am    Post subject: Re: A question for guru's ( About DB Forms) Reply with quote

First thing: IMHO, this message belongs to .oodesign group.
Short summary of the thread: the OP wants to dynamically
bind his forms to his datasets.
This is basically wrong, imho, unless the datasets are
surfacing an OPF.
Example code that was posted in the thread:
"
MainDM.QBirim.Locate(dgdataDBTableView1.Columns[0].DataBinding.FieldName,
mnuDbSearch.CurText, [loCaseInsensitive, loPartialKey]);

MainDM is my Datamodul
and QBirim is my Tadoquery

I want use a general definiton
MyFormQuery : TAdoquery


MainDM.XXXXXXXX.Locate(dgdataDBTableView1.Columns[0].DataBinding.FieldName,
mnuDbSearch.CurText, [loCaseInsensitive, loPartialKey]);

If my MyFormQuery is QBlabla this lines will be


MainDM.QBlabla.Locate(dgdataDBTableView1.Columns[0].DataBinding.FieldName,
mnuDbSearch.CurText, [loCaseInsensitive, loPartialKey]);
"

Ardahan wrote:
Quote:
What is your recommend for designing base DB form ? What is your method
doing that? I need a way.

I'm not usually doing "database forms", unless I'm using an OPF, where
this does make sense.

However, I'd go for one of these approaches:
1) Form parameters
2) Form inheritance

usually combined.

You could for example do something like this:

Type

TMyParamClass = class(TPersistent)
end;

TMyBaseParamForm = class(TForm)
public
procedure ShowModalParams(AParams : TMyParamClass);virtual;
end;

Now, your base form does only call ShowModal without doing anything
with params, but your derivative could look like this:

Type
TMyUsefulParams = class( TMyParamClass )
public
property IntProp : Integer;
property StrProp : String;
end;

TMyForm = class( TMyBaseParamForm )
public
procedure ShowModalParams(AParams : TMyParamClass);override;
end;

Now you implement your params settings(using a typecast) and
place the Inherited; keyword to call ShowModal.

You could then enhance the whole thing by using RTTI or a
Value Type Framework.

However, since I beleive this thread pertains to .oodesign group,
follow-up is set there.

Quote:
Thanks

HTH,

Quote:
Ardahan

Andrew
Back to top
Ardahan
Guest





PostPosted: Sun Feb 12, 2006 11:03 am    Post subject: Re: A question for guru's ( About DB Forms) Reply with quote

Thanks Andrew, I will watch my thread from here. If anybody can send me an
example project I will be happy.

Thanks for all persons because you are sharing your experiences with us.


"Andrea Raimondi" <rainaple (AT) tin (DOT) it>, haber iletisinde sunlari
yazdi:43ee7ff5$1 (AT) newsgroups (DOT) borland.com...
Quote:
First thing: IMHO, this message belongs to .oodesign group.
Short summary of the thread: the OP wants to dynamically
bind his forms to his datasets.
This is basically wrong, imho, unless the datasets are
surfacing an OPF.
Example code that was posted in the thread:
"
MainDM.QBirim.Locate(dgdataDBTableView1.Columns[0].DataBinding.FieldName,
mnuDbSearch.CurText, [loCaseInsensitive, loPartialKey]);

MainDM is my Datamodul
and QBirim is my Tadoquery

I want use a general definiton
MyFormQuery : TAdoquery


MainDM.XXXXXXXX.Locate(dgdataDBTableView1.Columns[0].DataBinding.FieldName,
mnuDbSearch.CurText, [loCaseInsensitive, loPartialKey]);

If my MyFormQuery is QBlabla this lines will be


MainDM.QBlabla.Locate(dgdataDBTableView1.Columns[0].DataBinding.FieldName,
mnuDbSearch.CurText, [loCaseInsensitive, loPartialKey]);
"

Ardahan wrote:
What is your recommend for designing base DB form ? What is your method
doing that? I need a way.

I'm not usually doing "database forms", unless I'm using an OPF, where
this does make sense.

However, I'd go for one of these approaches:
1) Form parameters
2) Form inheritance

usually combined.

You could for example do something like this:

Type

TMyParamClass = class(TPersistent)
end;

TMyBaseParamForm = class(TForm)
public
procedure ShowModalParams(AParams : TMyParamClass);virtual;
end;

Now, your base form does only call ShowModal without doing anything
with params, but your derivative could look like this:

Type
TMyUsefulParams = class( TMyParamClass )
public
property IntProp : Integer;
property StrProp : String;
end;

TMyForm = class( TMyBaseParamForm )
public
procedure ShowModalParams(AParams : TMyParamClass);override;
end;

Now you implement your params settings(using a typecast) and
place the Inherited; keyword to call ShowModal.

You could then enhance the whole thing by using RTTI or a
Value Type Framework.

However, since I beleive this thread pertains to .oodesign group,
follow-up is set there.

Thanks

HTH,

Ardahan

Andrew
Back to top
Nicolai Waniek
Guest





PostPosted: Mon Feb 13, 2006 10:03 am    Post subject: Re: AV when calling FreeAndNil on InterfacedObject Reply with quote

Joanna Carter [TeamB] wrote:

en see how it goes Smile)
Quote:

We await your next effort ;~}

Joanna


Hello,
Although i tried it the ways you proposed it didn't seem to work so I
changed the design to aggregation without usage of interfaces... It
seems to work pretty well (though I'm not already done and we're within
heavy testing right now).

Thank you for your tipps!


--
Nicolai Waniek
sphere71.com
Back to top
pcplayer
Guest





PostPosted: Mon Feb 13, 2006 11:03 am    Post subject: Re: AV when calling FreeAndNil on InterfacedObject Reply with quote

Hi,

I have the same problem.

Through my test, if a class is a descendent class of TInterfacedObject
and implement a Interface, and if you use it's interface, if you free
it , you will get a AV error.

I write a class named TMyInterfacedObject, it just like
TInterfacedObject, and I Update this code:

function TInterfacedObject._Release: Integer;
begin
Result := InterlockedDecrement(FRefCount);
if Result = 0 then
Destroy;
end;

To:

function TMyInterfacedObject._Release: Integer;
begin
Result := InterlockedDecrement(FRefCount);

//if Result = 0 then
// Destroy;
end;

So, if I release all the interface ref, the class will not free it's
self.

The next step of my test is:

I make a new class descendent from TMyInterfacedObject:

ILjnInt=interface
['{90C24D7C-EBEF-43E0-9B57-43AD11733866}']
procedure Hello(S:string);
end;

TLjnClass=class(TMyInterfacedObject,ILjnInt)
public
FMyInt:ILjnInt;
constructor Create;
destructor Destroy;override;
procedure Hello(S:string);
end;


Then, I use this class like:

MyClass:=TLjnClass.Create;
MyInt:=ILjnInt(MyClass);
MyInt.Hello('abcdefg');
MyInt:=nil;
MyClass.Free;

Ha, there is no problem.

if I have not do MyInt:=nil, MyClass.Free will cause AV error.

conclusion: if you get a interface Ref. of a Interfaced Object, and
have not set it to nil, execute this class's Free method will cause AV
error. if you free all interface Ref. of this object, you can free it
with no error.

But, why ? How can I change this behavior through change the source
code of TInterfacedObject ?

It seems no way ?
Back to top
pcplayer
Guest





PostPosted: Mon Feb 13, 2006 4:03 pm    Post subject: Re: AV when calling FreeAndNil on InterfacedObject Reply with quote

try again....

In my test below, I found that I can Free a Object while it's
Interface's Ref. more than one.

First, I declare a class just like TInterfacedObject:

TLjnInterfacedObject = class(TObject, IInterface)
protected
FRefCount: Integer;
function QueryInterface(const IID: TGUID; out Obj): HResult;
stdcall;
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
public
procedure AfterConstruction; override;
procedure BeforeDestruction; override;
class function NewInstance: TObject; override;
property RefCount: Integer read FRefCount;
end;


all implementation of this class just copy from TInterfacedObject,
only:

function TLjnInterfacedObject._Release: Integer;
begin
{Result := InterlockedDecrement(FRefCount);
if Result = 0 then
D estroy;
} <-----------This code is copy from TInterfacedObject, I comment
it.

Result:=-1; //<----- this code is add by me.
end;

the second, I declare a class like this:

ILjnInterface=Interface
procedure Hello(S:string);
end;

TLjnObj=class(TLjnInterfacedObject,ILjnInterface)
public
procedure Hello(S:string);
end;

and the third, I use the TLjnObj to test it:

procedure TForm1.Button1Click(Sender: TObject);
var
MyObj:TLjnObj;
MyInt:ILjnInterface;
MyCom:TComponent;
i:Integer;
S:string;
begin
1. MyObj:=TLjnObj.Create;

2. MyInt:=ILjnInterface(MyObj);


{
3. i:=MyObj.RefCount;
4. S:=IntToStr(i);
5. Memo1.Lines.Add(IntToStr(i));
}


6. MyInt.Hello('haha');

7. //MyInt:=nil;

8. MyObj.Free;
end;

In this code, I used the MyInt:ILjnInterface, and I didn't set it to
nil ( on line 7), and on line 8, I free MyObj. It's no problem! There
is no AV error!

But, if I let the line 3, 4, 5 execute, It will cause AV error. It's so
strange.

If I let line 3,4,5 execute, and the same time do line 7: MyInt:=nil,
there is no AV error.

So, if use a object's interface and you have not set it to nil when you
FreeAndNil the object, it is ok, but this time you must not read the
object's RefCount method otherwise you will get a AV error.
Back to top
Dave Keighan
Guest





PostPosted: Mon May 22, 2006 8:15 pm    Post subject: Re: About Entity-Relationship Diagram in BDS 2007 Reply with quote

Bob,

In the "About Entity-Relationship Diagram in BDS 2007" thread in borland.public.delphi.non-technical you, Jim Cooper and Joanna Carter have all made comments about not using an OPF that streams objects to Blobs [ .... or to that effect Jim Smile ]. Jim and Joanna have rolled their own - you haven't indicated what you use, not that it's important to my question(s). I think the three of you have an extremely valid point here and would like [you] to discuss it more ... just not in /that/ thread :)

Quote:
Nothing that streamed to blobs was considered here either. An OPF can and
should use a well-normalized database.

A bit fussy about how I get things done, I agree with you 110% on this point. Outside of rolling my own, which would point me right back to dropping DA controls on form and linking them directly to the DataSource, what's a guy to do? I'm not rolling my own and I've only found two viable [2006 Pro SKU and no budget] alternatives. IO and tiOPF. Unfortunately both are in various stages of redesign and the transition to using an OPF, for newbies [specifically me], requires a significant amount of support documentation that is still in the works. I'd decided to use IO primarily because of the ability to learn [and understand] it quickly with the available information/examples/support. The fact that it is integrated into the IDE was a huge consideration as well. Again with the being fussy bit, there are a few things I don't like, one of them being the fact that the database produced isn't [exactly] normalised - at least not what I'm used to as normalised. Does an Object Data Store _have_ to be normalised in the fashion I'm used to - I don't know. Could you provide some additional information on your position? At any rate, I'd decided to sluff it off and get on with things - your comments [simply for the reason that I value your opinion] have got me wondering about that decision. Bit of a quandary, I'd say, although I know that, in the end the decision is _mine_ and I'll have to make it.

Although "enterprise" is almost uniquely the level of discussion involved when talking about OPF and databases in general. I have to wonder if the opinions that get expressed would be as extreme if we were to take things down a few notches to a desktop utility level. Even something as simply as recipe collection storage/retrieval system for granny. Is using an OPF for this type of application even applicable or is it over kill? I'd like to think using an OPF, where persistence is used, is a _must_ regardless of application being written. Having said that and considering the application level we're discussing are blobs such a big deal?

Many thanks,
--
Dave Keighan
XanaNewser [ 1.17.6.3]
Back to top
Jim Cooper
Guest





PostPosted: Tue May 23, 2006 9:15 am    Post subject: Re: About Entity-Relationship Diagram in BDS 2007 Reply with quote

Quote:
comments about not using an OPF that streams objects to Blobs

The problem I had with InstantObjects was the only choice for one to many
relations at the time was blobs in a field. Since the data I was going to be
dealing with was highly hierarchical, this was not going to work for me. If your
object model is pretty flat, it might work, but you still can't do very much
with blobs (you can't load the detail objects by themselves, for example).

I find that the data ends up pretty normalised almost all the time, BTW.

Cheers,
Jim Cooper

_____________________________________________

Jim Cooper jcooper (AT) tabdee (DOT) ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
_____________________________________________
Back to top
Dave Keighan
Guest





PostPosted: Tue May 23, 2006 4:15 pm    Post subject: Re: About Entity-Relationship Diagram in BDS 2007 Reply with quote

Jim,

Thanks for taking the time to respond.

Quote:
The problem I had with InstantObjects was the only choice for one to many relations at the time was blobs in a field. Since the data I was going to be dealing with was highly hierarchical, this was not going to work for me. If your object model is pretty flat, it might work, but you still can't do very much with blobs (you can't load the detail objects by themselves, for example).

Ahh yes, <removing rose coloured glasses> some people do deal with data that is much more complex than that required for the desktop utilities I'm talking about. Fits the 'why do you roll your own' question I had nicely. Don't know why I have such a big issue with BLOBs, I just do.


Quote:
I find that the data ends up pretty normalised almost all the time, BTW.

Probably the biggest issues I'm having with IO-OPF is getting used to how objects get persisted ... I've taught myself to be very fussy about normalising the dB.


Oh well, it's all a learning experience ... thanks again,
--
Dave Keighan
XanaNewser [ 1.17.6.3]
Back to top
Display posts from previous:   
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi OO design All times are GMT
Goto page 1, 2, 3, 4, 5  Next
Page 1 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.