Инглиш маст дай

Я тебя породил, я тебя и убью. Писать надо на своем языке, у англичан есть всякие stackoverflow

for optimization

Feedback on “Design of Everyday Things” by D.Norman

Some time ago we’ve discussed general GUI improvements which might greatly improve usability in some lucky release. We’ve even investigated Adobe and other software, for comparing reasons.

From reading “Design of Everyday Things” I’ve learned that in development process, and even in GUI improvement, we miss user feedback.

Example 1

A company was selling car of one model, while having already developed second model. Car #1 has got recognition from automobile community, got prizes on car show. But they didn’t get feedback from customers. Car #2 has adopted some issues from car #1. Design #2 didn’t react any negative feedback from car #1.

We have the same, while developing release #4, we put release #3 GUI errors to backlog. We even don’t have anything special for usability, and users don’t file DRs, since usability issues are not errors. But some issues are very urgent, and easy to fix. If we had official usability channel for handling GUI issues which are easy to fix (alternative to DR bug tracking), we might better keep/satisfy some customers.

I adore AE's work of features,  predicting future needs, so that we have good future. But when relating only on application engineers (not customer feedback), all GUI related things will go to backlog, while 1/5 of GUI things are urgent for customer and are very easy to fix.

ON_NOTIFY vs. OnNotify

It is not always easy to catch WM_NOTIFY send from control to its parent window. 

In this case they want to notify parent CFileView from control CViewTree with WM_NOTIFY TVN_SELCHANGED message. And here message map just doesn't work:

ON_NOTIFY(TVN_SELCHANGED, 4, OnItemsSelChanged)

They should do it in virtual OnNotify function, not using message map. If OnNotify doesn't met correct handler, message would go to parent CMainFrame, and there you can use message map.

BOOL CFileView::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
   if (nmHdr->idFrom != 4)
      return CDockablePane::OnNotify(wParam, lParam, pResult);
   if (nmHdr->code == TVN_SELCHANGED)
   {
      OnItemsSelChanged((NMHDR*)lParam, pResult);
      return TRUE;
   }
   return FALSE;
}

Decryption of DLGINIT .rc file entry

Visual Studio saves ComboBox item list in DLGINIT entries of .rc files as ASCIIZ strings, in WORD format:

IDD_DIALOG1 DLGINIT
BEGIN
    IDC_STR1, 0x403, 16, 0
0x7241, 0x2063, 0x6c63, 0x636f, 0x776b, 0x7369, 0x0065,

    IDC_STR2, 0x403, 18, 0
0x6c41, 0x6177, 0x7379, 0x6120, 0x2074, 0x6874, 0x2065, 0x6964, 0x0065,
    0
END

Using simple type conversion we can reveal, what do these strings contain.

Understanding Mutex entity

Studying example from MSDN article Using Mutex Objects some questions arise about mutex entity.
Here are experimentally proved suggestions:

1. Mutexes are like files, open and create them with CreateMutex, close with CloseHandle (for files you use CreateFile, CloseHandle)
2. Unnamed mutex is like critical section
3. Mutexes are deleted after CloseHandle when no application currently have them opened

You can understand these things from running 10 simple programs which in short do the following:

HANDLE h
main(){
  h = CreateMutex("Global\\SuperMutex")
  CreateThread(WriteToDatabase)
  CloseHandle(h)
}

WriteToDatabase()
{
  WaitForSingleObject(h)
  ReleaseMutex(h)
}

Some programs create h = 0x3c, some h = 0x44
Some create mutex via CreateMutex while having ERROR_ALREADY_EXISTS

Pic 1. Running 10 of these programs:

Example sources are here...

Test f() for multithreading

Here is a copy-paste template to test your code for multithreading. Let's say you want to test your function

int f() { ... }

for multithreading. Use this code to test f() running from number of threads simultaneously:

struct TESTPARAM
{
   int threadNo;
   LONG* m_pnCount;
};

DWORD WINAPI _msgTestThread(void* pParam)
{
   TESTPARAM* par = (TESTPARAM*)pParam;
   char buf[1014];

   int tmax = 1000;
   int tstep = 100;
   for (int t = 0; t<tmax; t+=tstep)
   {
      f();
      Sleep(tstep);
   }

   InterlockedDecrement(par->m_pnCount);
   delete par;
   return 0;
};

int Start()
{
   LONG nThreadCount = 0;
   int THREAD_MAX = 10;

   //msg::Message threads
   for (int i = 0; i<THREAD_MAX; i++)
   {
      //new, otherwise TESTPARAM will not reach thread in _msgTestThread,
      //and will be deleted on closing scope }
      TESTPARAM * par = new TESTPARAM;
      par->threadNo = i;
      par->m_pnCount = &nThreadCount;
      InterlockedIncrement(par->m_pnCount);
     
      DWORD dwThreadID = 0;
      CreateThread(0, 0, _msgTestThread, par, 0, &dwThreadID);
   }

   //Call window procedure until threads are finished
   while (nThreadCount > 0)
   {
      MSG msg;
      if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
      {
         TranslateMessage(&msg);
         DispatchMessage(&msg);
      }
      Sleep(10);
   }
}