The question of whether you should allow new companies/departments to be created when adding/editing contacts is really a question for your users/customers but I would lean away from it if possible. If you want users to have the ability to add companies/departments from this interface, consider adding an ellipsis button (...) next to the drop-down control that will display a list editor when clicked.
Then, if you want to enforce security so that only certain users may add/remove/modify the list of companies/departments, you can bind this button's Visible or Enabled property instead if trying to implement all kinds of additional logic to handle it the way you've described.
This would also eliminate the mess with DepartmentID being -1 or Int32.MaxValue by always limiting the user to selecting from the drop-down list from your main interface. So, SelectedIndex will always be >= -1.
You can bind the drop-down list and the list editor to the same collection object so that any changes to the collection through the list editor can be carried over to the drop-down list by simply rebinding the control when the list editor is closed. Then, you can still bind DepartmentID to the SelectedIndex property of the drop-down list as you indicated.
Obviously this adds to your UI requirements, but may be a cleaner way to code it unless your business requirements prevent this approach.
Hope that helps.
SonOfPirate:
The question of whether you should allow new companies/departments to be created when adding/editing contacts is really a question for your users/customers but I would lean away from it if possible. If you want users to have the ability to add companies/departments from this interface, consider adding an ellipsis button (...) next to the drop-down control that will display a list editor when clicked.
Then, if you want to enforce security so that only certain users may add/remove/modify the list of companies/departments, you can bind this button's Visible or Enabled property instead if trying to implement all kinds of additional logic to handle it the way you've described.
Fortunately for right now, the users that can create contacts can create companies, and users that cannot create contacts cannot create companies. Only Sales people can modify those aspects of the data.
You can bind the drop-down list and the list editor to the same collection object so that any changes to the collection through the list editor can be carried over to the drop-down list by simply rebinding the control when the list editor is closed. Then, you can still bind DepartmentID to the SelectedIndex property of the drop-down list as you indicated.Obviously this adds to your UI requirements, but may be a cleaner way to code it unless your business requirements prevent this approach.
I would like to go this route, but the requirements are such that they want 'one form' when creating a contact. Originally I had required the users to create the company / department first, then it would appear in the comboboxes.. however Sales people are on the phone and must capture all the info at once. They found they were writing things down, then maybe going to the app to enter the data later..
The way it works now, the users are happy and enter directly into the application while they are on the phone. Which is good.. its just my end of things are more complicated.. I did float the elipsises idea by them, and they were instant that it was all one form.
Oh, boy. I've been down that road before. Have they considered what safeguards are to be in place to prevent one user from entering "Ford", another from entering "Ford Motor", a third from entering "Ford Motor Co." and fourth from entering "Ford Motor Company"? (Been there, done that!).
This is the obvious pitfall in not enforcing selection from a list, but if they are comfortable with the risk or have incorporated some additional logic to prevent such things, then who's to tell them otherwise, eh? Just wait until they try to run a report and bring up all sales for "Ford" and the list is missing some items!!!
If this is to be the case, then your work is a bit more complicated because, as you said, there is a problem trying to bind the DepartmentId to the drop-down list. If I understand your original post correctly, you are going to have the following type of code in the Save routine (pardon the rough semi-code):
if (CompanyList.SelectedIndex == -1)
{
if (String.IsNullOrEmpty(CompanyList.Text))
{
DataSource.DepartmentId = -1;
}
else
{
Company c = new Company(CompanyList.Text);
c.Save();
DataSource.DepartmentId = c.Id;
}
}
else
DataSource.DepartmentId = CustomerList.SelectedIndex;
Is that close? I guess the only questionable area is creating the new company and saving it all in one shot, but if that's what you've got to do, ya know?
Sounds like you are on the right track given the requirements you've been handed.
Oh, boy. I've been down that road before.
![Smile [:)]](/emoticons/emotion-1.gif)
Have they considered what safeguards are to be in place to prevent one user from entering "Ford", another from entering "Ford Motor", a third from entering "Ford Motor Co." and fourth from entering "Ford Motor Company"? (Been there, done that!).
This is the obvious pitfall in not enforcing selection from a list, but if they are comfortable with the risk or have incorporated some additional logic to prevent such things, then who's to tell them otherwise, eh? Just wait until they try to run a report and bring up all sales for "Ford" and the list is missing some items!!!
Yes, I did explain these problems. Their answer was that it doesn't change the fact that need to enter data very quickly, and having more forms opened slows them down, which, to be fair, is a valid point.
To prevent the problems you describe, I've set the company / department comboboxes SuggestList. Changing the company changes the SuggestList on the department (or nulls it, if the company doesn't exist). Additionally, there is functionality to merge companies, departments and even contacts, since they do have some duplicates of those too!
I don't have any reports yet; only the contact management piece is done. But I am working on quoting, invoicing and ordering, and reports will be part of that phase and those issues will be brought to light. If its a big problem, I can try pushing them to the elipsis button route.. unless someone has another solution! ![Big Smile [:D]](/emoticons/emotion-2.gif)
If this is to be the case, then your work is a bit more complicated because, as you said, there is a problem trying to bind the DepartmentId to the drop-down list. If I understand your original post correctly, you are going to have the following type of code in the Save routine (pardon the rough semi-code):
if (CompanyList.SelectedIndex == -1)
{
if (String.IsNullOrEmpty(CompanyList.Text))
{
DataSource.DepartmentId = -1;
}
else
{
Company c = new Company(CompanyList.Text);
c.Save();
DataSource.DepartmentId = c.Id;
}
}
else
DataSource.DepartmentId = CustomerList.SelectedIndex;Is that close? I guess the only questionable area is creating the new company and saving it all in one shot, but if that's what you've got to do, ya know?
That more or less is what I have done.
I was hoping there may be a simplier solution, like creating a Company and Department properties on Contact. Behind the scenes when the contact is saved, it would look up the company / department from the text entered.Sounds like you are on the right track given the requirements you've been handed.
Copyright (c) Marimer LLC