1

I made a program similar to Notepad using Visual Studio Community 2017 on Windows 10. It uses edit control created with CreateWindow with the following styles:

WS_CHILD | WS_VISIBLE | WS_HSCROLL | WS_VSCROLL 
| WS_BORDER | ES_LEFT | ES_MULTILINE | ES_AUTOHSCROLL | ES_AUTOVSCROLL

As you see, there's no DS_LOCALEDIT. However, using EM_SETHANDLE or EM_GETHANDLE to access the buffer within the edit control seems to work flawlessly. The following is a snippet of code that does initial buffer allocation for edit control that is supposed to have been created with DS_LOCALEDIT:

HLOCAL hEditMem = ::LocalAlloc(LPTR, sizeof(wchar_t) * 51);
wchar_t* pszEdit = reinterpret_cast<wchar_t*>(::LocalLock(hEditMem));
const std::wstring strData(L"Hello");
std::char_traits<wchar_t>::copy(pszEdit, strData.c_str(), strData.size());
::SendMessageW(hwndEdit, EM_SETHANDLE, reinterpret_cast<WPARAM>(hEditMem), 0);
::SendMessageW(hwndEdit, EM_SETMODIFY, TRUE, 0);

The documentation here clearly states that:

An application that uses the default allocation behavior (that is, does not use the
DS_LOCALEDIT style must not send EM_SETHANDLE and EM_GETHANDLE messages to the edit
control.

May be someone in Microsoft inconspicuously made the DS_LOCALEDIT no longer necessary as of Windows 10 or VS 2017 ?

David Lee
  • 859
  • 1
  • 11
  • 13
  • Besides, I know that LocalAlloc is bad and it's from the 16bit era; why is edit control still using it ? May be the control's internal buffer is using something more efficient but the custom buffer, passed to it using EM_SETHANDLE, can only be allocated with LocalAlloc. – David Lee Oct 21 '17 at 07:41
  • 1
    *LocalAlloc is bad* - this is absolute false – RbMm Oct 21 '17 at 07:59
  • 2
    MSDN docs for very old horses like the Edit control have a knack for being stale. That dialog style just doesn't mean anything anymore today. [From the docs:](https://msdn.microsoft.com/en-us/library/windows/desktop/ff729172(v=vs.85).aspx), "Applies to 16-bit applications only". Also the last time that LocalAlloc wasn't the same as HeapAlloc. Afaik you could still run such code on the 32-bit version of Windows, but finding a working 16-bit compiler to test this would be an effort :) Got started wrong anyway, the style flag would apply to the parent, not the control. – Hans Passant Oct 21 '17 at 07:59
  • @RbMm Thx! u r right. [Here](https://stackoverflow.com/questions/34326835/localalloc-vs-globalalloc-vs-malloc-vs-new) I found that LocalAlloc is just a wrapper that calls HeapAlloc in 32bit windows. I guess I should start questioning the docs that I take too much for granted. – David Lee Oct 21 '17 at 08:13
  • 1
    @DavidLee -yes `LocalAlloc(0,cb)` is = HeapAlloc(GetProcessHeap(),0,cb)` also exist big count of system functions which allocate memory for you and you need fee it by call `LocalFree` - so system yourself very active use LocalAlloc/LocalFree – RbMm Oct 21 '17 at 08:17
  • @HansPassant Someone in microsoft should do something about the stale docs. I guess I learned an important lesson today that I should not take msdn docs as god made docs. – David Lee Oct 21 '17 at 08:18
  • 1
    Meh, the only problem you had is that you did not have a problem. – Hans Passant Oct 21 '17 at 12:48
  • Raymond Chen covered this today: [The Old New Thing: In 16-bit Windows, some per-process data structures were really per-data segment](https://blogs.msdn.microsoft.com/oldnewthing/20181220-00/?p=100525) – Brian Dec 20 '18 at 15:08

1 Answers1

2

Since no answer from anybody, I decided to answer my own ...

Using heuristic approach, I came to the following conclusions, which are unlike what's written on MSDN docs:

  1. DS_LOCALEDIT is not a prerequisite for EM_SETHANDLE or EM_GETHANDLE, which means that the EM_XXXHANDLE can be used even when you're not managing the buffer customarily.
  2. EM_GETHANDLE seems a far better choice than the WM_GETTEXT when all you need to do is just refer to a portion of text in edit control.
  3. DS_LOCAEDIT seems to be obsolete, as I was able to set my own custom buffer without it. (As a side note, all I needed to do to increase the custom buffer, in response to EN_MAXTEXT, was to send EM_SETLIMITTEXT message with new size as parameter)

To me the second one was particularly important when implementing text find/replace using FindText and ReplaceText; you don't want to copy all the text from the edit control, using WM_GETTEXT, just to search for certain keyword, would you?

I still haven't tested if plain old new can substitute LocalAlloc when setting custom buffer with EM_SETHANDLE.

David Lee
  • 859
  • 1
  • 11
  • 13