|
Unless you are going to work through a tutorial/example then the first thing you need is an IDEA! What are you going to build, what is it going to achieve, why and how.
Once you have that it will define your research scope.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I was thinking something like a shopping system of some kind. Where you can register as a customer browser items and make orders.
if I google this kind of project I find lods of diffrent people doing them but I can seem to find one where there is an easy explanation of whats going on and why.
thanks for the reply !
|
|
|
|
|
You are in trouble already, you start off by wanting to build a desktop application and then want to build a shopping system which is a web based application. You need to clarify your thinking!
The stuff you are looking at are probably fully fledged applications and you will struggle trying to swallow the lot in one go. Decide on your platform/application and break it down to small jobs.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Okay, I thought maybe a desktop application was a bit easier to work with then a web based one when learning, but I guess i was wrong. ill do that! thanks for the advice!
|
|
|
|
|
No you are correct that a desktop app will be easier to build, it is just that Shopping is not a desktop application. Think of single user or networked applications.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Okay, I just wanted to do it for training purposes not really implement a "real" shop. but I guess you are right. ill figure something else out! but as someone else said Im overthinking what I can do. Im better doing some really simple small projects first to get my mind going in the right way of thinking! and then build from there  thanks
|
|
|
|
|
Im my humble opinion, computer programming comprises two parts: the language part and the implementation part.
1. Learning the language is relatively easier as the syntax and scope are static, specific, and limited. This can be achieved through reading books, attending courses, or self-study.
2. Implementation is harder as it involves analysis of problems, formulation of problem solving strategies/algorithms into computer programs that are executable by a computer to produce desired outcomes effectively and efficiently. Implementation skills are generic, that is they are independent of programming languages.
In a nut shell, programming languages are just media of implementation for a computer program, the real challenge lies in their effective and efficient utilization in problem solving and this can only be achieve through hands-on practices.
Can you claim to be a swimmer after reading some manuals and watching some video on swimming lessons? Most likely not. The real learning only happens when you get yourself wet in the pool.
So, shift yourself into hands-on mode, start with a simple problem (e.g. number sorting, fibonacci series), formulate the problem solving logic and translate it into a computer program. Do not afraid of making mistakes as mistakes help your learn correctly.
When you are stuck, do not too quick to ask for help, try to find the solution by yourself first. You immediate help-line should be Google, next CP.
When you become more confident and experienced, you may then embark on some serious project.
Wish you success.
|
|
|
|
|
Thank you so much for writing this it puts things in another perspective. Ill follow your advice and some some simple things first !
Thanks again!
|
|
|
|
|
You need an IDEA as someone mentioned. I would go for something like a movie database or CD collection database.
Then you immediately come up with some problems. You've hopefully read about n-tier design. Let's start with that.
Problem #1: How am I going to store the data? ASCII files, Excel, XML or a database (MySQL, PostgreSQL are free as is SQL Server Express) Start with choosing the type of storage.
Problem #2: Storage structure. Probably something you haven't read. Start here[^]
Problem #3: DAL: You'll need to talk to the database, whatever type you choose you'll need to find out how to do that. here's where the coding starts. Start with reading out the data and check if it works by debugging or doing an output to the cmd window (no UI yet!)
Problem #4: DAL: You can talk to the database, can you write to it? Make a unit test or something that adds and updates entries.
Problem #5: BL: Setup constraints and check of your input and output. Create objects you'll need to use and business rules to follow. You can create objects within objects. So eg you can have a DVD object that contains title, duration, ... but also an Actor object that in turn contains lastname, firstname, age, ... For those objects I would use Load and Save functions (save = insert or update depending if the object already existed).
Problem #6: GUI: How would you like to represent the data? With covers and pictures, without? In a grid or with "cards" (or both) will it be web or winforms or wpf? Can you print it?
This is just high level, but the point is to tackle each problem at a time.
If you want to build CRUD applications a DVD/CD collection is a good example. If you want to go into gaming, you'll need GDI+ and keyboard/mouse input/output. In that case snake, mastermind or a card game or something like that is a better option.
Hope this helps.
|
|
|
|
|
Thank you so much for taking the time to write this! This is some really good information and made it a bit more clear how to do start!
This might be another stupid question but Im currently using Visual studio and I have the option to add an Service-based Database, is that a good option? Ive done some googleing and from what I understand they are ok when working on smaller projects.
|
|
|
|
|
FilipJ wrote: Service-based Database
doesn't really matter. Actually if what I read I've read is correct a service based database is a more "real-life" database, where a compact database will be more used for home projects .
|
|
|
|
|
Okay, thank you for helping me !
|
|
|
|
|
FilipJ wrote: This is the first time im trying to learn to code
I have good news and bad news for you.
First the good news: you're embarking on a path that is likely to prove interesting, satisfying and rewarding, and will hopefully open the door to a great new career. 
Next, the bad news: you seem to have bitten off more than you can chew. I suggest you take small steps first - learn programming (and C#) by building small, very focused console applications. A console app runs in a command window and has no GUI. The purpose of this multi-month long exercise is to become familiar with programming in general, as well as the rich .NET framework.
- Start by building trivial applications that perform simple math calculations (e.g. addition, multiplication, identifying unique numbers in a collection, etc.)
- Next, get to know how to process character strings.
- Along the way, introduce yourself to the different types of collections (lists, arrays, dictionaries, sets) and see how and where they're used.
- Then, take a step into LINQ (Language Integrate Query Language) and see how LINQ makes it easy to do the things you did manually when you started working with collections.
- Get to know to read and write files (text files, binary files and compressed files).
- Then, introduce yourself to XML serialization and learn how to store and retrieved structured data from an XML file.
- Next, discover simple data access from a database and introduce yourself to the basics of SQL.
- Dip your toes into the wonderful world of fetching data from the internet and learn how to use the
HttpClient class.
By this time, you'll have enough under your belt to move from a command line app to building one with a GUI. I recommend starting out with Windows Forms - although an older technology, it offers an easy way to learn event driven programming, which is different from sequential user-directed programming.
I guarantee you hours of frustration, punctuated with moments of sheer joy. Feel free to ask questions of the CP community. We're a helpful bunch of guys and gals and will try our best to assist whenever we can.
/ravi
|
|
|
|
|
My first project (Not too long ago) was a utility to organize files on my disk. it was a console application. all it did was create a folder for each Document file type pdf doc txt in my documents folder and then search my hard drive and move the files to the respective folders.
It doesn't have to be a hard project to see if you like doing this kind of stuff.
Hope this gives you a few Idea's.
David
|
|
|
|
|
As a self taught ameture in c#, I have never found a reason to implement a struct instead of a class.
Since I am self taught (No formal education) I would like to know what advantage would be gained by using a struct in lieu of a class? More importantly why when and where would it benefit my programs?
To this point I have created applications for my own use or for my family. simple utilities and a few web applications.
Thanks in advance for any input.
David
|
|
|
|
|
|
That's a lot bigger question that you probably thought - it involves a lot of background before you can make a decision to use one or the other. So, let's have a little (hah - it was quite a lot) background...
Struct and Class have one huge difference: struct is a value type, class is a reference type. What that means is simple to describe, but harder to grasp the significance of.
So let's start by defining one of each:
public class MyClass
{
public int I;
public int J;
}
public struct MyStruct
{
public int I;
public int J;
}The two objects are identical, except that one is a class and one is a struct. Which means that if you declare an instance of each in your code then you get a reference and a value, but the code can look the same:
public void UseClassAndStruct()
{
MyClass mc = new MyClass();
mc.I = 1;
mc.J = 2;
MyStruct ms = new MyStruct();
ms.I = 1;
ms.J = 2;
}Or slightly different:
public void UseClassAndStruct()
{
MyClass mc = new MyClass();
mc.I = 1;
mc.J = 2;
MyStruct ms;
ms.I = 1;
ms.J = 2;
}Because you don't have to use the new keyword with structs. If you do, then the struct constructor is called, if you don't it isn't - simple as that. Unlike a class, the name of the struct is the struct itself, it is not a "pointer" to a instance.
And that's important, because that is the whole point: a struct is the object, and class is a reference to the object.
When you create a class variable:
MyClass mc; That allocates memory on the stack to hold a reference to a MyClass instance in future, it does not create an instance of MyClass, and you will have seen that before when you try to use any property or method of a class and you get a "Object reference not set to an instance of an object" exception and your program crashes. You have to explicitly create an instance of the class by using the new keyword:
mc = new MyClass(); What this does is create a new instance of MyClass on the heap, and assign the reference to it to the variable mc. This is important, because the stack and the heap are different "types" of memory: the heap is a big "lump" or memory which is sorted out by the Garbage collector and all classes, methods and threads share it. The stack on the other hand is specific to a thread, and everything on the stack is discarded when you exit the method - which means that the mc variable is lost, but the data it references is not - if you have copied the reference to a variable outside the method, then you can still access it from the rest of your program.
What happens when you create a struct variable is different: the actual struct is immediately created on the stack and is available directly for the lifetime of the method. But it will be thrown away when the method exits. So you don't need the new unless you want to use a struct constructor to initialise your fields. You've used this a lot - probably without noticing:
int i;
double j;
Point p; All create value types.
So that's it? Not quite. Remember I said that "the name of the struct is the struct itself, it is not a 'pointer' to a instance"? That has a big effect, which again you probably have used a lot, and not really noticed. Think about this:
int i = 3;
int j = i;
i = 4;
Console.WriteLine("{0}:{1}", i, j);What does that produce?
Obviously, it produces a string "4:3" - anything else would make coding very, very difficult!
But...what if we do that with reference types?
MyClass i = new MyClass();
i.I = 3;
MyClass j = i;
i.I = 4;
Console.WriteLine("{0},{1}", i.I, j.I);
This time, it prints "4:4" because i and j are references to the same instance in memory, instead of being separate, self contained value types.
The same thing happens if we use our structs:
MyStruct i = new MyStruct();
i.I = 3;
MyStruct j = i;
i.I = 4;
Console.WriteLine("{0},{1}", i.I, j.I);This time, we get "4:3" again.
When you assign a reference type variable to another reference type variable, it copies the reference, not the object. When you assign a value type variable to another value type, it copies the content of the object, not the reference to the object.
So when you call a method with a reference type, a copy of the reference is passed, and any changes you make affect the one and only object.
If you call it with a value type such as a struct, a copy of the value is passed, and any changes you make will not be reflected back:
public void ClassMod(MyClass mc)
{
mc.I += 100;
Console.WriteLine(mc.I);
}
public void StructMod(MyStruct ms)
{
ms.I += 100;
Console.WriteLine(ms.I);
}
MyClass mc = new MyClass();
mc.I = 3;
ClassMod(mc);
MyStruct ms = new MyStruct();
ms.I = 3;
StructMod(ms);
Console.WriteLine("{0},{1}", mc.I, ms.I);What do we get?
103
103
103,3 Within the method, everything works the same.
But outside...the changes we made to the struct inside the method affect the copy, not the original.
So what does this do for us in practice? What are the advantages of a struct over a class?
Speed, under certain conditions. they can be a lot slower to use if you aren't careful: if you have a large struct, just calling a method and passing it as a parameter means it must be copied which takes time. But...if they are small (16 bytes or less) and you use a lot of them then they can be a lot faster than a reference type, because the Heap is not involved. Every time you create a reference type instance, the heap must be looked at, a suitable size bit of memory found and allocated and a reference to that returned. This takes time - quite a lot of it! A value type in contrast takes almost no work to allocate: copy the stack pointer, add the size of the struct to it for next time is pretty much all you have to do (and you have to do that for reference types as well so you have somewhere to store the reference to the heap memory!)
There is one bit I missed out here: boxing. This was deliberate, because it's a bit difficult to explain...
What happens when you have a value type and you want to store it with other types in a mixed List (for example)?
List<object> mixedList = new List<object>();
You can add any object perfectly happily:
mixedList.Add("Hello there");
mixedList.Add(Form1);because object is a class that all reference types derive from. But...what happens here:
mixedList.Add(12); Um...12 is an int which is a value type, and so isn't derived from object...is it?
Yes, it is: all value types derive from a special class called System.ValueType, which derives from object and what happens is that the value is "boxed" - a reference is created on the heap to hold the value type and it is copied there, and the reference to the boxed value is added to the list. When you cast it back to the original struct it is "unboxed" and you have a value type again. This is not a fast process and is one of the reasons you don't use structs for everything!
So, to copy from MSDN[^]:
"CONSIDER defining a struct instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects.
AVOID defining a struct unless the type has all of the following characteristics:
It logically represents a single value, similar to primitive types (int, double, etc.).
It has an instance size under 16 bytes.
It is immutable.
It will not have to be boxed frequently."
The immutable bit is not enforced - it is just a recommendation, otherwise integers, doubles, and so forth wouldn't work! 
But...it's a very good idea to make structs immutable: it causes a lot less confusion.
The Point struct does it by making the X and Y Setters private, so that it is obvious that all Points are different instances and that you don't move the original when you change a copy.
Phew! I need a coffee!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
+5! You could easily copy & paste that into a new Tip/Trick (or even article)
|
|
|
|
|
Pretty good, but Griff, you know ints etc are immutable, right? You can't exactly change the value of 3..
|
|
|
|
|
I've worked with dialects of FORTRAN where you can... 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
They are and they aren't, but that's kinda the advanced school: who needs to know that
i = i + 1; creates a new integer instance and loads a copy into the original location?
Particularly when it doesn't - If you have a look at the IL it fetches the value, increments it, and stores the new value back - no new instance is explicitly created except in the sense that the load removes the early version instance from the stack and then iteh new value is put back in the same place:
.line 14,14 : 13,25 'int i = 777;'
IL_0001: ldc.i4 0x309
IL_0006: stloc.0
.line 15,15 : 13,23 'i = 1 + 1;'
IL_0007: ldloc.0
IL_0008: ldc.i4.1
IL_0009: add
IL_000a: stloc.0
But it does indeed behave as if they were, specifically to prevent constant values being modified by our code!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
I disagree with this analysis on many levels.
Firstly, immutability is about semantics, not implementation, so showing some IL or even assembly doesn't show anything.
Secondly, the semantics of the "add" IL instruction are "pop two values, add them, push result". So if you want to treat stack slots as instances (and I disagree with that as well), the old ones are gone and you have a new one.
Thirdly, extending this sort of analysis to assembly gives absurd conclusions. For example, what happens in "add eax, 1"? Obviously one is added to "eax", but that doesn't mean that if "eax" had the value 0 first that you've just "changed the value of the 0-instance".
|
|
|
|
|
I know what you mean, but...
That's not the way I see immutable: I see it as "can't be changed" which is applicable to the constant values 1, 2, 3, etc., but not to the variables which are initialised to the constant value and operated on from there. I would agree that 1 is immutable - to do otherwise induces madness - but I'm not convinced that variables containing what can also be considered as a constant are immutable. If the physical location is the same, but the content has changed and nothing else, then my feeling is that it has changed and is thus not immutable.
Certainly in the case of string the immutability is obvious (if hidden behind the scenes): once a string is created, it can never be changed again, just copied or deleted - even if the scene changers disguise this and appear to allow it!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
I completely agree that a variable of type int is not immutable, but that doesn't really matter since immutability is a property of a type, not of a variable of that type (obviously a variable is, well, variable).
Funny that you should mention strings, they're less immutable than integers, but most people agree that they should be called immutable anyway because the only way to mutate an instance is by cheating (reflection or unsafe). You can't even mutate an instance of an int by cheating.
modified 17-Feb-14 6:30am.
|
|
|
|
|
OriginalGriff wrote: That's not the way I see immutable:
Similar problem exists with 'const' in C++.
In terms of semantics for that I differentiate between 'binary constant' and 'logical constant'.
The first means that the structure of the memory for the data will not change.
The second means that for a user of the entity that it will not change. And example of this is a class that represents application properties that cannot be changed by the application itself but which use a memory cache which might be refreshed for various reasons.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
