Re: Static variable in dialog box proc

From:

"Alf P. Steinbach" <alfps@start.no>

Newsgroups:

microsoft.public.vc.language

Date:

Tue, 29 Jul 2008 23:13:02 +0200

Message-ID:

<p8edncVmX6GAFRLVnZ2dnUVZ_vudnZ2d@posted.comnet>

* Vincent Fatica:

On Tue, 29 Jul 2008 16:33:35 -0400, Victor Bazarov <v.Abazarov@comAcast.net>
wrote:

It happens even with this dlgproc:

INT_PTR CALLBACK BoxProc(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    static BOOL b = FALSE;
    if ( b ) return TRUE;
    return FALSE;
}

Without the "if" statement, the dialog box is drawn correctly (as specified in
my resource).

With the "if" statement, it's grotesque looking.

Can you see what the assembly code for that function looks like?

Unfortunately, that poses a steep learning curve. My app is a DLL, a plugin for
a 3rd party command processor

Oh well. It may be that in some way that 3rd party app loads your DLL in a way
so that you don't get proper initialization of statics. Have you tried something
simple like

static bool b = (IDOK == MessageBox( 0, "Blah", "Poi", MB_OKCANCEL |
MB_TASKMODAL );

just to see whether that initialization is performed.

Disclaimer: off-the-cuff code.

If initialization is the problem then you need to take charge of DllMain.

(I write extensions to the command processor, the
user can invoke "commands" I supply, my functions are called with a string of
user-supplied args so they appear as built-in commands). In addition, I rarely
make debug builds and I stink at using a debugger. :-(

Tracing is a nice technique. Just output to a file or whatever.

Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?