Hi Gideon,
<snip>
basically i did'nt want to make it confusing but , there are levels ...
each user is given some privilege and retricted in some way , eg .
some users might not be allowed to edit , but only allowed make new
entries , some users would be allowed do the opposite.. etc... .the
celBeginedit is'nt the only event i have to check for this...
In that case, the code I posted in my original response should be useful to
use as the foundation for a User business object to encapsulate information
about a particular user, and a UserUICapabilit ies object that encapsulates a
User's permissions. You may even want to use roles that encapsulate groups of
permissions so that you can write code as such the following:
if (User.Current.I sAdministrator) // role-check
{
// do admin things such as allow edit AND decrypt related information
}
else if (User.Current.C anEdit) // permission-check for non-admins
{
// allow edit
}
i'm just asking if its CORRECT to give it a different delegate to
different funciton depending on what privelages the use has...
For the example you posted, I wouldn't recommend it at all. As I already
stated, I think that logic should be in the event handler (or better yet, be
abstracted into a business object).
becuase checking for it in ONE event might get cumbersome and reduce
efficency??
The same would be true in the method that checks the user name to determine
which delegate to be registered as an event handler.
Try to separate the UI logic from the business logic. That is, encapsulate
the business logic in separate components that can be utilized by the UI code.
Only provide one place to handle a UI event, and then perform the required
processing in the appropriate business object. If the process itself will
vary by state that is retrieved from a database, such as user permissions,
then this design approach will make it much easier for you to change things in
the future without having to change the business logic in all of the UI
classes in which it may have been hard-coded. This is especially true if you
code the logic as in your example, where you wrote:
if (user == "user1")
What happens if "user1" is renamed to "user_1", or deleted, or their
permissions are changed?
In that case, you'd have to recompile your code to handle the change in the
data. That's something that should by dynamic, and accounted for ahead of
time so that simple changes in data will not require the entire solution to be
modified and redeployed.
Business objects can be the first step to providing the abstraction you need
from your UI code to your business logic code so that you don't have to
hard-code user names, permissions and business logic in every event handler in
which it's required.
also is Program.cs file , with "class program , and the main()" the
place to have complete global variables? that can be accessed by all
forms and dialogs??? (i'm an ex vb! , so i'm asking is program.cs like
a module file?)
Try to use as little global variables as possible. Instead, try to think more
OOP.
That said, there are definitely times where a global variable might be of use
outside of any business object, but it's rare (if even appropriate at all).
But I do use the Program class in my projects to aggregate certain singleton
data such as the current user of the application or the current client context
in which all of the Forms in my application will process information across
the entire system, for example:
static class Program
{
public static User CurrentUser { get { return User.Current; } }
public static Client CurrentClient { get { return Client.Current; }
}
But realize that the Program class doesn't store the data in this case, it
just creates a common interface for accessing global data. The data itself is
stored in the appropriate business object. In some cases, a DataContext
object may be useful if you need to store multiple contexts, simultaneously.
I like using the Program class because it just feels natural to code against
data with application scope like this:
if (Program.Curren tUser.IsAdminis trator)
{
if (Program.Curren tClient.Invoice Required)
{
Invoice invoice = Invoice.Prepare Invoice(Program .CurrentClient) ;
}
}
This is really just a matter of opinion. Some people, I'm sure, prefer to
access the User and Client objects directly for singleton data. I just feel
that User.Current isn't as clear as Program.Current User.
--
Dave Sexton