Label not getting updated.

[manju 3]

HI Team, Label text is not updating.Here is the check I am doing.If the label = 1234,i am trying to update the label.It is entering the if condition,but the label is not getting updated with the new one i.e 100.

this.lblPos.Text = "1234";
if (this.lblPos.Text == "1234")
{
this.lblPos.Text = "100";
this.lblPos.Update();
this.lblPos.Refresh();
}

Thanks in Advance

[Lost User]

Works fine in my program. Where exactly is this code being executed?

[OriginalGriff]

Use the debugger: put a breakpoint on the first line of that code and step it through. At a guess, I'd say it probably isn't being executed at all for some reason and the debugger will never hit the breakpoint as a result. If that happens, put another breakpoint at the start of the method containing that code and try again. When you hit a breakpoint the debugger will stop and let you take control, stepping lines of code and looking at variables to see what is going on.

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

[Michael_Davies]

If it is a winform try adding a line Application.DoEvents after you alter the value.

[OriginalGriff]

Generally speaking, if you need DoEvents then there is something very wrong with your application design! :laugh: In this case it won't help anyway: the Text property is just a string, if you look at ethe reference source:

/// <include file='doc\Label.uex' path='docs/doc[@for="Label.Text"]/*' />
/// <devdoc>
/// <para>
/// Gets or sets the text in the Label. Since we can have multiline support
/// this property just overides the base to pluck in the Multiline editor.
/// </para>
/// </devdoc>
[
Editor("System.ComponentModel.Design.MultilineStringEditor, " + AssemblyRef.SystemDesign, typeof(UITypeEditor)),
SettingsBindable(true)
]
public override string Text {
get {
return base.Text;
}
set {
base.Text = value;
}
}

And the base class implementation (Control):

/// <include file='doc\Control.uex' path='docs/doc[@for="Control.Text"]/*' />
/// <devdoc>
/// The current text associated with this control.
/// </devdoc>
[
SRCategory(SR.CatAppearance),
Localizable(true),
Bindable(true),
DispId(NativeMethods.ActiveX.DISPID_TEXT),
SRDescription(SR.ControlTextDescr)
]
public virtual string Text {
get {
if (CacheTextInternal) {
return(text == null) ? "" : text;
}
else {
return WindowText;
}
}

set {
    if (value == null) {
        value = "";
    }

    if (value == Text) {
        return;
    }

    if (CacheTextInternal) {
        text = value;
    }
    WindowText = value;
    OnTextChanged(EventArgs.Empty);

    if( this.IsMnemonicsListenerAxSourced ){
        for( Control ctl = this; ctl != null; ctl = ctl.ParentInternal ) {
            ActiveXImpl activeXImpl = (ActiveXImpl)ctl.Properties.GetObject(PropActiveXImpl);
            if( activeXImpl != null ) {
                activeXImpl.UpdateAccelTable();
                break;
            }
        }
    }

}

}

Doesn't do anything exotic with it either, certainly nothing that DoEvents would affect.

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

[Michael_Davies]

Of course, however if DoEvents shows an improvement and the label updates then you know there's an issue somewhere else.

[Richard Deeming]

OriginalGriff wrote:

nothing that DoEvents would affect

Are you sure about that? Have a look at the WindowText property setter[^]:

if (value == null) value = "";
if (!WindowText.Equals(value)) {
if (IsHandleCreated) {
UnsafeNativeMethods.SetWindowText(new HandleRef(window, Handle), value);
}
else {
if (value.Length == 0) {
text = null;
}
else {
text = value;
}
}
}

That call to UnsafeNativeMethods.SetWindowText will require the message loop to pump events before the control is updated. Which is exactly what DoEvents was intended for. :)

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[OriginalGriff]

Yes, but the text and / or the WindowText are already set by that point, and they are what the getter uses to provide the data. So the display may not be up-to-date yet, but the property return value will be.

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

[V 0]

If you're calling it from another thread (which the compiler "should" warn you about) this can happen. In that case you need to something like is explained here: c# - Update label from another thread - Stack Overflow[^]

V.

(MQOTD rules and previous solutions)

[Dave Kreskowiak]

DoEvents doesn't run the message pump or even start a new one. It's what I will call a kludge that grabs messages out of the queue and processes them itself, bypassing the pump. The problem comes in when a message causes another event to be triggered, possibly executing event code out of order of what is expected. For example, you're adding items to a control when the user clicks the application close button. If not written properly, your code will suddenly throw an unhandled IndexOutOfRangeException because the controls will no longer exist and your code is still adding items to it. While it may be the "easy fix" for the short term, it's a long term pain in the ass when you get to testing the code in UAT.

A guide to posting questions on CodeProject

Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak