OK, so you are embedding the data object in the form. This seems odd to me.
If a bit of calling code wants to update the data object, there is no way to
do so except by going through a form. A data object cannot exist without
being tied to a form, and a data-aware form cannot share data objects with
another form.
This coupling between forms and data objects is not a good thing
architecturally. In fact, it is really bad.
Best advice I can give at this stage: You want to have a controller object
in there somewhere that provides indirection. Make the controller a
singleton. Give it all powers of creation. E.G. no form or data object can
be created except by a method on the controller.
If a form wants access to a data object, it will ask the controller for it.
If the data object exists, the controller can return it. Otherwise, it can
create it (where creation implies query or preloading from a file, etc).
That way, any form can get access to any number of data objects, and forms
do not need to know if the object already exists or how to create it.
Also, when the form asks for a data object, either the controller can
register the form to receive the update events, or the form itself can
register the events. Right now, the data object has the code to register
the events, which implies that the data object is aware, at some level, of
the object that wants to be informed of the event. (Doesn't show in your
code, but once you get the bugs out, it will).
The controller and the data objects act as your middle layer. The forms are
your front end. The DAL under your data objects acts as your data layer.
This gives you a clean multi-tier design using the Model-View-Controller
pattern.
In other words... your original question is about how to best rearrange the
deck chairs on the Titanic... and I ducked the question completely to point
out the pesky iceberg.
As far as the apparent recursiveness: if a user updates a form, and the form
wants to update the data object, the form should set a flag so that when it
gets the event for a change to the data object, it knows to ignore it. Your
current check for changes is sufficient, or you can use a private field in
the form object.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Rob Penridge" <rp*******@hotmail.com> wrote in message
news:eL**************@TK2MSFTNGP10.phx.gbl...
Hi Nick, thanks for the reply. A sample bit of code may make it easier
for you to see what I am doing... I've just thrown this together but you
should get the idea.
<-- UNTESTED -->
public class frmMyDataClass {
...
Private _DataClass as DataClass
...
public sub new()
...
_dataclass = new dataclass("c:\mydataclass.xml")
end sub
public readonly property DataClass as DataClass
get
return _dataclass
end get
end sub
private sub RefreshDataClassName(ByVal title as String)
'Update the form title
me.text = title
'Update the treeview node
me.mytreeviewnode = title
'Update the textbox value (also used to change the
'value of _DataClass.Name)
me.txtDataClassName = title
end sub
..
'This sub is for a textbox control on the form
'and is fired when the value is changed
private sub txtDataClassName_TextChanged(ByVal sender _
As Object, ByVal e As System.EventArgs) Handles _
txtT2PDName.TextChanged
me.DataClass.Name = txtDataClassName.value
end sub
..
protected overridable sub _DataClass_NameChanged(ByVal sender as Object,
Byval e as DataClassEventArgs)
RefreshDataClassName(e.DataClass.Name)
end sub
..
end class 'frmMyDataClass
public class MyDataClass
public event NameChanged as Eventhandler
private _name as string
public property Name as String
get
return _name
end get
set (value as string)
if _name <> value then
_name = value
OnNameChanged(me, new MyDataClassEventArgs(me))
end if
end set
public sub new(byval filename as string)
'get details from file here....
...
me.Name = strFromFile
end sub
protected overridable sub OnNameChanged( _
byval sender as object, byval e as MyDataClassEventArgs)
Raiseevent NameChanged(me,e)
end sub
end class 'MyDataClass
<--UNTESTED-->
Ok, sorry the codes a bit of a mess but you should get the gist of
things. Basically all of the different places in the GUI that need to
be refreshed will be refreshed by the RefreshDataClassName sub which is
called whenever something changes the value of the DataClass.
Is there any advantage to doing it this way or should I just make a call
to the RefreshDataClassName sub everytime the value is changed and don't
worry about raising the events.
I'm also a little concerned about using the textbox this way. It works
fine but I don't like that it is almost recursive. Ie.
1) You change the value in the textbox
2) this updates dataclass.name b/c they are not equal
3) the NameChanged event is fired
4) the RefreshDataClassName sub is called which changes the value in the
textbox (see step 1)
5) this tries to update dataclass.name again but they are already equal
because of the check I put in the property so it stops here.
Anyway, this is my first attempt at .Net so you'll have to excuse my
newbieness.
Thanks
Rob
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!