|
5 seconds?!?! My machine must be blessed...
|
|
|
|
|
Some more direct advice if you're starting out. While programming in this country will take a down turn until this recession (or whatever it is) has ended, you can still get work in multimedia stuff. I recommend you get your teeth into Macromedia stuff (you can get a 30 day license on a free download of Studio MX 8.5). You should also take a look at DirectX if you want to go low level. This is essential for game writing (along with OpenGL).
The primary language for game writing is C or C++, but you can experiment in all sorts of languages, even Visual Basic! However until the official release of DirectX 9 SDK for .NET, I suggest you might want to get yourself a copy of C++ from Studio 6 (Standard edition should do I think). In fact if I were writing a game today I would consider Studio 6 ahead of Studio .NET (that comment may raise some controversy!)
I think in the long run that programmer salaries are set to fall a long way. We cannot compete with WiPro in Indian, and coders in China or Thailand. So if you are here in the USA you want to aim to get out of low-level programming as quickly as possible. Analyst, specialist, or something which requires close customer interaction. These domains are more difficult for overseas companies to dominate!
Gaming engines are really powerful and you can download any number of them. Most support C or C++ interfaces, some have their own associated language. Many of them are free (although if you want to use the engine commerically you may have to pay).
And finally, if you're bored, there is Cg from NVIDIA. This is a free download (C for graphics) and I have used this myself. It is fun, insightful if you're starting out, but I doubt it has a long term future (I might be wrong however as gaming is just a hobby for me).
Incidentally, if you check out your bookstore, there are many books on game writing and on AI for games. Personally I would like to find an AI which can adapt to my style of playing. Because I can easily wipe out the enemies at SOFII at the maximum setting, but everytime I go online I die!
Only change is constant
|
|
|
|
|
Vipermmx wrote:
Im REALLY new to all this and want to start programming. I want to start on either C++ or C#. My friends have told me to go for C# as it will be used more often in afew years and its easier to get started on and has good support.
I found by learning C# i pickup on C/C++ to the point where i code easily (not always) read C/C++. Java didnt have this affect on me.
DirectX9 does contains managed functions, but this not managed DX, this is merely a managed wrapper for DX. According to sources, this will have about a 5% preformance overhead.
I would really recommend starting on C# (speaking from own experience, and multiple failed attempts at C++) and then once you have formed a solid base, move on from there. Like said above, dont expect miracles. You will need at least 6 months solid experience in C# before moving on.
Hope this helps 
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info. 
|
|
|
|
|
Thanks all for the helpful advice. I will start out on C# and move on from there. I just need to get my head in the door and understand how programming works. If I get skilled in C# it should be possible to move on to others alot easier then not knowing.
Ill go with C# then once fully skilled see where I go from there. Ive always wanted to go the Assem route of programming. Lots of skill and a very powerful language.
|
|
|
|
|
So I am a total newbie. Tell me why this doesnt work. I dont know what to do anymore. notice; the second time I click this button the calling App closes and the instance runs anyway
please help
private Mutex m_myMutex = null;
private void button1_Click(object sender, System.EventArgs e)
{
bool blnGotIt;
m_myMutex = new Mutex(true, "aa", out blnGotIt );
if (!blnGotIt) this.Close();
Process aa = new Process();
aa.StartInfo.FileName = "C:\\Winnt\\System32\\calc.exe";
aa.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
aa.Start();
//aa.WaitForExit();
aa.Close();
}
|
|
|
|
|
The first time you click, your m_myMutex gets set, the second time, it tries to get it again but fails as it already exists; that is the Mutex already exists. I don't know what you're trying to do but an "if (!m_myMutex==null)" around the assignment and bool check would stop that behavior. Or you may just want to "return" instead of "this.Close()".
|
|
|
|
|
thanks. looks like you did it (return; tip). alltho now I can only start it once. Each new click doesnt start the app again even if I closed the first instance down.
|
|
|
|
|
is it possible to find out the names of the controls on a form. e.g.
TextBox tb = new TextBox();<br />
this.Controls.Add(tb);<br />
<br />
..<br />
<br />
<br />
<hr noshade="" width="100%" color="#80BFFF"><p style="margin: 0; padding: 2px; font-size: 8pt; text-align: left">:suss: Email: <a>theeclypse@hotmail.com</a> URL: <a target="_blank" href="http://www.onyeyiri.co.uk">http:
|
|
|
|
|
Object.GetType()
using System;
public class MyBaseClass: Object {
}
public class MyDerivedClass: MyBaseClass {
}
public class Test {
public static void Main() {
MyBaseClass myBase = new MyBaseClass();
MyDerivedClass myDerived = new MyDerivedClass();
object o = myDerived;
MyBaseClass b = myDerived;
Console.WriteLine("mybase: Type is {0}", myBase.GetType());
Console.WriteLine("myDerived: Type is {0}", myDerived.GetType());
Console.WriteLine("object o = myDerived: Type is {0}", o.GetType());
Console.WriteLine("MyBaseClass b = myDerived: Type is {0}", b.GetType());
}
}
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site. Support for development will ship at the same time as the Windows XP Service Pack 1 (SP1) release.
|
|
|
|
|
Hi , you are answering your question
foreach (Control control in this.Controls)
{
Console.WriteLine(control.Name);
}
Is this what you mean
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
Declare it as a public or protected member.
Mazy
"If I go crazy then will you still
Call me Superman
If I’m alive and well, will you be
There holding my hand
I’ll keep you by my side with
My superhuman might
Kryptonite"Kryptonite-3 Doors Down
|
|
|
|
|
Hello all!
I have the following problem: I have some properties that must not be null. Therefore I thought I should throw an exception in the set accessor if a null value is passed. But what exception? I thought to throw ArgumentNullException but is this a good approach? It's intended to be used in methods after all...
Cheers
and any help appreciated
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
I'd consider a value passed to a property to be an argument.
I tend to think that if you're giving a class invalid information, it's an Argument[Null/Invalid]Exception. If the class already holds invalid information based on what you're trying to achieve, it's an InvalidOperationException.
Paul
|
|
|
|
|
Thanks for the reassuring information !! 
Cheers
have a sunny sunday 
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
Martin,
If you're not already, I would suggest following the conversation that extended in this thread - there's some interesting points being raised on both sides.
P
Paul
|
|
|
|
|
Yeah thanks, codeproject didn't "work" for about one day for me.. 
Cheers
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
Someone else (or maybe you) was talking about this earlier in the Lounge (or maybe the Soapbox). CP has gone down, for an hour or so at a time, several times lately and then there's problems with losing the DNS entries but I didn't really follow it. It's not happening to me and my eyes tend to glass over when I hear anything about DNSes, so I phased out.
Paul
|
|
|
|
|
Exceptions are for exceptional conditions - conditions that are unexpected during normal circumstances. Exceptions are relatively expensive and aren't that great for stuff like this.
I personally would write the class to have a constructor that accepts all required arguments in addition to returning an error (or true/false) on execution of a method that finds a required field that contains null. Perhaps go as far as exposing a public read-only IsValid property and have your internal methods call it - exposing IsValid may also help developers understand how your class works since they can check the object's validity anytime they like.
If you insist on using exceptions, don't throw CLR exceptions(like System.ArgumentNullException - these are CLR-sourced exceptions. You can create your own application-specific exceptions based on the System.ApplicationException class - it exists for people like us to create our own exceptions. Just create your own class and derive it from System.ApplicationException - you don't have to add any members since the catch statement works based on the exception's type.
Erik Westermann
Author, Learn XML In A Weekend (October 2002)
|
|
|
|
|
Erik Westermann wrote:
Exceptions are for exceptional conditions - conditions that are unexpected during normal circumstances.
Wouldn't you say that trying to set something to null that shouldn't ever be null is an exceptional circumstance? The application setting the property SHOULD check for null before setting. If it doesn't then there's nothing wrong with throwing an exception.
I would agree with you that applications shouldn't simply live inside a try/catch structure, just in case. But if a class/component/control receives something it doesn't expect from an app then it should throw an exception.
Erik Westermann wrote:
If you insist on using exceptions, don't throw CLR exceptions(like System.ArgumentNullException - these are CLR-sourced exceptions. You can create your own application-specific exceptions based on the System.ApplicationException class - it exists for people like us to create our own exceptions.
Why would you do that if one already exists that meets the criteria you're looking for? Do things in the Microsoft namespace avoid throwing exceptions from the System namespace?
I'm not meaning to sound argumentative, I'm genuinely interested in people's opinions of good programming practice. The .NET languages are new enough that there is room for discussion; while some things will carry naturally from older languages, I'm not sure exceptions do. They have existed before but not in the same manner they do here.
Paul
|
|
|
|
|
Paul Riley wrote:
Wouldn't you say that trying to set something to null that shouldn't ever be null is an exceptional circumstance?
Have you come across the two pronged plugs that plug into the wall only one way? One prong of the plug is keyed and so is the wall receptacle so that the prong must match the wall receptacle's orientation - this is done to prevent something from being plugged in backwards.
The person that designed the plug expected that someone would eventually try to put the plug into the receptacle the wrong way and took measures to ensure the chances of that happening are much smaller than if he did not design the plug with that possibility in mind. My point is that the plug's designer knew that this could be a problem and wants to prevent the device that's being plugged in from working when the plug is put in the wrong way - this is obviously an expected condition.
I view this scenario the same way - since it is possible to set a property to null and the class requires a non-null value - this is nothing exceptional.
Paul Riley wrote:
Why would you do that if one already exists that meets the criteria you're looking for?
Simply becasue the idea of the .NET Platofrm is to provide a space where all activities occur in a managed, type-safe environment. The System namespace is called "system" becuase it exposes classes that you can use to interact with the "system". If your applicaiton throws an exception, throw an applicaiton-specific exception that's derived from System.ApplicationException to avoid confusion with CLR-generated exceptions.
Moreover, CLR-based exceptions usually need to be dealt with in another way than do application-specific exceptions. For example, if the CLR throws an OutOfMemoryException, you'll have to deal with that differnetly than if an application throws it's own memory-specific exception. In the application's case, the problem could be the result of some fixed capacity buffer becomming full whereas the CLR-based exception obviously indicates a problem that affects the entire system.
Given that the System.ApplicationException class is a derivitave of System.Exception, a catch block that catches a System.Exception type will also catch System.ApplicationException exceptions, thus reducing the chance that an applicaiton-specific exception could be missed.
Erik Westermann
Author, Learn XML In A Weekend (October 2002)
|
|
|
|
|
Erik Westermann wrote:
Have you come across the two pronged plugs that plug into the wall only one way? One prong of the plug is keyed and so is the wall receptacle so that the prong must match the wall receptacle's orientation - this is done to prevent something from being plugged in backwards.
Thank god I've been electrocuted enough times in the US to have the faintest idea what you're talking about... our plugs here in the UK are a sensible three-prong design (one vertical, two horizontal) and there's no way on earth anyone's plugging that in the wrong way around! 
Erik Westermann wrote:
The person that designed the plug expected that someone would eventually try to put the plug into the receptacle the wrong way and took measures to ensure the chances of that happening are much smaller than if he did not design the plug with that possibility in mind.
I would argue that this is exactly what the programmer is trying to do in this example. Someone, eventually, is going to pass null to that property and is not going to call IsValid().
Thus the class designer has to check IsValid all over his own class before doing anything with that property and may still have to throw an exception if this causes a situation that is unacceptable. Not only is this inefficient but it's harder for the app programmer to debug.
Erik Westermann wrote:
this is nothing exceptional
I think to a point this is where our opinions part. You are taking "Exception" in the context of "This is an exception to the rule", I think an "Exception" is better described in the context of the program saying "I take exception to this scenario".
Erik Westermann wrote:
Simply becasue the idea of the .NET Platofrm is to provide a space where all activities occur in a managed, type-safe environment. The System namespace is called "system" becuase it exposes classes that you can use to interact with the "system".
If that were true, why are the fundamental base classes all set in the System namespace? Wouldn't Object and Exception be better placed in a "Core" namespace?
However, I do see an argument (although you never quite said this, I think it was your point) that ArgumentNullException is derived from System.SystemException and if someone is trying to catch system-based problems, they will also catch a program defined ArgumentNullException.
That could be a problem, but I would suggest that trying to catch SystemExceptions like this is a problem in and of itself.
For example, RegistryKey.DeleteSubKeyTree will throw an ArgumentNullException if you pass null instead of a string. To argue that this is a system-level exception is ridiculous, just because the registry is part of the system, it must be an application error that caused the problem.
Paul
|
|
|
|
|
Paul Riley wrote:
I think an "Exception" is better described in the context of the program saying "I take exception to this scenario".
It really depends on what you're designing and what its purpose will be. I'm speaking in the snese of who the immediate user is of course. For example, if you're building a class library, you'll probably end up throwing exceptions since you may have no other means of reporting an error or the best way to handle the error is to let the code that called the code in the class library handle the error.
If you're building an applicaiton or a component that an end user will use then it is probably not a good idea to throw an exception since most typical end users don't know what to do when something 'wierd' happens.
Paul Riley wrote:
Wouldn't Object and Exception be better placed in a "Core" namespace?
That was Microsoft's choice.
Paul Riley wrote:
To argue that this is a system-level exception is ridiculous
It is a system-level exception, System.ArgumentNullException is a derivative of System.SystemException. The naming standard appears to focus on the source of the exception, not the entity that casued it.
Erik Westermann
Author, Learn XML In A Weekend (October 2002)
|
|
|
|
|
Erik Westermann wrote:
It really depends on what you're designing and what its purpose will be. I'm speaking in the snese of who the immediate user is of course. For example, if you're building a class library, you'll probably end up throwing exceptions since you may have no other means of reporting an error or the best way to handle the error is to let the code that called the code in the class library handle the error.
I'd agree with you on both a class and an applicaton. Applications should avoid using Exceptions, though I admit I've been guilty of throwing an exception because I'm in the middle of a try block and want to act the same in the event of this error as I would if it were an exception.
That was, however, an ApplicationException.
I wouldn't agree with you in the case of a component - I don't see how this is different from a class library.
Erik Westermann wrote:
That was Microsoft's choice.
Sure, but it does show a total disregard for the selection of the namespace name "System". I feel you're taking that name a lot more seriously than those who designed it.
Erik Westermann wrote:
It is a system-level exception, System.ArgumentNullException is a derivative of System.SystemException. The naming standard appears to focus on the source of the exception, not the entity that casued it.
Except that an ArgumentNullException is NEVER going to be a result of a system problem, it's ALWAYS going to be a result of erroneous programming.
Thus, trying to catch system problems specifically simply by using catch (System.SystemException ex) is already a dangerous idea.
As Martin has pointed out, what if (for some reason I can't think of right now) you wanted to catch all exceptions caused by null arguments? Is it not unfair to expect people to catch the standard ArgumentNullException plus your ArgumentNullException plus my ArgumentNullException, etc, etc?
Paul
|
|
|
|
|
Now I have used exceptions instead of events, and will make no further comment
Bottom line, you use it where u need it
Paul Riley wrote:
Is it not unfair to expect people to catch the standard ArgumentNullException plus your ArgumentNullException plus my ArgumentNullException, etc, etc?
Say what ? So you say its OK to expect ppl to check for 3 exceptions instead of one, although they check for the same thing? PUDATE: Me dyslexic mind didnt read that right.
|
|
|
|
|
leppie wrote:
Now I have used exceptions instead of events, and will make no further comment
Now that is shoddy coding
leppie wrote:
Say what ? So you say its OK to expect ppl to check for 3 exceptions instead of one, although they check for the same thing? PUDATE: Me dyslexic mind didnt read that right.
 But that's exactly what Erik is suggesting, on the grounds that otherwise anyone trying to catch system-level exceptions will accidentally catch your ArgumentNullexception.
Paul
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
