I have a COM server application that uses some WinForms controls that, frankly, do not redraw when their properties change (Text, BackColor, etc.).
I tried to invoke txtControlName.Invalidate()as well .Update(), and nothing affects anything.
This is a business requirement that we adhere to .Net 2.0 and provide a visually responsive and interesting user interface, and although I understand that I can possibly force redrawing using WinAPI SendMessage(), I would rather have .Net handle all these things - - Yes enough hacks, and we no longer want to add.
Finally, I wanted to point out that the .Net COM server is located inside an unmanaged application.
Thank!
Tom
Application:
Currently, the actual update code is as follows:
public void UpdateSt(int? seq, string text) {
Control.CheckForIllegalCrossThreadCalls = true;
if (this.lblText.InvokeRequired) {
this.lblText.Invoke(new MethodInvoker(() => {
UpdateSt(seq, text);
}));
} else {
if (text != String.Empty) {
lblText.Text = text;
lblText.Refresh();
DebugTrace("lblText says '" + lblText.Text + "', is supposed to say '" + text + "'.");
}
if (imgSeq.HasValue) {
}
}
}
Addendum No. 2:
Spy ++ reports that the WM_SETTEXT call coming from the .NET Text setter does not work, like my own WM_SETTEXT calls do.
Appendix No. 3: SOLVED
Turns out the problem was a combination of a broken message pump and some P / Invoke calls that did more harm than good. Since the library was launched via COM, there was no .Net message pump and no additions Application.Run()inside the new thread so that everything could react as it should. It seems like a good idea to make sure that all form-based interactions start with the stream with this call.
source
share