Re: Role-Based Dynamic UI - C# Discussion Boards

Nyanoba10-Oct-11 23:04

Nyanoba

10-Oct-11 23:04

Yes., i do have that..,

Calla10-Oct-11 20:17

Calla

10-Oct-11 20:17

Assuming you use Visual Studio you can right click your DLL-project and choose Properties. Under the "Debug" section you can choose an external program to be launched as a start action - a program that uses your DLL. Another simple way would be to just add for instance a Console project to your solution, add the DLL project to References and then start that program.

If you don't use Visual Studio, and your IDE doesn't support the first method described above, you could still use the second method for debugging. Good luck!

Nyanoba10-Oct-11 22:38

Nyanoba

10-Oct-11 22:38

Yes, we can do that,
But my requirment is that i already had a framework and this is the dll which i want to load, So i want to debug the dll without having .cs file .
What i has is just an pdb and .dll file.
I am able to launch the VS Debugger then how to give thw code to debug, thats the problem ?

Windows NameSpace Extension

Daniel.Grondal12-Oct-11 2:22

Daniel.Grondal

12-Oct-11 2:22

I don't get it, do you want to debug a dll without an executable?

//daniel

ycorre10-Oct-11 16:18

ycorre

10-Oct-11 16:18

Hi !

I'm looking to write a Windows Shell Namespace Extension using .Net.
The Extension needs to support drag'drop and context menus would also be nice.
What I'm specifically looking for is links, books, and examples that are useful.

Thank in advance.

Re: Windows NameSpace Extension

Richard MacCutchan10-Oct-11 22:17

Richard MacCutchan

10-Oct-11 22:17

Start here[^].

Unrequited desire is character building. OriginalGriff

Role-Based Dynamic UI

Matt U.10-Oct-11 15:28

Matt U.

10-Oct-11 15:28

I am writing an in-house application at work which stores data in SQL Server 2008 Express. In the application's database I have a table which contains user accounts and each user is assigned to a role. A few of the role titles: Administrator, Supervisor, Lead and so on. Depending on the user's role, I need to enable/disable certain elements, hide/show certain elements, etc. What is the best method to use in this situation?

I have seen a few from Google results, such as adding the role-based controls to a list and toggling them as necessary. But is that the most efficient method? What do you think?

djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

David Skelly10-Oct-11 22:14

David Skelly

10-Oct-11 22:14

Do I really need to say, "It depends"? How many forms are you talking about, how many controls on each form, how many different roles, how often do you add new roles, how often do the requirements for existing roles change, do the end user administrators need to be in control of this themselves or is it OK for it to go back to the developers each time a change is required, does it matter if hidden fields leave ugly gaps on the form, or is the aesthetics of the thing important, can a user be in more than one role at the same time, and there are probably lots more considerations which will affect your decision.

Matt U.11-Oct-11 1:56

Matt U.

11-Oct-11 1:56

The only form which will be affected is the main application form. It will not contain a ton of controls but it will contain some buttons, some menu items and some toolstrip items. There will be 4 or 5 roles which never change, there will be no need to add new roles and the requirements for each role will never change. Each user will only be part of one role at a time.

Hidden controls, unlike what I initially stated, will probably not be necessary aside from menu/toolstrip items. The only items I need to hide will be menu and toolstrip items, in which case the layout will change accordingly to place items in their new position.

I implemented this in a previous project. But there was a lot of "if role is Administrator then enable/show these controls; if role is Supervisor then enable/show only these controls; etc; etc". That became tedious after a while. So I am looking for a better solution.

djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

Wayne Gaylard11-Oct-11 2:16

Wayne Gaylard

11-Oct-11 2:16

Create another class called Permissions or something similar. In that class you would have boolean properties which correspond to each permission you would like. Then in your role class you would have a property permissions, which would return a permissions class with appropriate permissions set. Then each user would be assigned a role, which would have the permissions set. Then in you application you couls have a currentuser property, who would have their role with permissions, and so you could just enable buttons/menuitems according to the permissions. Here is a simple example:-

public partial class Form1 : Form
    {
        User currentUser;

        public Form1()
        {
            InitializeComponent();
            btnAddNewDoc.Enabled = currentUser.CurrentUserRole.Permissions.CanAddNewDoc;
        }
    }


    class User
    {
        public int UserID { get; set; }
        public string UserName { get; set; }
        public UserRole CurrentUserRole { get; set; }
    }

    class UserRole
    {
        public string RoleName { get; set; }
        public RolePermissions Permissions { get; set; }
    }

    class RolePermissions
    {
        public bool CanAddNewDoc { get; set; }
        public bool CanDeleteDoc { get; set; }
    }

When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman

Matt U.11-Oct-11 3:06

Matt U.

11-Oct-11 3:06

Oh wow, thanks a lot. I will keep this in mind. The concept is quite simple really and I can easily create my own classes based on this idea. Thanks a lot, Wayne.

djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

Wayne Gaylard11-Oct-11 3:16

Wayne Gaylard

11-Oct-11 3:16

Glad to help.

When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman

BobJanova11-Oct-11 3:15

BobJanova

11-Oct-11 3:15

Good answer.

As an extension to this, you can then data bind the Enabled property to User.CurrentUserRole.CanXxx (at least in WPF/Silverlight, I think that works in WinForms too).

(By the way I'd just call that property User.Role. I like brevity Wink | ;)

Wayne Gaylard11-Oct-11 3:23

Wayne Gaylard

11-Oct-11 3:23

Thanks. In WPF an easier way is to use this in your RelayCommand, something like this:-

public RelayCommand DeleteFileCommand
        {
            get
            {
                return new RelayCommand(() => DeleteFile(), () => CanDeleteFile());
            }
        }

        void DeleteFile()
        {
            //delete file here
        }

        bool CanDeleteFile()
        {
            return currentUser.Role.Permissions.CanDeleteFile;
        }

and then your button is automagically disabled Big Grin | :-D

When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman

BillWoodruff11-Oct-11 7:09

How 'cheap' is recursive use of variables ?

11-Oct-11 7:09

Matt U. wrote:
The only items I need to hide will be menu and toolstrip items, in which case the layout will change accordingly to place items in their new position.

Addressing this part of your design only: have you considered having a container control place-holder on your client UI, and having three separate UserControls, one for each Role, which then are inserted into the place-holder based on Role ? Save you layout calculations: makes it easy to modify/maintain Role UI's ?

A good question, and Wayne's answers are great !

"Use the word 'cybernetics,' Norbert, because nobody knows what it means. This will always put you at an advantage in arguments." Claude Shannon (Information Theory scientist): letter to Norbert Weiner of M.I.T., circa 1940

BillWoodruff10-Oct-11 15:22

10-Oct-11 15:22

I was answering a question here on CP with a recursive solution[^], and I realized I had never really thought about the internal memory use of variables ... which contain constant values at run-time ... in the parameter list of the recursive call in C#.

Now I do remember (dimly) from computer-science daze of yore that recursion uses stacks, and so forth. But, on a practical level in today's .NET C#, is there any real benefit from declaring constant value variables outside the recursive call vs. having them in the parameter list ? Example:

private void SetControlsEnabledProperty(bool isEnabled, bool isRecursive, string typeToCheck, Control.ControlCollection theControls)
    {
        foreach (Control theControl in theControls)
        {
            // edited here: removed duplicate line inserted by mistake

            // is there a better way to handle the
            // the type checking required here ?
            if (theControl.GetType().Name == typeToCheck)
            {
                theControl.Enabled = isEnabled;
            }
            else
            {
                if (isRecursive && theControl.HasChildren)
                {
                    SetControlsEnabledProperty(isEnabled, isRecursive, typeToCheck, theControl.Controls);
                }
            }
        }
    }
}

In this code there are three variables whose constant-values are set by the calling code: can I assume the compiler recognizes this and does some kind of optimization; or is it possible that there may be some real benefit to defining those constant-value variables outside the recursive call ? As in

private void EnableAllTextBoxes()
{
   bool isEnabled = true; // enable all the controls
   bool isRecursive = true; // handle nested controls
   string typeToCheck = "TextBox"

   SetControlsEnabledProperty(Control.ControlCollection theControls);
}

thanks, Bill

modified 11-Oct-11 2:04am.

Luc Pattyn10-Oct-11 15:57

Luc Pattyn

10-Oct-11 15:57

More method parameters means more bytes and more cycles, there isn't much the compiler can do about that. It has to obey the signature and semantics of the method, there could be other callers using non-const values.

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum
iSad

BillWoodruff10-Oct-11 20:19

10-Oct-11 20:19

Hi, I'm going to ask a friend of mine who is fluent in IL ... I'm not ... to look under-the-hood for me, and tell me if there is any optimization ... but I doubt there is. But, I have underestimated the C# compiler before: I did not realize until I asked I learned here on this forum that the switch/case statement, given an integer case-selector in a continuous range, generates a totally efficient IL jump table Smile | :)

thanks, Bill

PIEBALDconsult10-Oct-11 16:00

PIEBALDconsult

10-Oct-11 16:00

I don't think I've given it any thought either -- until now.

I suppose the parameters would get copied each time, unless the compiler is smart enough.

BillWoodruff wrote:
if (theControl.GetType().Name == typeToCheck)

TypeTransmogrifier[^]

BillWoodruff10-Oct-11 20:15

10-Oct-11 20:15

Hi, My guess is that it would be very difficult for a compiler to analyze code for any possible change of a variable's value in a recursive call ... a huge possibility matrix comes to mind ... but then I'm not a compiler-writer Smile | :)

I'm not fluent enough in IL to look under-the-hood and see what's going on.

I have studied ... in the sense of reading other people's explanations ... how the C# compiler optimizes switch/case statements, and the range of implementations/optimizations is quite fascinating.

I read your TypeTransmogrifier article with interest; I am curious if now, a few years later, you'd use the same techniques and code.

best, Bill

PIEBALDconsult11-Oct-11 2:33

PIEBALDconsult

11-Oct-11 2:33

BillWoodruff wrote:
use the same techniques and code.

Oh yes, but I don't need it very often.

BobJanova11-Oct-11 1:39

BobJanova

11-Oct-11 1:39

I'm fairly sure that it does cost those parameters on the stack each time. That's going to be 4b or so per parameter, I guess, if they're reference types, so it is a fairly minor cost, and compared to the time and resources of doing a recursive call in the first place, it's not really worth worrying about.

I'm not sure if the C# compiler optimises tail recursion (i.e. calling yourself on the last functional line of a code path), which can essentially be turned into a 'goto 1;' with some parameter reassignments and avoid the cost of a new function frame entirely.

harold aptroot11-Oct-11 2:54

harold aptroot

11-Oct-11 2:54

For the type checking, directly comparing types (instead of the name) is actually better optimized in many case (though not all). Do you have access to the actual type to check against?

BillWoodruff11-Oct-11 7:28