You're absolutely right, sorry! A lot of sentences in there and I guess I missed the last one.
In any case - to the original poster if you're following along - you should look at the CultureInfo class and its related properties (IFormatProvider implementations). For most ToString overloads (not the override from Object or another base class), the IFormatProvider (like the NumberFormatInfo) is used for the Thread.CurrentUICulture, so you don't really need to specify one unless you want to format for a different culture (just for that instance, otherwise you should set Thread.CurrentUICulture and re-initialize your controls) or pass your own IFormatProvider. Typically, such a ToString method (or methods like String.Format) will specify if they use the current CultureInfo for the format specifier.
While I continue my investigation on C#, I'm currently testing some techniques I was used to use in MFC.
I have done the following things:
I derived a UserControl to write my own control. In the OnPaint overridable method, I want to do my drawings. As C# uses GDI+, it's cool, I also use GDI+ in C++.
In MFC I was doing the following thing:
- Instanciate a Bitmap object with the width, height, and color depth
- Link a Graphics object to this bitmap
- Work with this graphic object to generate my bitmap
- When the bitmap was generated, I displayed it on the drawing context.
Therefore, it looks like this
First of all, when overriding an event handler like OnPaint, always call the method on the base class (ex, base.OnPaint) unless you have a VERY good reason not too. The base class might have things it needs to do as well, and if you don't the Paint event won't be fired for other, outside classes to handle. Also, whenever you're done with a Bitmap, call Dispose on it or memory consumption increases rapidly. This could be one reason for the flickering. The GC will clean it up eventually, but not in a timely enough manner - especially when the app is busy doing a lot of repainting that occurs when you resize.
Also, for things that don't change - like your Pen, you can store these as fields if time is a big issue, but you should normally dispose those as well.
Finally, you can call SetStyle with ControlStyles.AllPaintingInWmPaint, ControlStyles.DoubleBuffer, and ControlStyles.UserPaint in order to tell the Framework (or rather the underlying system resources) to use double-buffering when painting. This works in most cases.
im coding a system in c#...i have got four buttons that link to four diff departments
in the system. these buttons when clicked, opens up the same dialog box which requires a username and
password to access to the respective parts of the system(according to the buttons).
the user name and password is different for each department is it possible for me to use "if else" statements to check
the passwords from the database(SQL).
i've coded in plain english just to check if its logic and possible
private void btnOK_Click(object sender, System.EventArgs e) //ok button on the password dialog box
if (btnReg was clicked)
check for user name and password in the REG table
if (username and password is correct)
messagebox saying incorrect password
if (btnDiag was clicked)
check for user name and password in the DIAG table
if (username and password is correct)
messagebox saying incorrect password
and so on for the rest of the buttons....
if this is not possible...then is there anyway i can do this...or do i have to code four different password dialog boxes for
each of the buttons which will not be very good for the system, design wise and also extra coding....arrrgghh!! HELP!!
I take it all of the buttons are wired up to the same event?
If so the 'sender' variable is the textbox 'sending' the 'on_click' event. You can then cast the sender variable to a control of type 'textbox'
TetxtBox txt = (TextBox)s;
and evaluate the id etc with either a switch/case statement as below...
//Function to check password 1
//Function to check password 2
//Function to check password 3
//Function to check password 4
//Default password failure?
...or with an If Else statement, that would be up to you. Of course you're password checking could be all nicely wrapped up in it's own class etc.
Before showing the dialog, set a property you'd add to the Form that dictates which button was clicked, like an enumeration for example (provides easy value checking to make sure an invalid enumeration wasn't passed in - see Enum.IsDefined).
You could also use a generic prompt Form that has a username and password property that gets the text from their respective TextBox controls in the Form and, if ShowDialog returned DialogResult.OK handle the code in each one of the Click event handlers for the departmental Buttons. If you put this in a terminating loop (for which you can always use break to break out of it if the credentials were authenticated successfully), the dialog could be shown multiple times - even using the same instance. Just don't forget to call Dispose when you're finally done with the Form to free system resources, which is necessary for modal dialogs (i.e., when calling Form.ShowDialog, which has to do with the underlying native resources used by the Form).
There's many other ways you can do this. Personally, I would've invoked the call on some sort of broker since your code to check the database is most likely the same except for, perhaps, the connection string and the query string. If you passed an instance of an object configured with the write departmental connection and query strings, the prompt could simply call a single method and know whether or not the credentials are valid without even knowing which department is authenticating the credentials. After all, it's just a generic prompt dialog - why should it care about how to authenticate credentials. Just use the power of polymorphism. For instance, if you have an interface like so:
...and had a property that takes an instance of this interface (by declaring a property of Type IAuthenticator), then when the user tries clicks OK (or Login, or whatever) you make sure this property isn't null and call Authenticate on the instance. Any code that wants to authenticate credentials merely implements this interface and provides a specific implementation of Authenticate. This is a good abstract design.
I’m a long time programmer of C++ and a great fan of the Standard Template Library (STL). I’ve recently started working on C# and find that my beloved vector template doesn’t exist.
To get round the problem of creating a container of class objects I have to implement a whole new class that derives from System.Collections.CollectionBase for the container and then another class to deal with enumeration.
I realise that C# is strongly typed and that is the reason for creating your own containers but does anyone know how I could get round this to create a template class.
Colin Angus Mackay wrote: Wait for the next version of C# which includes generics (C# equiv. of templates)... I can hardly contain myself. That is one of the things I miss from C++.
Yeah me too. Actually, C# generics should be an improvement over our C++ templates; templates are nothing but "exalted macros" as I once read, with the compiler swapping values in at compile time. C# generics will have a JIT'd version of the actual generic code you write, and reuse that JIT'd code across all the types of that generic class.
Fun fun fun stuff. I just hope it will be released in the spring or summer this year.
You can always use a generic collection or list class like ArrayList. It won't give you strongly-typed params (also, C# isn't strongly-typed, .NET is), but .NET is a true object-oriented framework and adding, for example, a Control to an ArrayList (which accepts Objects) is still a Control in the list. GetType (inheritted from Object) will always return the right Type.
I realize this is probably not what you want and as Colin said, .NET 2.0 (due to release in late 2004 I would imagine, since the end of the year was the release date for 1.0 and 1.1) will include generics. I just wanted to point out that you don't need to worry about using appropriately Typed parameters. After all, when you extend the CollectionBase class and use either List or InnerList (and if you don't, then don't waste time by deriving from CollectionBase), both of those are an instance of the same ArrayList.