[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 306
  • Last Modified:

call event code in a diffrent dll

hi there ,
i have this event
  private void txtTz_Leave(object sender, EventArgs e)
        {
            if (Tz != txtTz.Text.Trim().TrimEnd())
            {
                Tz = txtTz.Text.Trim().TrimEnd();
                bool flag = fa.ChekEmpExs(Tz);
                if (flag == true)
                {
                    MessageBox.Show("¿¿ ¿¿¿¿ ¿¿¿¿ ¿¿¿¿¿¿", "¿¿¿¿¿ ¿¿¿¿¿");
                    txtTz.Clear();
                    txtTz.Focus();
                }
               
            }
        }
can i declare this event in another dll and get also the object propries in the distrbute dll
i just want to manage the code out from the win form
what its the best wasy to manage code by layers ?
0
Tech_Men
Asked:
Tech_Men
  • 3
  • 2
1 Solution
 
saraganiCommented:
Hi, the code you've posted is not the event, but the function that is being called when the event is fired.

The function is being "attached" to the event by:

txtTz.Leave += new ...


Your function is not "Generic" since the code inside the function knows about a control called txtTz, and Tz (which is assume is a string).

You can access txtTz and Tz because you are writing in the Code-Behind of the form.


You can pass the textbox txtTz to the Dll, but that would be a bad coding.

You should better have the code in a way that every time the text changes, it changes a text property in your DLL, and then call a public function in your DLL when the textbox is being Left.


Please read more about MVP and 3 tiers model.



I can also suggest you to write in WPF since "Binding" is the new way of connecting Business logic to the View.
0
 
käµfm³d 👽Commented:
Just to be clear, what you have posted is an event handler, not an event. The handler is the code that gets executed when some event occurs. A handler is just a function like any other.

Events are designed to be raised by the object which owns the event. Think about it like this:  unless you are an invalid, does someone else lift your arms for you? Does someone else turn 30 for you? etc.

An event should be raised by the object itself. Can you expand on what the ultimate goal is?
0
 
saraganiCommented:
As I understand, he wants the txtTz_Leave "sit" on another DLL other than his form, and he expects to access txtTz.Text from another DLL, which is obviously not a good idea.
Although he can actually get the mentioned TextBox from casting the sender into a TextBox, it is not recommended.
0
 
käµfm³d 👽Commented:
As I understand, he wants the txtTz_Leave "sit" on another DLL other than his form, and he expects to access txtTz.Text from another DLL, which is obviously not a good idea.
Although he can actually get the mentioned TextBox from casting the sender into a TextBox, it is not recommended.
If that is the case, then there's not really any difference in assigning the handler to be a function in the DLL rather than a function on the forms, aside from location of the function. He would be coupling his DLL to the System.Windows.Forms library at that point, but the DLL itself would still be decoupled from the form due to your casting of sender, as you mentioned.
0
 
saraganiCommented:
Yes, I know... and I said that it is not the best practice.
It would be better to either have a Presenter that deals with the BL in a class along the Form, or have it (is needed) in a different DLL, and the Presenter's function would be either way called from the event handler located on the form.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now