I still think this is a stack problem, all of your parameters and automatic
(local) variables should be placed on the threads own stack, which I
believe grows downwards (in your case the last stack entry would be
delFileName). If any called functions write passed the end of delFileName
then your other parameters and return address (also on the stack) may be
corrupted. I don't think that swat will be able to give you any useful
information about this, other than that you can see the parameters screw
up. To verify that this is happening try doing a backtrace in swat before
and after the MSG_GEN_FILE_SELECTOR_GET_SELECTION call, and see what
happens. If you have a nice function call trace then your stack is OK, if
not then it is definately corrupted.
Another simple test is to change the line
char delFileName[13];
to
char delFileName[50]; /* BIGGER BUFFER */
and see if this works
Happy hunting
Alan M
----------
> From: CamiLee@aol.com
> To: geos-dev@lifelike.com
> Subject: Problem spotted.
> Date: 17 February 1997 09:53
>
> Well, after looking some more, I finally printed up some useful
information
> for myself. :D
>
> Apparently when the process calls the GenFileSelector for the selection,
the
> localwin variables change from this:
>
> parameter dword trigger at [bp+6]=4640h:0058h
> parameter enum IDEProcessMessages message at [bp+10] =
MSG_DELETE_FILE_DIALOG
> parameter dword oself at [bp+12= 4510h:0000h
> local char delFileName[13] at bp-14] =
> {\2201\227\002\262m\203\n\223m\262\030\000}
>
> To (the ones that need seeing anyway):
>
> parameter dword trigger at [bp+6] = 0d0eh:0000h
> parameter enum IDEProcessMessages message at [bp+10]= 0(invalid)
> parameter dword oself at [bp+12]= 1448h:0d20h
> local char delFileName[13] at [bp-14]={Y\237fR\262\030\263\036\17\(\000}
>
> Now, from this I figure the trigger has lost its own reference based on
the
> changed values for the trigger, the message and oself.
>
> Here's the code I'm using in the message that does this.
>
> /********************************************************************
> * MSG_DELETE_FILE_DIALOG
> ********************************************************************
> * SYNOPSIS:
> * CALLED BY:
> * PARAMETERS:
> * RETURNS:
> * SIDE EFFECTS:
> * STRATEGY:
> *
> *******************************************************************/
> @method IDEProcessClass, MSG_DELETE_FILE_DIALOG
> {
> char delFileName[13];
>
> /* Open the dialog box to display the file being deleted. */
>
> @call DeleteFileDialog::MSG_GEN_INTERACTION_INITIATE();
>
> @call IDEFilesSelector::MSG_GEN_FILE_SELECTOR_GET_SELECTION(delFileName);
>
> @call DeleteFileText::MSG_VIS_TEXT_REPLACE_ALL_PTR(
> delFileName, 0);
>
> }/*MSG_DELETE_FILE_DIALOG*/
>
>
> When I tried code to dereference itself, it fatal errored on me, so I'm
not
> sure what I'm doing wrong on this to make it lose itself. Since I'm
> executing it from the Process thread, I'm curious why it's changing at
the
> second message call, since the Dialog box, in this version is already on
> screen, and by the last message call, the file name has been properly
entered
> into the dialog box.
>
> Maybe I'm just getting dense or something, but I just don't see it. :(
>
> Lee