Im confused, and mildly concerned.

Keep in mind i have heap memory generated via a WM_CREATE message to the sub-classed edit control. Since the control is already created, i sub-classed this message as a new, next stage, init. However, if for some reason you dialog is sending this message again (a third time ~ one to create, two for my subclassing, and three for what ever reason the parent window has) you will have extra heap memory not being freed and forgotten (the second call's allocation).

Now, i might be missunderstanding your problem. But if not, this is something to pay attention to. As an alternate, and probably safer, you can rename the WM_CREATE to a WM_USER+300 or something. But im personally surprised that more than one WM_CREATE message would get sent to any control.

As for your EN_UPDATE messages, i did nothing directly to this from sub-classing. I simply pass on anything im not interested with to the normal handler.

*brain fart* :: I just realized im not properly handling the OldEditProc variable properly for multiple subclassing. Its being used as the sole global variable. This means if, for some reason, two edit controls have different origional handlers, i would be routine *all* forwarded messages to the last edit control that was 'converted'. I fixed this now in this next version! As well as modify the WM_CREATE to WM_USER+206.

The above is probably paranioa anyways.. im not 100% sure, but i believe windows uses the same proc for all edit's. This is most likely not your bug (but its good to fix anyways ;) ).

To get EN_UPDATE messages, when your not expecting them may come from WM_SETSEL or WM_SETTEXT which i use in the subclassing. But they are only active when you hit a key in the control. (Or a key message is issued to the control). So im still not sure where this is comming from. My only suggestion is to compile a debug version of the lib, with PrintText messages to proove to yourself that certain sub-classing fragments are been entered when no key is hit by a user. (I use VKIM's debug macros heavily for this sorta stuf).


Thanks for the new version : I think it was a bug in my code anyway : it was probably just more noticeable with your control because it must use send messages that generates EN_UPDATE notifications.
As I said, I use a boolean variable to say whether I want to deal with the notification or not.
This variable, being static was initialized to 0 (FALSE) on the first call, so I thought it was ok, but in fact, when the window leaves, the variable is at TRUE... and as it is a static variable, the value stays persistant trough different calls of this function, so, when this window is reloaded, the default variable value is now TRUE and not FALSE.
You are right, you are midly concerned, but I didn't find out/understood this bug when I wrote this and thought that your control could generate EN_UPDATE notifications when I didn't expect it.

Thanks !
Posted on 2003-07-28 01:23:34 by JCP

Hi QvasiModo

Well SendMessage works fine I used my color button and just put a messagebox into it
Attached the demo...

Clickin on the button send the message

Cya Greetz Kahn

You are absolutely right, of course...
Maybe my problem was because I was trying to send WM_CREATE to a dialog box instead of a control? Seems more likely to me that there was a bug somewhere else, so my dialogproc was not handling the messages correctly... :P
Posted on 2003-07-28 11:00:50 by QvasiModo
Dear NaN,

Your control is working very well ! I am pleased with it ! :alright:
But I have another question again... (I hope my explainations will be clear)
I use your control to input a float value and I did set the mask to "##.##" which works very well for the user input.
What is also very likeable is that the user can also type the decimal seperator, altough it not a masked character, which is very nice...

Now, I want to programmatically set a value in this masked edit box (example : "20.40").
But, when I use SetEditText all I have is "20._4" and not "20.40".
I assume it is because the '4' character is "eaten" because its previous character is not a masked one.

I tried with "2040" and it works as expected, but it implies to delete the dot from the string, which is a bit annoying (in real life, it is not hardcoded value, but values from a listview) and not very adaptable for other cases...
Do you think it is possible to modify your control to accept such a behavior ?
I thought about using keyb_event to send the characters to the control or something like this, but it does not sound very clean...

Thanks in advance !
Posted on 2003-07-29 05:41:48 by JCP
What you want is challenging, in a sense to maintain all the other constraints.

Firstly it should be a masked edit control. To do what you want implies the mask be used as a guideline more than a constraint.

The char yours suggesting is 'eaten' is actually the '.' that is not shown. The control knows nothing of your mask other than where the "#" and "?" are. So it thinks your trying to put a '.' in a location where a '#" should reside. Doing so, it simple skips the location, not entering anything where the incorrect char is.

(A) Alternately you can make the '.' a valid entry (as is chars and numbers). This should not be a lot of trouble. However, like '#' and '?', you will have to place specifically where you need decmal points, and will not be able to be freely placed.

That is, your floats will have x chars befor the point, and y chars after. No if and or buts. Simply because its a masked control.

(B) Lastly, i could also add is a fourth char that will make it "unmasked". Say '$' for any char. In this case, if you dont want to constrain a decmal place, you can not mask any input for six or seven chars. However you will have to do more manual checking to ensure the data was entered correctly afterwards. (Which is no different than a normal edit control at this point!!).

Tell me what you think is best. A, B or A&B. And i will try to code up the changes soon.

Posted on 2003-07-29 21:38:38 by NaN
I understood your explanation, it also was my theory but when the user inputs "20.40" (including the decimal separator) the input is correct because the dot character is skipped, which lets me think that having the same behaviour when programmatically setting a text may also be possible.
In my opinion, it would be nice to have another function like SetEditText but which has the same behavior as when the user inputs text in the control.

Deleting a decimal separator from a string is not something very difficult to do but I am thinking of the days when this control will be used with much more complex mask strings like the one from your example...
Maybe the right way is to make a string function that suppress all the non masked characters from the string so a further call to SetEditText will work as expected... but that sounds a bit complicated to do but also rather clean... maybe it is less cumbersome to do with your object model... what do you think of this idea ? I think it is the most versatile... but maybe there are simpler ways ?

Regarding the new mask character '$' to allow any char, I think it is a very good idea... The control could be then restrictive and/or permitive in different caret positions...

Thanks ! :alright:
Posted on 2003-07-30 02:33:57 by JCP

I wrote the function I was talking about...
Sorry, it is in C as I only have a C compiler there and do not have very much time to do an efficient asm implementation now...
I coded this function very quickly so it is maybe bugged (I tested and it seems to works just fine but...) and not very clean...
It expects that the input text is formatted in conformance with the mask.
If you agree with my idea, maybe you can adapt it and use it in a new function that wraps around SetEditText ?

void MaskConvert(char *szStr, const char *szMask)
int MaskPos = 0;
int StrPos = 0;
int TempPos;

if(szMask[MaskPos] != '#' && szMask[MaskPos] != '?' && szMask[MaskPos] != '$')
TempPos = StrPos;
szStr[TempPos] = szStr[TempPos+1];
}while(szStr[TempPos] != '\0');


}while(szMask[MaskPos] != '\0');
Posted on 2003-07-31 05:15:13 by JCP
I will see what i can do...
Posted on 2003-08-04 11:41:12 by NaN
Here is the last available version of the Masked Edit Control written by NaN:
Posted on 2006-07-22 08:02:51 by JimmyClif