Under what circumstances will a dialog box not use the caption specified in the resource file?

Could it be space aliens?

Under what circumstances will a dialog box not use the caption specified in the resource file? In particular, we have a modal dialog box that is not using the caption from the resource file. Even if we explicitly call Set­Window­Text from within the WM_INIT­DIALOG handler, the call succeeds but the caption remains unchanged.

The dialog box's initial title is the value specified in the resource template. And if you set it again in the WM_INIT­DIALOG handler, then that new title overwrites the title from the resource template. Perhaps the problem is that some other code that runs after your WM_INIT­DIALOG handler is changing the title yet again.

The customer sheepishly wrote back,

[banging head against the wall]

Being skeptical that there could ever be anything else overwriting the code I went to debug with Spy++. After some considerable effort I found out that yes, further down ~30 lines there's a call to Set­Window­Text that changes the title to something else.

Thanks for making me look again.

Sometimes the fault is not in our stars but in ourselves.

Comments (6)
  1. John Doe says:

    I miss the technet magazine…

  2. Brian_EE says:

    Sometimes when in the thick of debugging a problem it is easy to get so focused on one part of the problem that you become myopic to other possibilities. What I find strange is that they asked MS about this without (I'm assuming here) asking another set of eyes within his own group to look at the code.

  3. Joe says:

    At least the customer was courteous enough to respond. They usually just vanish when they've overlooked the obvious solution.

  4. Joshua says:

    Once upon a time I filed a bug against .NET 2.0 after having this weird behavior in production we were failing to track down. Process Explorer would show a stack trace going straight from acquire semaphore from create thread, in a pattern that indicated livelock. Windbg kept on crashing the process trying to get good information out of it.

    Turned out it was my own bug requiring a novel set of circumstances to create, and Process Explorer can't generate correct stacktraces of .NET process in all cases. Given the bug was a simple spinning thread repeatedly acquiring and releasing a semaphore in a loop, I never was able to learn why Windbg kept crashing the process being debugged.

    The amusing thing is typing an incantation into Google that should mostly match that stack traces found a lot of others complaining about the exact same bug that I reported (which did not exist).

  5. 640k says:

    If you have already payed MS (or another company) for doing time consuming debug work, don't spend time doing it yourself, learn to outsource the work. It would actually be irresponsible to do it yourself, then you spend resources twice.

  6. Neil says:

    Firefox's windows are simply documents in an XML dialect, but the title setting code used to run at different times depending on whether you loaded the document as a new window or as a frame in the browser, causing no end of confusion.

Comments are closed.

Skip to main content