eh ? doesn’t have to be a file reader (though that is the traditional way of doing it as it may be useful for scripting an export with the #noprompt) , that was just an example it could be a simple initialize or do nothing.
if you just want to get the dialog settings then this would suffice
class myGameExport : public ....
{
public:
myExportOptions options;
.....
};
INT_PTR CALLBACK myGameExportOptionsDlgProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
HWND CBhwnd;
static myGameExport* exp = NULL;
switch(message)
{
case WM_INITDIALOG:
exp = reinterpret_cast<myGameExport*>(lParam);
myExportOptions& options = exp->options; ....
Edit: Thanks Klunk… I will experiment with your last example.
Also, I’ve added the following to the progressbar’s dialog procedure and will give it a try later this evening to see what happens:
case WM_DESTROY:
return IMPEXP_CANCEL;
I read on MSDN that the DestroyWindow() sends a WM_DESTROY message to the dialog... so I'm hoping this fixes my cancellation [albeit delayed] crashes-- if not, then I will abandon this custom modeless progressbar dialog and fall back to the inherent interface progressbar methods.Ok… so that seemed to make it crash faster– no dallying around. I finally got the debugger working… although it’s all greek to me. 😮
It told me no code was available for where it crashed and asked if I wanted to see the Disassembly. In the Disassembly the yellow arrow is pointing at: Address 7D61002D int 3
The callstack yellow arrow is pointing to ntdll32.dll!7261002d() :shrug:
With my elementary knowledge… I guess I need the “See ‘n Say” Debugger version–
“The Cow says Moo”
you need to find where the program exited your code either from the stack frame or stepping through from a break point and having a look at variables, pointers, return values etc.