Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>So the problem that you're having is just a small symptom of major fundamental problems in your code that will only continue to manifest themselves as you continue.</p> <p>I've re-written what you have into something that's more in line with what is more traditionally seen for what you're trying to do. It's not perfect, and I've tried to keep things fairly simple so as to not throw too much at you at once.</p> <pre><code>public partial class Form1 : Form //Main form class { private TextBox itemInput; private TextBox txtOutput; private string eventType; //used for event type selection private string formEventName; //used to store selected event name private void itemSend_Click(object sender, EventArgs e) { string name = itemInput.Text; try { Event myEvent = Event.Create(eventType, name); txtOutput.Text = "Event name is " + myEvent.Name + "\r\n"; } catch (ArgumentException ex)//if the event name isn't valid { MessageBox.Show(ex.Message); } } } public abstract class Event { public string Name { get; private set; } public Event(string eventName) { Name = eventName; } public static Event Create(string eventType, string eventName) { if (eventType == "Leisure") { Leisure myLes = new Leisure(eventName); return myLes; } // else if { ... } test for other event types else { return null; } } } public class Leisure : Event { private static List&lt;string&gt; myEventNames = new List&lt;string&gt;() { "music", "Music" }; public Leisure(string eventName) : base(eventName) { if (!myEventNames.Contains(eventName)) { throw new ArgumentException("Not a valid Leisure event name"); } } } </code></pre> <p>So, let's go over some of the changes. First off, <code>Event</code> doesn't inherit from <code>Form1</code>. It should not do so. An event is not conceptually a type of form at all, let alone that particular type of form. An <code>Event</code> should have no knowledge of any form, in any way, not just inheritance. It's just some other class that <code>Form1</code> will use, but it could just as easily be used by any other type of class, form or otherwise.</p> <p>In addition to making <code>Event</code> not inherit from <code>Form</code>, I've made it abstract. It doesn't have any abstract methods, it's just that you shouldn't ever be creating just an plain <code>Event</code>, you should only ever actually create some specific type of event. Being a common base class, it's easiest to prevent accidental creation and to help improve readability by making it <code>abstract</code>.</p> <p>I've also made <code>Event</code> immutable. Rather than allowing name to be changed at any time, creating an event without giving it a name, and then changing it later, I have configured it such that you need to provide the name and type before creating the event, and then there's no way of changing it once it's created. The <code>Name</code> is set in the constructor, and I have added a static <code>Create</code> method which is where the logic can go for choosing the proper subtype of <code>Event</code> and actually creating it. This is a simple version of the "Factory Pattern". Note that normally I wouldn't pass the type in as a string. I would make it something like an <code>Enum</code>, so that it's easier to tell what the valid options are.</p> <p>Now onto <code>Leisure</code>. Logically, <code>Leisure</code> really is an <code>Event</code> and should inherit from it. Your problems were steming from the fact that you created an instance of <code>Event</code>, and also an instance of <code>Leisure</code>, and assumed that they shared the same variables. They don't, but that confusion should go away now that you can't ever have an instance of <code>Event</code>.</p> <p>When a <code>Leisure</code> is created it uses the base class constructor to set <code>Name</code>, since it doesn't have access to set the property itself.</p> <p>From what I can see <code>myEventNames</code> is just a list of valid names, and it doesn't appear to change between different types of <code>Leisure</code> instances, so it makes sense for it to be <code>static</code>, which means it's shared between all instances and is only created once.</p> <p>I also moved the <code>MessageBox</code> call out of the <code>Leisure</code> type's constructor. Instead I'm throwing an exception. The main idea here is that you shouldn't mix your UI code with your business code. <code>Event</code> and <code>Leisure</code> are both business objects and shouldn't know anything about what, if any, UI exists. You should be able to use them from a console app, an ASP application, etc. On top of that, since what we're trying to say is that this is an invalid name and the type shouldn't exist, the end result of throwing an Excpetion in the constructor is that the object never becomes "valid". We don't allow the creation of an object that shouldn't exist, as opposed to allowing them to continue using the object anyway.</p> <p>That exception is caught with the <code>try/catch</code> block in <code>Form1</code>, where it shows the appropriate <code>MessageBox</code> based on the failure to create the event. </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload