I know I’m not the only .NET developer for Smartphone. But it sure seemed that way when I tried to find a solution for a .NETCF 1.0 bug with multiline textboxes, hardly an uncommon Control, IMHO. After trying a number of different hacks, I finally have constructed one that seems to solve all problems. But what is this problem first of all?
When the textbox is drawn, it will paint the back on any area that contains text, but leave any empty areas unpainted, i.e. showing whatever was previously on the screen. This is aggravated by the fact that T9 textinput will often partially obscure the Textbox and once the T9 pop-up disappears the Textbox won’t repaint the dirty areas. The closest thing to an official recognition of this bug that I could find was a post on the MSDN Forums that said it was known and to switch to .NETCF 2.0. Now, I would love to switch to 2.0, since Windows.Forms on 1.0 of .NETCF is missing a lot. Unfortunately all current Smartphones ship with 1.0. I could require users to upgrade their phones. But even if i just plug the ARM .cab out of MS’s redistributable, that’s still a 6MB install, not insignficant for loading over the phone network nor for the memory available on the device. And all that so they can run a 500KB app? Right. That path is not an option.
I initially hacked around the bug by first drawing the background and using a timer to draw the textbox itself a moment later. While this worked initially, it added a complication in having to hide the textbox to refresh it. Hiding it made it loose focus, so I had to catch that and refocus it. This in turn does screwy things with T9 text entry modes on most phones I tested.
The solution that does work without any sideeffects that i’ve found is simply to overlay the textbox with a background colored panel for a moment. Once the panel is removed, the Textbox repaints itself and any area not repainted because of the bug is left with the color of the overlay/. This does not affect focus, so it can be done at any time.
Let’s assume you have TextBox textBox and a Panel wiper of equal size and placed overlapping in the form, as well as a disabled Timer timer running at the shortest allowable interval. Finally you have a bool wipe to indicate whether we’ve performed the wipe. With this setup the logic for “wiping” the TextBox clean is as follows:
private void Wipe() { wiper.Visible = true; wiper.BringToFront(); timer.Enabled = true; wipe = true; } private void timer_Tick(object sender, EventArgs e) { if (wipe) { wiper.Visible = false; timer.Enabled = false; } }
That solves the problem of painting the areas the TextBox forgets. We can call Wipe() on Refresh() or pretty much any time we know we obscured the control. Wouldn’t it be useful if Invalidate was virtual in 1.0 as well? ho hum. Unfortunately it’s completely up to you to know when your TextBox is Invalidated and needs a wipe-down.
If you are handling the UI, that’s manageable, but what about those T9 pop-ups? For all your program knows there is no such thing. Even if you derived a class off of TextBox and overrode its OnPaint(), you’d still never see a paint message, because the actual textbox painting caused by the T9 pop-up appears to happen at the OS level, below .NET. To detect a T9 pop-up, or let’s say, to infer that it’s happening, you have to watch both the KeyDown and KeyPress events. As soon a s the T9 pop-up happens you won’t be seeing your characters come through as KeyPresses anymore. Instead you will see KeyDown events being fired with a KeyCode of ProcessKey. The next time you see a KeyPress event, it’s all the keys of the completed word being spewn into the TextBox. Therefore, if you see a keypress come in after a ProcessKey, you know a T9 pop-up just closed and it’s a good time to wipe down your code>TextBox. Given a flag bool inT9, the code would look look this:
void textBox_KeyPress(object sender, KeyPressEventArgs e) { if (inT9) { Wipe(); inT9 = false; } } void textBox_KeyDown(object sender, KeyEventArgs e) { if (e.KeyCode == Keys.ProcessKey) { inT9 = true; } }
At the end of the day this is all fairly elaborate just to use a standard multi-line code>TextBox, but I have not found another way to do it on a stock Smartphone under .NETCF. I'd be glad to be proven wrong, but in the meantime, at least this is an option.
The Visible property on Controls is a bit misleading. Aside from the fact that setting it to true, is really only an advisory setting, since it’s truth is also dependent on all its parents, there is the issue that is has nothing to do with whether it’s actually visible when the form is painted.
Simple example: You have a Control A in a panel and that panel is half off-screen (or at least half across the edge of its container. And A is in the part of the panel that’s obscured. A is going to be Visible, even though its not visible.
The interesting thing is that the paint cycle knows this, and OnPaint won’t be called on the Control. Now wouldn’t it be nice if there was a property that told you that your Visible control won’t be drawn? If there is a simple way to determine this, I haven’t found it (especially not on .NETCF 1.0).
The way I do it now is that i use RectangleToScreen on the Control and then recursively walk up the parents, get their screen rectangle and call IntersectsWith on the control’s Rectangle and each Parent. As soon as i find one that doesn’t intersect, I know the Control is not going to be drawn.
If you are working on the .NET Compact Framework 1.0 and you get an ArgumentException trying to manipulate your UI (such as adding a Control to a form), you are likely doing this operation from a thread other than you UI thread and should be using Invoke. Thanks to jonfroelich‘s post “Controls.Add ArgumentException” for putting me on the right path. With all my frustrating debugging and unexplained freezes, i’d completely forgot that the particular code branch I was looking at was initiated by a callback from a WorkerThread.
Of course the Invoke facilities of .NETCF 1.0 are pitiful, lacking the things that make this whole single-threaded UI business bearable in regular Windows.Forms. There is not InvokeRequired for one thing, nor is there BeginInvoke. And even Invoke just provides the Invoke(Delegate) signature, not the much more useful Invoke(Delegate, Object[]).
Add to that that the only valid Delegate is an EventHandler, which takes two arguments, the exclusion of Invoke(Delegate, Object[]) really is painful.
Today started simple enough. I needed more debug info from my Smartphone app than just using the debugger could give me in a reasonable fashion. My usual solution is log4net for getting a debug spew, but trying to stay as simple as possible on the .NETCF 1.0, I decided to hit up System.Diagnostics instead. More to the point, System.Diagnostics.Debug.WriteLine() and its brethren.
Except, nothing showed up in the output window. Checking whether there was a config setting, then making sure that .NETCF 1.0 supported it, I was stumped. Finally I find out that the default TraceListener is only supported by VS.NET 2k5 if you use .NETCF 2.0. Now I don’t know if you’ve looked at deploying 2.0 apps in a world where even the most modern phones still ship with 1.0, but I certainly couldn’t find a clean and simple solution. Especially not one that didn’t require being tethered and downloading 40MB from MS, just so they can run a couple hundred kilobytes of App. And it’s a pity, because I run into something every day to which the answer is “Use .NETCF 2.0″. I want to, really, I do, but deployment convenience trumps developer convenience.
Next up was writing a custom TraceListener and wanting to be as unobtrusive to my Apps operation, I built it on UDP, i.e. a UdpTraceListener. Console based prototype code was up in about 20 minutes for the UdpTraceListener and the console app for listening to the spew. Then followed a couple of hours of testing and stepping through debug and not being able to get anything to be sent from my Emulator cradled via ActiveSync.
I even thought it might be because the phone Emulator couldn’t talk to the hosting computer and moved the console app to Mono on my server. That part worked flawlessly–copy the binary call mono UdpTraceConsole.exe and it was up and running. But it also received no data.
Then finally I find a chat log with the .NETCF team that reveals that UDP is not supported over ActiveSync. Nice.
Another 20 minutes of coding and i had a TcpTraceListener up in running in my console test harness. Woot. Time to put test on the phone, so i can finally get back to real coding….
Right. That would have been nice. The same game as before. Tried all sorts of permutations and received no data. Sometimes the debugger would throw a Socket Exception, usually it wouldn’t. It made no sense. I knew that TCP worked because I use HttpWebRequest extensively. So I tried putting my console listener on port 80. Nothing. Finally, I decided to open up a port on my firewall and forward it back to my dev machine so that I could try to contact my console listener via a network address from the outside world. And that finally worked. Only theory I have right now is that the DHCP setup via ActiveSync is screwy and it just can’t see any of my local net. I’ll investigate that later, for now I’m just happy to have a working debug spew.
And here is the exceedingly simple TcpTraceListener. Note: I use '\0' to denote the end of any message so my debug messages can include linefeeds.
using System; using System.Diagnostics; using System.Net.Sockets; using System.Net; using System.Text; namespace Droog.Diagnostics { public class TcpTraceListener : TraceListener { IPEndPoint endPoint; Socket console; public TcpTraceListener(IPEndPoint consoleEndPoint) { this.endPoint = consoleEndPoint; } private Socket ConsoleSocket { get { if (console == null || !console.Connected) { console = new Socket( AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); console.Connect(endPoint); } return console; } } public override void Write(string message) { try { ConsoleSocket.Send(Encoding.ASCII.GetBytes(message)); } catch { // this is for a debug spew. I'd rather swallow the exceptions // than have my debug code mess with my App. } } public override void WriteLine(string message) { Write(message + "\r\n\0"); } public override void Close() { if (console != null) { if (console.Connected) { console.Close(); } console = null; } base.Close(); } } }