|
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.
|
|
|
|
|
I too create static utility classes for things which are generic (in the non-technical sense of that word) functions that have nothing to do with your particular problem. De-quoting a string seems like a string utility to me.
|
|
|
|
|
Hi,
I'm trying to convert this string array to byte array. I keep getting exceptions no matter what method I try. I tried following the example on another website, but it's not working and I can't figure out how to get it into my returned byte array. So it takes strings 40, AA, and 00 and puts them in a byte array. Even if I comment out the wBuf addition, it's throwing an exception when I run it.
I'm not sure if I'm showing the string array in the code correctly. It's like this:
dataString =
"40 A8"
"AA A8"
"00 4E"
private int ExtractBytesFromDataSTringArr(string[] dataString, ref byte[] wBuf, ref byte[] sBuf)
{
int line = 0;
string [] dataString= {"40 A8", "AA A8", "00 4E"};
for (int i=0; i < myStringArr.Length; i++)
{
delimitedChar = ' ';
stringArray = dataString[i].Split(new char[] {delimitedChar}, StringSplitOptions.RemoveEmptyEntries);
int NumberChars = dataString[0].Length;
byte[] byteArr = new byte[NumberChars/2];
for (int j = 0; j < NumberChars; j+=2)
{
byteArr[j/2] = Convert.ToByte(dataString[0].Substring(j,2), 16);
wBuf[line] += byteArr;
}
line++;
}
|
|
|
|
|
It seems you split dataString[i] to form stringArray, but then don't access that. Your call to dataString[0].Substring(j,2) should probably be for stringArray, but I don't think you need to deal with the digits separately anyway (I think what you're doing with them is probably wrong); how about something like:
wBuf[line++] = System.Byte.Parse
(
stringArray [ j ]
,
System.Globalization.NumberStyles.HexNumber
,
null
) ;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
