|
Why do you make it so complicated, I would manage the visibility based on the users group. If they don't have permission then don't show the tab or disable the tab.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Good Idea.. Thank you, but where do i write the conditional statement?
Just a little illustration please
|
|
|
|
|
In the form load method you check the current users credentials and set the visibiility/disable the tabs according to the users creds.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
That would be a security-leak; one can re-enable the tab with ManagedSpy[^].
Bastard Programmer from Hell 
|
|
|
|
|
If any of my users are capable of using such a tool and are caught circumventing an applications security I will get them fired. I write corporate software not highly secure commercial applications.
It is assumed that if you work for the organisation you abide by their ethics and rules, you don't try and hack the solutions we supply to make your life simpler!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: I write corporate software not highly secure commercial applications.
I was under the assumption that those are the same; If you trust your users, then why go through the bother of hiding it at all?
Getting fired might not be that much of a punishment, if someone is being paid by the competition to destroy the database. ..and it might be "hard" to catch them circumventing security.
Call me paranoid.
Bastard Programmer from Hell
|
|
|
|
|
Eddy Vluggen wrote: I was under the assumption that those are the same;
No they are vastly different, inside the firewall you have higher level of control over what the app does, in the wild the requirements will be dramatically wider and there is less tolerance of errors (not necessarily bugs).
As to trusting the users, bloody hell no, but they do know hacking the systems carry a load of retribution, sacking being the least. If a user acquires a specialist peice of software who primary use is to circumvent the internal security of an app they are way outside the bounds of acceptable activity. They would need to be paid very well with a long term prospect of collecting.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: No they are vastly different, inside the firewall you have higher level of control
Someone might temporarily disable the firewall to diagnose connection-problems. Or buy a PC with a rootkit.
Mycroft Holmes wrote: If a user acquires a specialist peice of software who primary use is to circumvent the internal security of an app they are way outside the bounds of acceptable activity. They would need to be paid very well with a long term prospect of collecting.
Provided you know which user it was, and that's assuming it's an employee.
Bastard Programmer from Hell
|
|
|
|
|
We are using Spring Frame work in C#.
We have a stored proc calling another stored proc.
In Web Config there is definition of the property of the first SP. In its definition we have the property of the SP called inside this first SP.
How to define the second SP in web config?
When I put the property as in second block I am getting error.
Basically we have Class A having a property of Interface and a class implements the interface which the Stored Proc A. In Stored Proc A there is one more property that is for another Sp call. Need to know how to define web config for it.
<object id ="CustDetailsForTaxIdService" type="CustDetailsForTaxIdService, Service" >
<property name="ControlPersonDao" ref="ControlPersonStoredProcedure" />
<object id="ControlPersonStoredProcedure" type="Spring.Aop.Framework.ProxyFactoryObject" >
<property name="ControlPersonItemDao" ref="ControlPersonItemStoredProcedure" />
Thanks any help will be appreciated.
|
|
|
|
|
Since I've done all my learning the hard way - buying lots of books and surfing CodeProject, most of the examples I see are short ones, meant to illustrate a concept. The usual routine is to fire up VS, create a new project, and do all the coding on one form. But that seems cluttered to me for a real program.
I'm revisiting a project I started a while back, and it uses a main form for user interaction, but does a lot of background stuff that just clutters up the form code. For instance, one routine strips all the quotation marks out of a string so that I can later use the Split function to break up the fields in the string. It was convenient to debug it on the main form, but now that it works, it's just making the form code hard to follow. I don't have enough stuff to justify a library, but I'm wondering where it would be good to shove such things. Should I make a new class that contains all the helper functions? Or stuff these things in the nearly empty Program.cs file? Or something else?
What's the usual practice?
Will Rogers never met me.
|
|
|
|
|
Roger Wright wrote: make a new class
I usually create a "Utility" class that contains such functions.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
|
|
|
|
|
You beat me to it; I was going to suggest that. The second suggestion I was going to make is separation of the GUI code and the process code.
I did a project where it seemed simplest at the time to put all the process code in the Form class. Predictably the Form class got cluttered (but adding #regions helped).
I later realized having the Form class just send messages to a process class would have simplified it.
Then I realized another benefit of separating the classes: Separating would have made adding a scripting capability much easier; just have the scripting class send messages to the process class (just like the GUI).
Lesson: Separating functionality promotes simplicity (except when you pay for it with increased complexity from the communications between the classes).
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
|
|
|
|
|
While this is true, "Utility" class tend to morph into blob antipattern very quickly. Which is the problem he is now facing with the main form.
You can only be young once. But you can always be immature.
- Dave Barry
|
|
|
|
|
Fortunately, I anticipated the problem and asked the question here. The answers are about what I expected, but I wanted the experience of more seasoned programmers before I cast off on a new course. At this point, I've got a Utilities file containing the one routine I've been discussing here, but there will be others. Just to avoid what you're describing, I plan to limit this file to text-related functions, and add more files if I need other types of helper functions, like database functions.
Will Rogers never met me.
|
|
|
|
|
Stuffing these things into Program.cs would be an unusual practice. 
If the driving reason is too much code in main form file, you might consider leaving the actual GUI stuff there (button click handlers, load event handler, closing event handler, etc) and moving the other functions to another file. It could be another "partial class" of the main form (probably another unusual practice) or a new class of helper functions as your suggested. It really depends on your design and needs.
I predict that will be a concensus: it's up to you.
BDF
I often make very large prints from unexposed film, and every one of them turns out to be a picture of myself as I once dreamed I would be.
-- BillWoodruff
|
|
|
|
|
Big Daddy Farang wrote: Stuffing these things into Program.cs would be an unusual practice.
Yes, but it's nearly empty, and I hate wasting space. 
Will Rogers never met me.
|
|
|
|
|
Such library routines I put in their own files. I can then make a Library DLL from them or include them individually as necessary.
If you need it in this project, you'll need it in another. A stitch in time saves nine.
|
|
|
|
|
PIEBALDconsult wrote: If you need it in this project, you'll need it in another.
Maybe. It typically takes me several years to complete a project. I get an idea for something useful. I spend four days (nights, actually) developing the framework. I get busy with other things, like work, and don't have time to touch the project. Months pass, then I have a chance to get back to it, but I've forgotten much of what I did and why. In the meantime, Microsoft has released a new buzzword into the wild, and my way of approaching the problem no longer fits, so I have to start over. A few days later I get busy again. And the cycle repeats. That's why I'm always a beginner, and ask the same questions over and over again... 
Will Rogers never met me.
|
|
|
|
|
If you just want to store them in a convenient location where you can get to them later on, if you need them, then you could always store them in an online snippet store. If you look at my article history, you'll find details of just such a one. If you want to store them in a convenient location for use in the project, I tend to have a little Utility class that I use.
|
|
|
|
|
I don't plan to reuse them, I just want them out of my sight when I'm trying to figure out what my Form is doing. I find it handy to debug them in the Form, but once they work, I don't want to look at them anymore. I created a Utilities class in a separate file tonight, then cut and pasted the material from the Form to the Utilities file. That should work for now.
Will Rogers never met me.
|
|
|
|
|
If I'm not going to reuse stuff, then I usually leave it in the form code but make a lot of use of #regions.
Group my UI stuff, BGW stuff, Logging, Helper methods, etc into seperate regions. Whatever makes sense. I then collapse all the regions and just look at the bits that interest me at the time.
|
|
|
|
|
RCoate wrote: just look at the bits that interest me at the time
Yes, but what does that have to do with code?
|
|
|
|
|
One man's formatting is another man's ASCII pr0n. 
Will Rogers never met me.
|
|
|
|
|
I completely forgot about Regions, and that's a perfectly good use for them. We didn't need no stinkin' regions back when I was punching Hollerith cards for FORTRAN programs, and I forgot that we have that option. Still, it does seem kludgy to me to keep details like that in the main Form file. I like a nice, clean file that treats functions like well known old friends, to be called when convenient, but otherwise out of sight.
Will Rogers never met me.
|
|
|
|
|
That's a great question.
I'd go with a helper class. Over the years I've built a slew of helper classes (each with just a few methods) for working with everything from strings to controls like ListView, TreeView, ListBox, etc. I get a lot of code reuse from them and find them indispensable.
/ravi
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
