Cursor goes to beginning of digits in edit box!

I have a multiline, numerical only non-rich edit box with right allignment. But when I enter a digit, the first digit appears rightmost (as it should) but the cursor jumps to the beginning of the number thus the result is that the number is entered backwards. So entering 6,4,5 will give the number 546.

Now I subclass this procedure so there must be something I do in the handling of messages that prevents the system from restoring the cursor to the right. I cannot find a message to send to the edit box which places the cursor to the right (or does anything with the cursor).

Any ideas or know how on how to control the cursor?

Brian

Quote:

---

Originally Posted by Gyannea

I have a multiline, numerical only non-rich edit box with right allignment. But when I enter a digit, the first digit appears rightmost (as it should) but the cursor jumps to the beginning of the number thus the result is that the number is entered backwards. So entering 6,4,5 will give the number 546.

Now I subclass this procedure so there must be something I do in the handling of messages that prevents the system from restoring the cursor to the right. I cannot find a message to send to the edit box which places the cursor to the right (or does anything with the cursor).

Any ideas or know how on how to control the cursor?

Brian

---

try this may be this one help u

open the property dialog of edit control in that choose style.
and select align text left

Did that already, but it doesn't help. The problem comes from a 'SetWindowText()' API function used in the subprocedure. When a WM_CHAR message is received, the standard handler is used, but after that I GetWindowTExt() to see if the number has exceeded certain limits. If it does, I enter the new corrected number into the edit box. However, the cursor appears to the left of that newly entered number and not the right. From then on, entries will be as they should (number enter to the right but displaced to the left of the number I entered) until I cross limits again then the whole thing starts over again.

I need to get Windows to recognize my corrected entry as part of the number!

Brian

Quote:

---

Originally Posted by Gyannea

Did that already, but it doesn't help. The problem comes from a 'SetWindowText()' API function used in the subprocedure. When a WM_CHAR message is received, the standard handler is used, but after that I GetWindowTExt() to see if the number has exceeded certain limits. If it does, I enter the new corrected number into the edit box. However, the cursor appears to the left of that newly entered number and not the right. From then on, entries will be as they should (number enter to the right but displaced to the left of the number I entered) until I cross limits again then the whole thing starts over again.

I need to get Windows to recognize my corrected entry as part of the number!

Brian

---

Can you post your code.
so we can c how u r trying to achive this.
and check once again with SetDlgItemText() method

The problem is in the subclassing (otherwise it doesn't happen). I have found a work around. After I call the 'SetWindowText()' API function I post a WM_KEYDOWN message and fake an arrow key of my choice. That moves the cursor to where it would be without the call.

Brian

You can use SetSel to move the caret

Wouldn't have guessed by the name! Thanks, that sounds better thanfaking an arrow key!

Brian