Edit Control for Dialog Box in ANSI/UNICODE
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
I'm making a Find & Replace dialog box and I need the edit controls inside to be either ANSI or UNICODE determined at runtime. While developing the code as an extension to Petzold's POPPAD3, CreateDialogParamA would create a dialog containing ANSI edit controls and CreateDialogParamW would create a dialog containing UNICODE edit controls. It works whether POPPAD3 is compiled in UNICODE or non UNICODE modes. Now that I have transplanted the code into my other project:Notepad++, both calls create only UNICODE edit controls. I have verified with IsWindowUnicode() that the CreateDialogParamA dialog is ANSI but the edit controls inside are UNICODE.
If I trick POPPAD3 into making the F&R dialog box not for itself but for Notepad++, ANSI and UNICODE edit controls are created correctly. If I trick Notepad++ into creating the dialog for POPPAD3, only UNICODE edit controls are created.
Just in case CreateDialogA is calling CreateWindowW to make it's child windows I tried to CreateWindowA my own edit control inside the known ANSI dialog box and I still get a UNICODE edit control.
I have also tried duping the dialog resource and using CreateDialogIndirectA and that still creates a UNICODE edit control.
I also tried to LoadLibrary("USER32.DLL") and GetProcAddress(...,"CreateDialogParamA") myself just in case someone was playing thunkey in the middle.
One search turned up the claim that in an NT based OS, all A functions are translated to W functions. From POPPAD3, we can see that there are some differences between CreateDialogA and CreateDialogW. I've also found some editors that create ANSI only edit controls in their find windows.
There is a secret hand which is forcing all my edit boxes to be UNICODE and I'd like to smash it's fingers. No amount of Google searching has turned up any instance where someone needed to and was able to control the ANSI/UNICODE aspect of an edit control inside a dialog box. Apparently it's supposed to take care of itself.
The problem with having a UNICODE edit control in an ANSI environment is that it changes how text is pasted from the clipboard.
I hope noone tells me to use a RichEdit for a F&R dialog. I have better options than that.
It could be asking too much of the resource compiler to figure it out properly. I might suggest creating the Edit controls with CreateWindowExA/W as child windows of the dialogbox. This should also eliminate the perceived problem in Win9x as well.
The edit control is created from a resource file or a CreateWindow function, not CreateDialog. CreateDialog and CreateDialogParam create the dialog box. The controls in them are created separately from either a resource file or a CreateWindow function with the EDIT class.
Check your resource file for the edit control definition, or check the CreateWindow function. If you still can't find the problem post the resource code for the dialog box or the CreateWindow function.
Just a quick snip from commctrl.h and I'm not sure if this is it:
define WC_EDITA "Edit"
define WC_EDITW L"Edit"
define WC_EDIT WC_EDITW
define WC_EDIT WC_EDITA
...
define WC_EDIT WC_EDITW
...
define WC_EDIT WC_EDITA
But it's a starting place. I love Notepad++, thanks. Hope you'll let us know how this turns out.
Regards,
Brian
>The controls in them are created separately from either a resource file or a CreateWindow function with the EDIT class.
And as you can see from the second reply, the class name is the same for the W or A versions. The only difference is that the name is in UNICODE or not and that's something I can control directly when calling CreateWindowA. The problem is that some invisible hand is upgrading the edit controls in my known ANSI dialog box to UNICODE and not in every case. I can't find any options for the top level CreateWindow that might promote to UNICODE all child controls.
>post the resource code
None of it is special and I've #if 0--#endif out any code that could affect the dialog box generation. The .rc line that creates the edit control isn't special. I've copied the one from "findtext.dlg" and I've looked through all the editor messages and window options for something that would make a UNICODE/ANSI decision.
REPLACEDLG1 DIALOG 0, 0, 174, 241
STYLE DS_MODALFRAME | DS_CENTER | DS_3DLOOK | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Find/Replace"
FONT 8, "MS Shell Dlg"
{
EDITTEXT edt1, 4, 7, 165, 60, ES_MULTILINE | ES_AUTOHSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP
Some more checking shows that the big editors have solved the problem in a very simple way. Word uses a RichEdit and SC-Unipad uses it's own UNICODE editor component. Using the Scintilla editor component that drives the main window appears to be the solution that is both optimal and controllable.
Even if I figure out how to force UNICODE/ANSI edit controls I will have the problem of getting the "edit" control working properly in Win9x. It just bugs me that something is being done against my directives and noone knows why.