C# Discussion Boards - CodeProject

Re: what is the "game engine"????

13-Sep-11 23:52

A game engine is normally a black box piece of software that handles the internals of game creation, and provides an API for you to work with to create your own games. In a 3D game engine, for instance, the engine will take care of things such as loading textures and models, provide physics capabilities, lighting, etc.

As for where you can get one - there are several available, and there prices range from free up to several hundred thousand pounds depending on their target audience.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

OriginalGriff14-Sep-11 3:10

OriginalGriff

14-Sep-11 3:10

Pete O'Hanlon wrote:
prices range from free up to several hundred thousand pounds

...and from what I can tell, you get what you pay for!

Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.

Manfred R. Bihy: "Looks as if OP is learning resistant."

Re: what is the "game engine"????

molesworth14-Sep-11 7:27

molesworth

14-Sep-11 7:27

OriginalGriff wrote:
...and from what I can tell, you get what you pay for!

Yes, and no Smile | :)

Most of the expensive engines also have free versions for home or hobby use, and some only require licensing if you release a product commercially.

There are also some excellent free engines (oh, and some horrible commercial ones Dead | X|

As an ex-game developer I could tell you some horror stories about well-known engines...).

I'm not going to try to recommend a good engine, but DevMaster has a huge list of what's out there in all categories.

[ I've also just noticed there's a game development forum here now as well! Thumbs Up | :thumbsup:

]

Days spent at sea are not deducted from one's alloted span - Phoenician proverb

GetThreadPreferredUILanguages

marca29213-Sep-11 22:56

marca292

13-Sep-11 22:56

Hi,

I need to get all installed languages on the computer. "Control Panel / Regional and Language / Keyboards and Languages / Display language". How can I get the selected language in .NET?

Our application has language settings for a lot of different languages. If our application don't has support for the selected language in "Display language" then we have to see if we has support for a fallback language.

I tried to use "GetThreadPreferredUILanguages" call and it work fine when I use C++, but I can't get is working on .NET. Is there an .NET call I can use instead to get selected languages and also the fallback languages?

C++ code

C++

wchar_t buf[2323];

wchar_t *pBuf;

ULONG numLangs;

ULONG size= 2323;



GetThreadPreferredUILanguages(MUI_MERGE_USER_FALLBACK, &numLangs, buf, &

C# code

[DllImport("Kernel32.dll", CharSet = CharSet.Auto)]

       static extern System.Boolean GetThreadPreferredUILanguages(

           System.UInt32 dwFlags,

           ref System.UInt32 pulNumLanguages,

           out System.IntPtr pwszLanguagesBuffer,

           ref System.UInt32 pcchLanguagesBuffer

           );





         uint MUI_MERGE_USER_FALLBACK = 0x20;

           uint numLang = 0;

           IntPtr pwszLangBuf = new IntPtr();

           uint langBuf = 2323;

           bool b = GetThreadPreferredUILanguages(MUI_MERGE_USER_FALLBACK, ref numLang, out pwszLangBuf, ref langBuf);



           string tmp = Marshal.PtrToStringAuto(pwszLangBuf

tmp string variable contains only a lot of chinese characters after Marshal.PtrToStringAuto(pwszLangBuf);.

pulNumLanguages and pcchLanguagesBuffer returns the same in both C++ and C#.

See more information about GetThreadPreferredUILanguages on
http://msdn.microsoft.com/en-us/library/dd318128(v=vs.85).aspx[^]

What is wrong?

Regards
Olof

Re: GetThreadPreferredUILanguages

Luc Pattyn14-Sep-11 1:52

Luc Pattyn

14-Sep-11 1:52

Hi,

1. I'm not familiar with GetThreadPreferredUILanguages however I do know a thing or two about P/Invoke, and wrote a little article[^] on the subject. What you need here goes beyond the scope of my article though.

2. Your C# code is not doing what your C code does; in particular you should preallocate the result buffer, as you did with wchar_t buf[2323];. The native function you're calling expects a third parameter pwszLanguagesBuffer that is either a NULL, or a valid pointer to a buffer you provide for it to fill.

3. This seems like a reasonable approach: create a byte buffer, have it pinned (with GCHandle), call the native function, then use some kind of Marshal.PtrToString() for each string you need to extract from the buffer. Free the handle once all strings got extracted.

4. I would recommend you call GetThreadPreferredUILanguages twice, once without an output buffer (IntPtr.Zero), just to get the required buffer length; then the regular call with a sufficient buffer size.

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

Re: GetThreadPreferredUILanguages

BobJanova14-Sep-11 2:14

Where to use Try/Catch block? [modified]

14-Sep-11 2:14

Have a look at the documentation for CultureInfo[^] and related classes.

Adam_Dev13-Sep-11 22:21

13-Sep-11 22:21

Hi
First of all please forgive me, I seem to be having a bit of a mental block! I've been trying to improve my exception handling and error logging.

I have a function ProcessPerson(). Within that function I call a ValidateUser() function. And within that function I call the GetAdmin() function. Would the following be acceptable or if not, how should it be done?

I have omitted unimportant code, so:

//Class 1:
public void ProcessPerson(Request arg)
{
    try
    {
        if(Class2.ValidateUser(arg.Username, arg.Role)
        {
            //Do something
        }
        else
        {
            //log error
        }
    }
    catch(ArgumentNullException ex)
    {
        //log error
    }
    catch(Exception ex)
    {
        //log error
    }
}

//Class 2:
public static bool ValidateUser(string Username, string Role)
{
    try
    {
        using(MyClass myClass = new MyClass())
        {
            if(myClass.GetAdmin(Username, Role)
                return true;
            else
                return false;
        }
    }
    catch
    {
        throw;
    }
}

// MyClass
public bool GetAdmin(string Username, string Role)
{
    // should I do this?
    if(String.IsNullOrWhitespace(Username) || String.IsNullOrWhitespace(Role))
    {
        throw new ArgumentNullException("e.g. Username or Role cannot be null");
    }
    
    try
    {
        using(MyClassAdapter myClassAdapter = new MyClassAdapter ())
        {
            myClassAdapter.GetAdmin(Username, Role); 
        }
    }
    catch(ArgumentNullException ex)
    {
        throw;
    }
    catch(Exception ex)
    {
        throw;
    }
}

Appreciate any help or advice.

Thanks

modified on Wednesday, September 14, 2011 5:01 AM

BobJanova13-Sep-11 22:40

Re: Where to use Try/Catch block? [modified]

13-Sep-11 22:40

try { ... } catch { throw; }

... is by definition pointless. Are you logging within that catch block? I don't think you should do that, though, because it will result in exceptions getting double-logged.

I would say you should trap exceptions at the point where it makes sense to handle them. You can make an argument for that being in ValidateUser (any exception should be 'invalid' i.e. return false), or at the top level call which might produce one (at which time you log the error). But don't catch it in both places.

You should only throw an ArgumentNullException if the argument is actually null – if you want to fail on empty too, it should be an ArgumentException. But 'guards' at the top of a method like that are fine.

Adam_Dev13-Sep-11 23:01

13-Sep-11 23:01

Thanks BobJanova.

The only reason I was using "try { ... } catch { throw; }" was to make sure the original exception was passed on to the top calling method that would handle the exception and log where the exception occurred.

Regarding ValidateUser, you're right, any exception should be invalied (return false) but I know you're not mean to return anything within the catch block correct?

What would you say is best, preempting an error by having a guard at the top or letting the error happen and catching it? I know it's swings and roundabouts really but it feels that if I know the arguments might be null or empty, I should test for it first?

Is this better?:

//Class 1:
public void ProcessPerson(Request arg)
{
    try
    {
        if(Class2.ValidateUser(arg.Username, arg.Role)
        {
            //Do something
        }
        else
        {
            //log error
        }
    }
    catch(Exception ex)
    {
        //log the error
    }
}
 
//Class 2:
public static bool ValidateUser(string Username, string Role)
{
    using(MyClass myClass = new MyClass())
    {
        if(myClass.GetAdmin(Username, Role)
            return true;
        else
            return false;
    }
}
 
// MyClass
public bool GetAdmin(string Username, string Role)
{
    try
    {   
        if (String.IsNullOrWhiteSpace(UserName) || String.IsNullOrWhiteSpace(Role))
                    throw new ArgumentException("Username/Role cannot be empty or null");

        using(MyClassAdapter myClassAdapter = new MyClassAdapter())
        {
            myClassAdapter.GetAdmin(Username, Role); 
        }
        return true;
    }
    catch(ArgumentException ex)
    {
        //log the error
    }
    catch(Exception ex)
    {
        //log the error
    }

    return false;
}

If not, are you able to show me what would be best please?

Thanks a lot for your help.

modified on Wednesday, September 14, 2011 5:14 AM

BobJanova14-Sep-11 2:09

14-Sep-11 2:09

I don't think there's anything particularly wrong with returning from a catch. The rule of thumb is that (as Pete says below) you should catch an exception where you intend to deal with it, and if you consider it dealt with you can return from the function. In this case, the calling code will not know that there was an exception in some lower layer. If you think the calling code should be informed, don't catch the exception and let the calling code deal with it.

What you've done in GetAdmin makes no sense. You're catching the exception you're throwing and doing nothing with it! Don't use exceptions to control the flow of code. If an empty or null user name/role is an error (i.e. in normal operation it should never happen), then throw the exception; if you want it to be valid input, but not an admin, then return false.

The only reason I was using "try { ... } catch { throw; }" was to make sure the original exception was passed on to the top calling method that would handle the exception and log where the exception occurred.

If you don't catch an exception, it automatically propagates up the stack. Handle it where it makes sense to do so, and once only. (Not always true, but generally you should not rethrow an exception.)

Since you included it originally I'm inclined to believe that the null or empty username is an error and GetAdmin, at least, should throw in that case. That means that, logically, it's invalid input to ValidateUser as well, I think, so I'd catch the error at the request level:

// Class1
public void ProcessPerson(Request arg)
{
    try
    {
        if(Class2.ValidateUser(arg.Username, arg.Role)
        {
            //Do something
        }
        else
        {
            // log failure to authenticate
        }
    }
    catch(Exception ex)
    {
        //log the error and create a nice message to the user
    }
}
 
//Class 2:
public static bool ValidateUser(string Username, string Role)
{
    using(MyClass myClass = new MyClass())
    {
        // if ( x ) return true else return false is redundant
        return myClass.GetAdmin(Username, Role);
    }
}
 
// MyClass
public bool GetAdmin(string Username, string Role)
{
    if (String.IsNullOrWhiteSpace(UserName) || String.IsNullOrWhiteSpace(Role))
                throw new ArgumentException("Username/Role cannot be empty or null");

    using(MyClassAdapter myClassAdapter = new MyClassAdapter())
    {
        return myClassAdapter.GetAdmin(Username, Role); 
    }
}

It also seems like there are far too many layers involved in the authentication process. You have Class1 (which receives the request), Class2, MyClass and MyClassAdapter all involved in finding out this simple piece of information (whether a user/role combination is admin). What I typically do is at login time I populate a single UserInfo object which contains the role and user-specific access overrides, and then I can just authenticate like:

if(user != null && user.HasAccess(AccessTypes.Admin)) { ... }

(setting user to null if no user is logged in). HasAccess would look a bit like:

public bool HasAccess(AccessTypes access){
 return access == access & (Access | role.Access & ~RemovedAccess);
}

I'm not sure if you can do that with enums but logically that is what AccessTypes would be, and UserInfo.Access, UserInfo.RemovedAccess and Role.Access would all be of that type. You might have to cast to int or uint to get the bit matching to work.

Pete O'Hanlon13-Sep-11 22:57

Re: Where to use Try/Catch block? [modified]

13-Sep-11 22:57

To be honest, the catch statements in your ValidateUser and GetAdmin methods are completely redundant. In general, if you find yourself using catch/throw without doing anything in there, you have poor code. You should only catch exceptions if you plan to do something with them, e.g. reattempt to acquire a transient resource that you couldn't get and which triggered the exception.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Adam_Dev13-Sep-11 23:10

13-Sep-11 23:10

Thanks Pete.

Would my above post be any better? Or closer to better coding?

I'm just confused really, I think I've read too many articles on exceptions (or maybe not enough infact!). Some have said to deal with exceptions in the method that was called, others have said to let exceptions propagate to the top calling method.

(Or an alternative to the GetUser() function?)

// MyClass
public bool GetAdmin(string Username, string Role)
{
    try
    {   
        if (String.IsNullOrWhiteSpace(UserName) || String.IsNullOrWhiteSpace(Role))
        {
            LogEntry.New("Username/Role cannot be empty or null");
            return false;
        }

        using(MyClassAdapter myClassAdapter = new MyClassAdapter())
        {
            myClassAdapter.GetAdmin(Username, Role); 
        }
        return true;
    }
    catch(Exception ex)
    {
        //log the error
    }
 
    return false;
}

modified on Wednesday, September 14, 2011 5:27 AM

Pete O'Hanlon13-Sep-11 23:50

13-Sep-11 23:50

OK, the simple way to think of this is to only catch an exception at the point at which you intend to do something with it. In the case you have here, you are logging the fact that something went wrong, but does it make sense to allow processing to continue? That's the question you have to ask whenever you are attempting to place exception handling in your code.

For instance, suppose you have some code to write something over TCP, and there's a failure at one point which throws an exception, do you want to attempt to reacquire a connection or abort the processing of that message at that point? The answer to that question indicates whereabouts you want to place your exception handling - if you want to reacquire, you'd handle the exception at a lower level than you would if you just wanted to abort the whole thing and tell the user that there was a problem.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Adam_Dev14-Sep-11 0:26

14-Sep-11 0:26

Thanks Pete, your advice is really helpful.

Ideally when an error occurs I want to log what happened and exit. I guess I could just have one single Try/Catch block in the top calling function and catch either a custom exception and then the general Exception or maybe just the general exception? Would this be acceptable? It just doesn't seem like a clean exit, as opposed to returning false after catching an error, but that may be a misconception?

Thanks.

Luc Pattyn14-Sep-11 2:11

Luc Pattyn

14-Sep-11 2:11

You could have all your methods contain try-catch constructs, and return a success/failure result somehow (that is what the Win32 API has done for as long as Windows exists); the disadvantage is you have to provide all the code to do that, *and* your callers have to explicitly check each and every return value.

Or you could take full advantage of the Exception mechanism, which basically says: if something goes wrong, an Exception will be thrown, and some piece of code is bound to catch it, either in the method itself, or one of the callers higher up in the calling chain; if there are no catchers, then the app will exit. You get all this for free.

So yes, a single try-catch at the top level would allow you to log the exception and exit, although that would be an ungraceful exit (and an app I would not like to use). As others have said, use a local try-catch if and when your catch block is able to resolve the problem, and leave the exception as is if you can't resolve it at that level.

And yes, input checking and throwing explicitly on bad input values is the normal thing to do.

And yes, having a catch block that just contains throw is pointless; having a catch block that contains logging and throw normally results in multiple logging. What I sometimes do is catch an exception, and throw a different exception (a "smarter" one, one that fits the usage domain of the method) while putting the original exception in the new one's InnerException. So a "File Not Found" situation deep inside a simulator program may end up as a "Simulation failed" exception, where the tree of inner exceptions ends up explaining why or how it failed.

FWIW: I would recommend you study the topic in more detail in a book on .NET in general, or on C#; an introductory book should contain a number of examples of all of the above. And I do mean a physical book, not an eBook or some web course.

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

BobJanova14-Sep-11 2:22

14-Sep-11 2:22

Generally an excellent post. I'd just mention that it's good to be careful about your use of catch-throw different, because it makes debugging quite a bit harder if your IDE is set up to trip on where the exception was thrown, because you get stopped in the context of the catch handler and don't have access to the state at the point of the initial failure. It can be good but don't overdo it (as the folks who wrote the app I'm working on seem to have done).

Adam_Dev14-Sep-11 2:33

14-Sep-11 2:33

Thanks Luc, your reply was really useful. I think I have a goodish idea of how to proceed (I hope). I'll make sure to get a good introductory book to give me a better understanding.

I should point out that when I said that I'd log the exception and then exit, I meant log the exception and then return a message to the user. Would that still count as an ungraceful exit if I had a single try/catch block at the top level out of interest?

Thanks

Luc Pattyn14-Sep-11 2:51

Luc Pattyn

14-Sep-11 2:51

You're welcome.

I don't want an app to exit until I explicitly tell it to, unless it has done all it is supposed to do.

You wouldn't want MS Word to exit on a disk full situation, as that would make you loose any changes you've made to the currently open document(s).

Smile | :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

ArrayList

Subodh Kumar Jain13-Sep-11 20:38

Subodh Kumar Jain

13-Sep-11 20:38

using System;
using System.Collections;

public class Array
{
    public static void MyArray(IEnumerable list)
    {
        foreach (object a in list)
        {
            Console.WriteLine(a);
        }
    }
    public static void Main()
    {
       ArrayList  array = new ArrayList(10);

        array.Add("January");
        array.Add("Febuary");
        array.Add("March");
        array.Add("April");
        array.Add("May");
        array.Add("June");
        array.Add("July");
        array.Add("Agust");
        array.Add("September");
        array.Add("October");
        array.Add("November");
        array.Add("December");

        MyArray(array); Console.ReadLine();

    }

}

Re: ArrayList

Wayne Gaylard13-Sep-11 21:04

Wayne Gaylard

13-Sep-11 21:04

Whats the question ?

When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman

Re: ArrayList

PIEBALDconsult14-Sep-11 2:27

PIEBALDconsult

14-Sep-11 2:27

Yeah, OK, whatever, but List<string> is preferable.

Re: ArrayList

Pete O'Hanlon14-Sep-11 3:51