[comp.windows.ms] Dialog boxes multiplying like rabbits

tom@mims-iris.waterloo.edu (Tom Haapanen) (09/06/90)

I'm working on a medium-sized Windows application (~20,000 lines) using
SDK 2.1, and I'm running into a bizarre problem.  I have a dialog module
for opening a file; it works fine for opening an application's main data
file.  However, when I call it from another dialog box procedure (to open
an auxiliary file), it appears OK, and I can select a file no problem,
but it won't go away.  When the file dialog procedure processes the OK or
Cancel message, it never returns from the EndDialog() call!  More exactly,
it destroys the file dialog box from the screen, but immediately creates
another file dialog, and then another, until finally I get a stack overflow. 
Ctrl-Alt-Del is  the only way out --- and yet the file dialog box works fine
for the other, my main File Open call.

I've been spending hours on this, and endless reading of docs -- what could
I be doing wrong?  I'm quite sure I'm allowed to have a modal dialog box
call another modal dialog box --- that's the way Printer Setup works, too!
Where can I look?

I can send a code segment to anyone who's willing to look at it...

[ \tom haapanen --- university of waterloo --- tom@mims-iris.waterloo.edu ]
[ "i don't even know what street canada is on"               -- al capone ]

johnm@spudge.UUCP (John Munsch) (09/11/90)

I had some problems with a dialog box of my own that weren't very different
from your own and they turned out to be...

[drumroll please]

I was an idiot and forgot to export the dialog box function.  Since none
of the development tools warn you of an unexported function it is an easy
mistake to make and the results can be incredibly weird.

John Munsch

P.S.  Please don't be insulted that I should suggest something so basic, it
happened to me and it can happen to others.

kensy@microsoft.UUCP (Ken SYKES) (09/17/90)

In article <21114@spudge.UUCP> johnm@spudge.UUCP (John Munsch) writes:
>I was an idiot and forgot to export the dialog box function.  Since none
>of the development tools warn you of an unexported function it is an easy
>mistake to make and the results can be incredibly weird.
>
>John Munsch

One way to avoid this is to use the _export keyword.  So instead of a
Window function that looks like

DWORD FAR PASCAL WinProc(...)

it looks like

DWORD FAR PASCAL EXPORT WinProc(...)

where you have

#define EXPORT _export

defined someplace convenient.

This way the export is defined with the procedure instead of someplace 
seperate.

Ken Sykes
Disclaimer: The above opinions are solely my own.