|
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
|
|
|
|
|
I'm new to dealing bigger projects in C#, but recently when I had this situation,I created a new Utility class and made all these functions static. And kept it so generic and independent that I can rip this class off from the project and make a class library.
Seriously dumping code on the main form is a bad idea to me at least. I consider that as the launch platform. And every other functionality I push them out as other classes.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
That seems to be the consensus, and that's what I've done with this bit I have so far. I expect to have some more helper functions to add later as I continue to work on this, so at least I'll have a repository of things I might need again to reference. In the form itself, I'll just stick in a comment to remind me what the function is supposed to do, but keep the details off the form; that seems so much cleaner to me, especially since I'm a perpetual beginner and easily confused.
Will Rogers never met me.
|
|
|
|
|
Like every other developer here I have a utility class(es) that hold these little tools. Caveat, make sure you document the utilities REALLY well, not just what you are doing but why you are doing it. I have the sinking feeling I get when ratting through a utility folder/class and wondering why the hell I would write such a thing.
Also keep you utilities in smaller classes, string, date function, treeview etc all should have their own class, don't shove them into one humongous Utilities.cs
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Rats. You're on to me.
I created a code file called Utilities.cs, added the project's namespace, then added a static class called Utilities. VS bitched and moaned about it without the class declaration, and was quite vexed with me when I tried to include it in the Form file with a using statement. My bad.
Anyway, I'll take your advice to heart, and make more classes if I need other types of functions. For now, I only have the one function, which just strips the quotation marks out of a string variable. That was only necessary because the data source I have quotes every value, including empty ones, then separates them with commas. String.Split() doesn't like that very much, but it works perfectly after I clean the string. Since my source data is all in csv form, I expect that any other functions I need will be related to text handling and belong in the same class, but who knows where this will take me. I still don't know what I want the program to do, just that I know that these daily emails of csv data are doing me no good at all. Once I get them sorted out and stored in SQL Server, I'll figure out what else I want to do with the stuff.
Talk about 'agile' programming... sheesh!
Will Rogers never met me.
|
|
|
|
|
:cough: Rive[^] :cough:
Oh, hey, it's Thursday!
|
|
|
|
|
Great. Now you tell me, after I spent two days on this.
Well actually, a couple of dull hours at work with nothing more interesting to fill them. Don't tell the boss...
Will Rogers never met me.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
