I think you are asking how to move the textbox caret to position 0 when the empty textbox is clicked. The first part is to get the empty state of the maskedtextbox before any data has been entered. At that point the Text property value is not String.Empty but a representation of the mask. This 'empty' text can be obtained by capturing the Text when the MaskChanged event fires. For your example it is "( ) " The second part is picking a suitable place to move the caret. When an unfocussed textbox is clicked the sequence of Enter, GotFocus and Click events occur. You'll find that attempting to set the caret position in either the Enter or GotFocus events will fail and changes must be made in the Click event handler. Combining that information gives some prototype code private String emptyText; private void MaskedTextBox_MaskChanged(object sender, EventArgs e) { // Capture the empty text MaskedTextBox mtbx = (MaskedTextBox)sender; emptyText = mtbx.Text; } private void MaskedTextBox_Click(object sender, EventArgs e) { MaskedTextBox mtbx = (MaskedTextBox)sender; String currentText = mtbx.Text; if (currentText == emptyText) { // Move the caret to the start of the line mtbx.Select(0, 0); } } EDIT : Correct operation of this code requires that the MaskChanged event handler is attached before the Mask is set. Alan.

Even with a scale, your need to "send" before you can "receive". And you may need to wait up to 200+ ms for a response (centering; etc.) "(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal

Hi, serial communication can be very hard, and it can be quite easy; it all depends on circumstances: how high the transmission rate is, how big the gap is in between messages, etc. Here are three pointers, assuming the peripheral uses printable text: 1. Always use a terminal emulator to get acquainted with your peripheral's behavior. It will help you in checking the hardware aspects and overall settings of your port, and it will help you in understanding the message flow. 2. the DataReceived event fires whenever it wants, which could be after receiving 1 byte, or 39 bytes, or whatever. It does not care about what you expect as a message, it only knows about individual bytes and several levels of buffering inside Windows. As a result it isn't very useful except in simple cases: If your messages are far apart, which gives you some time to waste, the easiest approach is to get started by the DataReceived event, then wait (with Thread.Sleep) sufficiently long so the entire message should be received by now, and then use ReadExisting. The required delay equals maximum string length * character time, which obviously depends on the baud rate used (say 1 msec at 9600 baud). Warning: Windows timing isn't always very accurate, so add a spare 20 msec or so. 3. The DataReceived event gets handled on an arbitrary thread (actually one from the ThreadPool) but absolutely NOT on the GUI thread (read more: Asynchronous operations run on ThreadPool threads[^]); therefore, you are not allowed to touch any of your GUI Controls inside the DataReceived handler. The proper solution is by using Control.InvokeRequired and Control.Invoke (read more: Invalid cross-thread operations[^]). NEVER use Control.CheckForIllegalCrossThreadCalls In more complex situations I tend to avoid the DataReceived event, instead I'd use an explicit Thread and perform blocking reads and a buffering scheme. Sometimes a BackgroundWokrer can do the job. Hope this helps. :) PS: Don't trust the default settings of SerialPort, always explicitly set properties such as Encoding, NewLine, etc.