When you use MessageBox.Show() you have a selection of MessageBoxButtons to choose from. The buttons available are an enum, and give you options like "Yes No", "OK Cancel", etc.
When I am using, for instance, Norwegian message text the user still gets the English "Yes No".
Is there a way to change the text of the buttons (in C#) so that the language is correct? Can I override the text, or set the current locale in some way so that I can have "Ja Nei" instead of "Yes No"?
I do not want to rely on installing a .NET language pack at my client.
There is no native support for this in .NET (as far as I know, anyway; please correct me if I'm wrong, anyone). I did come across this CodeProject article, that seem to do the trick with some message hooking and P/Invoke:
http://www.codeproject.com/KB/miscctrl/Localizing_MessageBox.aspx
Usually messagebox buttons (as all of Windows) honor the currently set UI language for Windows. So if you've got an English installation and can't change languages (MUI versions or Ultimate for Vista/7) you're out of luck.
You could implement a messagebox yourself but I'd beg you not to. Simple things like common hotkeys for the buttons, having the ability to use Ctrl+Ins to copy the contents, etc. are the ones I miss the most when people start reinventing square wheels.
I don't think it is possible, but refer to the MSDN article MessageBox.Show Method. You may get some ideas. You can change the text in the message box. What about creating your own message box (new form) and displaying them?
You can create a panel (pnlExitMode), with property Visible=false, and put info text as well as buttons (btnYes, btnNo) labeled YES and NO (with button captions in "your" language) onto this panel, then place required Yes/No- actions into the button event handling routines.
At decision time (in my case: warning if ini file not yet written when closing application) set panel to Visible. Panel with buttons will pop up.
Example code:
private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
if (bIniModified)
{
pnlExitMode.Visible = true; pnlExitMode.BringToFront();
e.Cancel = true;
}
}
private void btnYes_Click(object sender, EventArgs e)
{
SaveToIni();
pnlExitMode.Visible = false; bIniModified = false;
Application.Exit();
}
private void btnNo_Click(object sender, EventArgs e)
{
pnlExitMode.Visible = false; bIniModified = false;
Application.Exit();
}
Related
I'm sorry if this seems incredibly obvious or a very much commonly asked question, but I've been searching and looking over posts for a while now and i still can't seem to get it.
I'm just getting into learning C# and I set myself a little project, making a word processor around a richtextbox control with a few extra features.
I'm currently just adding in the ability to 'Find & Replace' text, and the below code is working when used on the same form as the rich text box control.
richTextBox1.Rtf = richTextBox1.Rtf.Replace("bob", "bill");
I don't want to use a dialog box or something similar, i'm coming direct from our old friend VB6 though, so i'm not sure if they still even exist as such, so i'm making an external form that acts sort of like a dialog box, where i'd like the user to be able to enter the text to look for and replace and then press okay, and be sent back to the main form, sounds simple huh, probably is, i'm not sure what i'm missing...
private void findReplaceToolStripMenuItem_Click(object sender, EventArgs e)
{
Form3 AboutBox = new Form3();
AboutBox.ShowDialog();
}
I've tried my best at implementing a few of the answers I've read over here, in one of them i managed to be able to control form1 but only if i opened a new instance of it with form1.show(); after the code, which is kind of useless in what i'm trying to achieve.
I've set the richTextBox1.Modifiers to Public, but I'm still scratching my head over this one.
Instead of making the RichTextBox public, I'd add a property to the other form that returns the text from that control, like this:
public class SearchForm : Form
{
public string SearchTerm
{
get { return richTextBox1.Text; }
}
...
When the user closes the "search" form, you can get the search term by referencing the property:
private void findReplaceToolStripMenuItem_Click(object sender, EventArgs e)
{
string searchTerm;
using (var searchForm = new SearchForm()) // used 'using' to dispose the form
{
searchForm.ShowDialog();
searchTerm = searchForm.SearchTerm;
}
// do something with searchTerm
}
You'll find this makes maintenance more manageable too. Changing the names of controls in one form shouldn't require you to make changes in any other form that uses them.
sorry my english language is bad
I want make a button by another control and this button editable in design mode (change size, define onclick,... )
i create a button in design mode by programming but onclick of this not work in design time
btnTest.Click += new System.EventHandler(this._Click);
protected void _Click(object sender, EventArgs e)
{
if (DesignMode)
{
MessageBox.Show("Hi Design Mode.");
}
else
{
MessageBox.Show("Hi Run Mode.");
}
}
don't show show message
for that you need to understand what are you putting in the condition. read here on Control.DesignMode Property:
Gets a value indicating whether a control is being used on a design
surface.
The DesignMode property will be set to True when you are editing your winform page in Visual Studio. For example if you create a user control you could show a user control based on dummy data during design-time and at run-time generate a user control based on the provided data
i don't think you can push a button in designer time so this code does nothing i'm afraid
So I have my WinForms application with a StatusStrip. Inside this StatusTrip, there's a StatusLabel (it's not the default Label, as it's not supported for some reason).
Now, when I set StatusLabel.IsLink = true;, you'll get a hand cursor (which is great!). But now, if you do StatusLabel.Visible = false; the whole StatusStrip has a hand cursor on it right now. Making the StatusLabel visible again does not fix it.
This seems like either a .NET or C# bug to me.
My question is: is there any workaround for this, I'm not aware of? Either by fixing this hand cursor bug or by placing a real Label inside the StatusStrip? I've found out that when placing a MessageBox just right before you make the label non-visible, it's not doing this weird bug.
You can download a test solution here. In the Main.cs file there's a line with the MessageBox which you can uncomment. Try it yourself.
You can try setting the Cursor of your StatusStrip back to Default
private void toolStripStatusLabel1_Click(object sender, EventArgs e)
{
// UNCOMMENT THE LINE BELOW TO "FIX" IT
//MessageBox.Show("It's not doing the bug when showing this message.");
toolStripStatusLabel1.Visible = false;
statusStrip1.Cursor = Cursors.Default;
}
I'm coding a simple text editor using Windows Forms. As in many editors, when the text changes the title bar displays an asterisk next to the title, showing that there is unsaved work. When the user saves, this goes away.
However, there is a problem. This is handled in the change event of the main text box. But this gets called too when a file is opened or the user selects "New file", so that if you open the editor and then open a file, the program says that there are unsaved changes. What is a possible solution?
I thought of having a global variable that says whether the text changed in a way that shouldn't trigger the asterisk, but there has to be a better way.
before loading data to a textbox, unassociate first the eventhandler for change
uxName.TextChanged -= uxName_TextChanged;
uxName.Text = File.ReadAllText("something.txt");
uxName.TextChanged += uxName_TextChanged;
This is a horrible solution, but every time the text change event fires, compare the value of the textbox to some variable, and if they are different store the contents on the textbox in a variable and add the asterisk. When the method is invoked via the New File dialog or any other such event that is NOT changing the text, the asterisk won't appear.
This is not a viable solution for a real text editor since the memory would quickly get out of hand on even medium-sized files. Using a finger tree or whatever data structure text editors use to compare "versions" of the text is the only real efficient solution, but the premise is the same.
http://scienceblogs.com/goodmath/2009/05/finally_finger_trees.php
Below the second picture he mentions the use of finger trees in text editors to implement an extremely cheap "undo" feature, but I'm sure you can see the validity of the tree for your problem as well.
There are no global variables in C#. You should have such an variable as an instance variable in your form (or better yet, in a model for which your form is a view), and that is perfectly fine.
This is a very simple and stupid solution. I would use a MVP design pattern for this but here the fastest and simple solution:
//Declare a flag to block the processing of your event
private bool isEventBlocked = false;
private void OnTextChanged(object sender, EventArgs e)
{
if(!isEventBlocked)
{
//do your stuff
}
}
private void OnNewFile() //OR OnOpenFile()
{
try
{
isEventBlocked = true;
CreateFile();
}
catch
{
//manage exception
}
finally
{
isEventBlocked = false;
}
}
I have a winform app that we use in house. It has many individual controls on each of it's 25 "pages"(usercontrols). Our user base prefers very technicolor apps...they want a TextBox to be outlined Blue if it is a required field (color should go away if data entered). They want a TextBox to change to outlined Green if data has been changed in it to remind them to save. They want a currently highlighted TextBox to be outlined RedOrange.
I have been trying to come at this from many different angles (some of you have probably seen similar posts by me lately). Non of them work... So one way I KNOW will work is to register the paint event for every control and check for a "required" tag for the required portion. The OnFocus for the current field portion and finally the Validate event for the data changed portion.
I know this is not the best way or at least I STRONGLY suspect it isn't but I am out of time, nearly, and nearing my point of frustration. That being said, will that DESTROY my app's responsiveness? Is there a better way? Can I override the base control to color on different premises so that I don't have to go to each of the 100+ controls?
Any idea would be welcome because I am between my stupid Paint_Event idea and rewriting all the controls in WPF... :)
I will be rewarding a solution that works for me and that I can implement shortly with a Bounty.
I am so sick of colors...
Here is my attempt based on suggestions.
public class MyTextBox : TextBox
{
private bool _isRequired;
public bool isRequired
{
get
{
return _isRequired;
}
set
{
_isRequired = value;
}
}
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);
if (isRequired && base.Text.Equals(string.Empty))
{
HighlightControl(e.Graphics);
}
}
private void HighlightControl(Graphics graphics)
{
ControlPaint.DrawBorder(
graphics,
this.ClientRectangle,
Properties.Settings.Default.RequiredFieldColor,
Properties.Settings.Default.BorderWidth,
Properties.Settings.Default.BorderStyle,
Properties.Settings.Default.RequiredFieldColor,
Properties.Settings.Default.BorderWidth,
Properties.Settings.Default.BorderStyle,
Properties.Settings.Default.RequiredFieldColor,
Properties.Settings.Default.BorderWidth,
Properties.Settings.Default.BorderStyle,
Properties.Settings.Default.RequiredFieldColor,
Properties.Settings.Default.BorderWidth,
Properties.Settings.Default.BorderStyle);
}
}
I don't know the particulars of your app, but you could derive your own control from the base TextBox and let it handle much of this for you. Some thoughts:
Give it a bool Required property and some internal logic to color accordingly.
Have the textbox respond to its own
events - when text is entered, it can
do the right thing - change colors or
whatever is appropriate.
Provide your derived control with
properties to set the colors that get
used for each condition, then you can
switch them easily when the users
decide they want pink rather than
green.
You can utilize the focus events to "know" whether your TextBox (this is the one control you mentioned, so I'll assume this is the main control used here) has focus or lost it and the text change events can be used to drive all the color changes to the control.
You can certainly wire up all the
text boxes to control the
Apply/OK/whatever buttons to
determine if the buttons should be
enabled, assuming you have an Apply button or something like that which stores the data on click. There are a number of ways to communicate this. It's easy enough to iterate through the controls and ask their state.
Seems like this would work just fine.
What have you tried? You didn't really mention what you'd tried that didn't work.
You've got a problem, TextBox is, erm, special. Windows Forms leaves all painting to the native Windows EDITBOX control, the Paint event won't be raised. That can be fixed by setting the UserPaint control style to true:
using System;
using System.Drawing;
using System.Windows.Forms;
class MyTextBox : TextBox {
public MyTextBox() {
this.SetStyle(ControlStyles.UserPaint, true);
}
protected override void OnPaint(PaintEventArgs e) {
base.OnPaint(e);
// Paint something
//...
}
}
Copy and paste this into a new class, compile and drop the new control from the top of the toolbox. Try it out, you'll be quite disappointed. What you see is the result of close to 20 years of appcompat hacks on a control that dates back to Windows version 2. One of the grave crimes that EDITBOX commits is painting itself without generating a WM_PAINT message. That was important way back when Windows had to run on a 386SUX, keeping it compatible with old programs prevented Microsoft from fixing its behavior.
No happy answers here, you'll have to give up on the idea of customizing the border. What you can do is give the control a distinct BackColor when it has the focus. For example:
class MyTextBox : TextBox {
Color mBackColor;
protected override void OnEnter(EventArgs e) {
mBackColor = base.BackColor;
base.BackColor = Color.AliceBlue;
base.OnEnter(e);
}
protected override void OnLeave(EventArgs e) {
base.BackColor = mBackColor;
base.OnLeave(e);
}
}
You can inherit from base control classes and add your own drawing logic. That won't be very expensive performance-wise, but, if your app is of significant size, you'll have to replace each occurence of standard TextBox with your own implementation.