|
well, in user control...
FormMain mainForm = (FormMain)this.Parent;
mainForm.CallFunction();
or you could store a static instance of your main form somewhere, then...
ClassStatic.MainForm.CallFunction();
or, probably what i would go for, create an event handler in the usercontrol that the main form is listening for... Then you just fire the event in your usercontrol... In user control class...
public delegate void MyUCEventHandler(object sender, EventArgs e);
public event MyUCEventHandler UCEvent;
protected virtual void OnEventCall(EventArgs e)
{
if(UCEvent != null)
UCEvent(this, e);
}
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Option 3 is the better from an OO point of view.
It is a better design aproach to 'inform' the outside when the state within a class changes. That way there is little or no coupling from the referenced class, in this case the control, and the referencing class, the form.
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
ok, I admit I was assuming that the control was intended to be used in multiple forms. So how would you 'inform' the form of a change?
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
musefan wrote: So how would you 'inform' the form of a change?
An event! I said, and Wavey Davey concurred, the event approach is the safestest.
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
Oh right, I misunderstood your post thinking you were saying that an event would not be the best option in this case. i.e if a control is only intended to be used in one form then it should talk directly with the form itself...
Nevermind
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Use musefan's 3rd option above - the event driven one. If you're just wanting the signature to be the standard
object sender, EventArgs e then you don't need to create your own delegate, just use EventHandler like this:
public event EventHandler UCEvent;
protected virtual void OnUCEvent(EventArgs e)
{
EventHandler eh = UCEvent;
if(eh != null)
eh(this, e);
}
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
I agree with all of them! Use option 3.
If this is your first time doing this, then you may need more detail:
In your child form:
public partial class frmDetail : Form
{
public delegate void OnChangeHandler(object sender, EventArgs e);
public static event OnChangeHandler OnChange;
private void DoSomethingToChangeData()
{
OnChange(file, null);
}
}
In your main form:
public frmMain()
{
frmDetail.OnChange += new frmDetail.OnChangeHandler(OnChanged);
}
private void ChangeCards()
{
frmDetail fd = new frmDetail(currentDetail);
fd.ShowDialog();
}
private void OnChanged(object sender, EventArgs e)
{
FileChanged = true;
}
It is pretty simple when you get your head around it!
[edit] Changed to move add event handler out of frmDetail instance create - we don't want another event each time ChangeCards is called, do we? My brain is not working - it must be thursday [/edit]
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
|
|
|
|
|
A few problems. Avoid the Onxxx for the event name, that should be saved for the method that raises the event - in your example the event should be either Changing or Changed dependending on when it's fired.
An inheritor of your class may need to add functionality so the event itself should be raised in a separate protected virtual method OnChanging or OnChanged with that method taking the event args.
In your child form snippet, you call the event directly. If there are no subscribers, this will generate a NullReferenceException. At a minimum you should null check.
protected virtual void OnChanged(EventArgs e)
{
if(Changed != null)
Changed(this, e);
} There is a possibility (unlikely) that 'Changed' could change between the null check and the event raise line, so either a copy should be created and work on that copy:
EventHandler eh = Changed;
if(eh != null)
eh(this, e); or it should be put in a try/catch block.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
Sorry. (I feel really small, now)
Your comments are (as always) correct, so I modified it.
In the child form:
public partial class frmDetail : Form
{
public delegate void ChangeHandler(object sender, EventArgs e);
public static event ChangeHandler Changed;
protected virtual void OnChanged(EventArgs e)
{
ChangeHandler ch = Changed;
if (ch != null)
{
ch(this, e);
}
}
private void DoSomethingToChangeData()
{
OnChanged(null);
}
}
I am not sure a try - catch block would be a good idea: it's not an error to not have a handler, and the throw/catch will be slow. But that is just me.
In the main form:
public frmMain()
{
frmDetail.Change += new frmDetail.ChangeHandler(Changed);
}
private void ChangeCards()
{
frmDetail fd = new frmDetail(currentDetail);
fd.ShowDialog();
}
private void Changed(object sender, EventArgs e)
{
FileChanged = true;
}
Better?
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
|
|
|
|
|
Yeah
Static events are pretty dangerous, unless you explicitly unsubscribe from the event, the subscribing object will stay in memory even when you think it's gone as a reference is held to it in the delegate's invocation list!
Normally it's better to use instance ones, in which case you'd need a class level member variable
frmDetails fd; and then (possibly in the constructor)
fd = new frmDetails;
fd.Changed += ...
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
DaveyM69 wrote: Static events are pretty dangerous, unless you explicitly unsubscribe from the event, the subscribing object will stay in memory even when you think it's gone as a reference is held to it in the delegate's invocation list!
Normally it's better to use instance ones, in which case you'd need a class level member variable
frmDetails fd;
Yeeeees... I think I'd rather unsubscribe, or you will always have the memory allocated to the form instance anyway...
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
|
|
|
|
|
Thanks to all for the help,
I am able to implement it.
Regards
Mahesh
|
|
|
|
|
Hi all,
I was browsing the net and stumbled upon the following piece of code and stated to wonder, is it better to open a connection to the database once and make use of it until the application closes or open and close it after each use during the application life cycle?
Code snippet[^] being referred to.
Many thanks in advance
Kind regards,
The only programmers that are better C# programmers, are those who look like this -> |
Programm3r
My Blog: ^_^
|
|
|
|
|
Easy one... Open and close it each time. Don't keep an unused connection open, it's just a waste of resources. Once a connection has been made, it will get put in the pool anyway (providing you have connection pooling on) so the next time it connects it won't take as long.
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Thanks for the response.
Just a quick one though.... Even if you have to insert X amount of records every couple of seconds / minutes?
The only programmers that are better C# programmers, are those who look like this -> |
Programm3r
My Blog: ^_^
|
|
|
|
|
Well it depends... if you don't know how long between inserts then yes still open close each time, actually even if you know it will be every second on the dot I would still go for Open/Close each time. The only time I would keep it open is if I was going to do all the inserts at the same time with no other stuff being done in between.
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Thanks for the info.
The only programmers that are better C# programmers, are those who look like this -> |
Programm3r
My Blog: ^_^
|
|
|
|
|
This thread confused me a little. Is it better to open and close a connection for each query even in a short ASP.Net page?
I've always thought that
<%
cntDB.Open()
MakeAQuery()
'Do something else
MakeAnotherQuery()
cntDB.Close()
%>
Was better than
<%
cntDB.Open()
MakeAQuery()
cntDB.Close()
'Do something else
cntDB.Open()
MakeAnotherQuery()
cntDB.Close()
%>
Maybe simply I misunderstand something.
|
|
|
|
|
Well it depends what your 'Do Something Else' actually does.
If it's simply setting the text of a textbox of something similar then it would probably be best to do your first suggestion and keep the connection open (thou I doubt you would see a difference in performance if you have connection pooling on). If your 'Do something else could take some time then yes re-opening the connection is slightly costly but its better then wasting resources keeping the connection open.
Basically it depends what you do in between the database queries but I would generally close mine each time. Especially if I was using a custom class that handles my database work for me and should naturally close a connection after it finishes as It will not know if to expect another one any time soon.
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Well, basically my pages make some query and print out the result. Anyway I've found a serious problem, i have to use the MySql ODBC driver 3.51 which doesn't support connection pooling!
It's a verified bug! http://bugs.mysql.com/bug.php?id=12552
One day I'll pass to the native connector (but i'll have to replace tons of OdbcConnection, OdbcCommand, etc. with the respective MySql* names)
I think the better solution is makeing as less connections as possible and maybe set a short timeout for connections (now it's 60 secs and infact, through SHOW PROCESSLIST, i can see several threads sleep for 60 secs and then disappear).
Thanks!
|
|
|
|
|
That code you linked to is some of the worse ive seen. Its awful, don't use it.
|
|
|
|
|
Thanks for the head sup.
Any example code or wrapper that you have or might know of that is considered to be good?
Thanks in advance
Kind regards,
The only programmers that are better C# programmers, are those who look like this -> |
Programm3r
My Blog: ^_^
|
|
|
|
|
Personally I like the Microsoft Enterprise Library for data access, but in all honesty I usually roll out my own wrapper for this purpose.
The important thing to note about the library you linked to is that they are trying (for some odd reason) to circumvent the connection pooling that is already present in ADO.NET, as well as using dynamic sql for data access which is inherantly slow and unsafe.
|
|
|
|
|
|
At least it was formatted pretty!
|
|
|
|