shown event problem

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • nrylm25
    New Member
    • May 2010
    • 10

    shown event problem

    Hi,

    I have a problem about shown event. I have a login form and a main form. I start the program with main form. then I used frmMain.Shown() to control the login form. When main form is shown, it checks Win. Registry if username and password is stored there. İf yes, login form comes and wants me to sign in and if not, it calls first login form to create a record in Registry.

    The problem is that;
    When I click on X (close) button, it closes the login form, but Main form is still running and I can use it without sign in.

    How do I solve this problem? Or is there any other way to controls if Registry has the record or not?

    Thanks&Regards. ..
  • tlhintoq
    Recognized Expert Specialist
    • Mar 2008
    • 3532

    #2
    I would suggest you create a class of "privileges " that contain properties like "CanExit", "CanMakeUse rs" and so on.

    Your main form methods should check the user's privileges class to see if they are allowed to do each thing.

    You populate the privileges at log in. If they don't log in, the privileges are all false.

    Comment

    • nrylm25
      New Member
      • May 2010
      • 10

      #3
      Originally posted by tlhintoq
      I would suggest you create a class of "privileges " that contain properties like "CanExit", "CanMakeUse rs" and so on.

      Your main form methods should check the user's privileges class to see if they are allowed to do each thing.

      You populate the privileges at log in. If they don't log in, the privileges are all false.
      thanks for your reply...

      But I want to close program completely when user canceled the Login process. the program closes when I close it form cancel button, but I also want to close it when I click on X button.

      Privileges are good idea, but I dont work with a database, the progarm is created for a single user, and all the information is stored in windows registry.

      Comment

      • tlhintoq
        Recognized Expert Specialist
        • Mar 2008
        • 3532

        #4
        nrylm25: Privileges are good idea, but I dont work with a database, the progarm is created for a single user, and all the information is stored in windows registry.
        So store the privileges in the registry. I do it all the time. I just encrypt the features so someone can't use RegEdit to give themselves capabilities.

        nrylm25: But I want to close program completely when user canceled the Login process. the program closes when I close it form cancel button, but I also want to close it when I click on X button.
        Ok. So quit the program. You should create a single "Quit()" method, then call that from all the various ways someone might quit the program. If they choose a menu option "File | Exit" then call the Quit() method. If they close the form, then call the Quit() method.

        This way you have consistent behavior. Everything routes through the same Quit() method, which is responsible for cleaning up, closing threads, closing datafiles etc.etc.

        Take a look at the FormClosing event. No matter how they close the form, the form still fires this event.

        Comment

        • tlhintoq
          Recognized Expert Specialist
          • Mar 2008
          • 3532

          #5
          If you are having trouble with your Main form reacting to events in your log-in form, maybe this will help.

          Originally posted by OriginalPoster
          Original Poster: How do I get my Form2 to react to something on my Form1?
          How do I make my Form1 control something on my Form2?
          Although you can have Form1 directly access items on Form2 it isn't the recommended way to go. It ties the two forms tightly to each other. If a change is made in Form2 such as removing one of the controls, then code in Form1 breaks.
          It is better to Form1 raise an event, and have Form2 contain its own code for how to react to this. This places responsibility for Form2 within Form2, and Form1 within Form1.
          It keeps Form1 blissfully ignorant of Form2 - and a logging component - and a progress component, and a dozen other little black boxes that can be subscribed to events in Form1, all without Form1 being made responsible for directly affecting controls other than itself.
          Events tutorial (including Form to Form which is the same as class to class)
          This tutorial for a cash register does exactly that: It makes a virtual numeric keyboard.

          Bad: Directly accessing controls of one class/form from another.
          Code:
          bool IsOn = Form2.button1.IsChecked;
          Good: Use a property to get such information
          Code:
          //Form1
          bool IsOn = Form2.IsOn;
          Code:
          //Form 2
          public bool IsOn
          {
             get { return CheckBox1.Checked; }
             set { CheckBox1.Checked = value; }
          }
          It's a subtle but important difference as your applications become more complex. Using properties means your target class/form (Form2) can be changed and updated a thousand different ways yet won't negatively impact the classes that are reading from it. If you change the name of a control for example: It won't break references in all your other classes. If your target form evolves where it needs to do 10 things when it is turned on, then the responsibility stays within Form2, and that burden is not put on Form1 and a dozen other forms that might be using Form2. The goal is to compartimentali ze the work so that Form2 is responsiblity SOLELY for Form2. From1 should only have to say "Turn on" or "Turn Off"

          Form2
          Code:
          public bool IsOn
          {
             get { return btnMeaningfulName.Checked; }
             set {
                      btnMeaningfulName.Checked = value;
                      panelDashboard.Visible = value;
                      labelStatus = value == true ? "On" : "Off";
                      btnRunNow.Enabled = value;
                 }
          }
          Now when Form1 tells Form2 to turn on, Form2 will check a box, make an entire panel visible, change its Status label to say 'On' and enable a Run Now button.

          Comment

          • nrylm25
            New Member
            • May 2010
            • 10

            #6
            Originally posted by tlhintoq
            So store the privileges in the registry. I do it all the time. I just encrypt the features so someone can't use RegEdit to give themselves capabilities.

            Ok. So quit the program. You should create a single "Quit()" method, then call that from all the various ways someone might quit the program. If they choose a menu option "File | Exit" then call the Quit() method. If they close the form, then call the Quit() method.

            This way you have consistent behavior. Everything routes through the same Quit() method, which is responsible for cleaning up, closing threads, closing datafiles etc.etc.

            Take a look at the FormClosing event. No matter how they close the form, the form still fires this event.
            Thanx a lot....

            I solved the problem. Thanks again:))

            Comment

            Working...