No, there's no Z-order for drawing on a window. It's up to you to make sure you draw on top of whatever you want the text to be on top of. I'm not sure what "IEControl" you are using so I'm not sure how you could potentially know when it's appropriate to draw the text. Mark "Great job, team. Head back to base for debriefing and cocktails." (Spottswoode "Team America")

No. Unicode/ANSI support is defined per function (via argument/return types, or by API doc's that state the function uses Unicode/ANSI internally) not per dll. ...cmk Save the whales - collect the whole set

Hi Sarath, Thanks, its of great help, in particular http://www.codeproject.com/useritems/SizingDialog.asp, Though it doesn't solve my problem completely, i can re-use it. However I still feel there should be some utility developed particularly for my problem, as its very generic requirement for multilingual application if we do not wish to maintain seperate resource dlls. Anyways, Thanks much. Regards Suyash

So just to be clear here are the settings I'm using to get this to work (for the Release configuration) Configuration Properties->General Output Directory = Release Intermediate Directory = Release Configuration Properties->C/C++ Object File Name = $(IntDir)/ Configuration Properties->Linker->General Output File = $(ProjectDir)OutPut/$(ProjectName).exe Is that what you're using?

Arti, I tried CRichEdit Control. by default it doesn't support unicode. l_pWnd->Create( _T( "RichEdit20W" ), NULL, in_dwStyle, in_rcRect, in_pParentWnd, in_nID ); please note "RichEdit20W" which makes the CRichEditControl unicode enabled, by default its "RichEdit" hope it helps. regards suyash

DavidCrow wrote: Is that useful? Wouldn't that be irritating to the Chinese user? Hello All, Thanks for your replies and suggestion to the given problem, I would try to apply ES_NOIME solution as suggested. Regarding this requirement, actually we do have a poker table client, wherein various players from various contries(usa, china etc. etc.) will be able to play on the same table. Each player may have his/her own different language version of our software. However we also provide a chat facility, its all lobby chat, and personal chat is allowed. and its possible that 2 chinese player, if allowed to chat in chinese language(which other players may not know), can collude and cheat other players, so thats the reason we wish to restrict the chat input window to support only the english characters. Though we understand that there is no way to prohibit languages that uses english character set, like german. Thanks again! Regards Suyash

if the compiler can find a function which signature fits exactly to the argument types it receives, then there's no problem. the ambiguity can arrise when the compiler has to do some implicit conversions... in you case Func1(1, 1); results in calling void Func1(int, int) because literal numbers are firstly interpreted as ints. i don't know the priorities of the compiler's implicit casts, but take this for instance : Func1(1, 'a'); 'a' is of type char, but no function Func1(int, char) exists, so it continues looking if this call fits another existing overload before casting some parameters. only if the compiler makes some implicit casts an ambiguity can come, because the call can then fit several overloads...

Lookup the FormatMessage API (or alternatively here[^] for a better solution IMHO). It uses %n for hard line breaks in a string. You may be right I may be crazy -- Billy Joel -- Within you lies the power for good - Use it!