access violation on event handler cycle | developer.brewmp.com access violation on event handler cycle | developer.brewmp.com

Developer

access violation on event handler cycle

Forums:

I try and hit a menu item. The AVK_KEY code for the menu item runs without any errors. However, when the event handler returns TRUE and breaks to cycle, i get an access violation:

"Unhandled exception in BREW_Emulator.txt: 0xC0000005: Access Violation"

I'm using a HandleEvent function exactly like many of the BREW examples I've seen. Other menu items work fine. Just this one causes the event handler to crap itself. It is weird it dies on the event handler restarting rather than any point in the code I've writen. I wish the error was more specific!

I've read that access violations are often uninitialized pointers so I've sifted through the AVK_KEY code for anything like that ... any other suggestions of things to hunt for? TNX in advance!

Three possible and particularly hard-to-trace things that might be causing it:
Perhaps anyplace where an array might be accessed with a *negative* index (particularly if the index is specified with a variable)?
Also, if you use any code that yields in the middle to let other events through (i.e. a two-part function that calls ISHELL_Resume or ISHELL_PostEvent to access the second part of the function), make sure that any key events don't mess around with variables used by the two-part function in any undesired fashion.
Last but not least: whenever freeing something, always always ALWAYS set a pointer to a dynamically allocated object to NULL right after freeing it, even on app exit. This prevents freed pointers from being seen as valid pointers, and makes pointer-validity checking easier.
These are the ones I know of offhand (as all of the above have happened to me at one pont or another).

Three possible and particularly hard-to-trace things that might be causing it:
Perhaps anyplace where an array might be accessed with a *negative* index (particularly if the index is specified with a variable)?
Also, if you use any code that yields in the middle to let other events through (i.e. a two-part function that calls ISHELL_Resume or ISHELL_PostEvent to access the second part of the function), make sure that any key events don't mess around with variables used by the two-part function in any undesired fashion.
Last but not least: whenever freeing something, always always ALWAYS set a pointer to a dynamically allocated object to NULL right after freeing it, even on app exit. This prevents freed pointers from being seen as valid pointers, and makes pointer-validity checking easier.
These are the ones I know of offhand (as all of the above have happened to me at one pont or another).

thanks for the tips!
as it happened, the problem was a type mismatch. i was writing FileInfo data into a character array in a IFILEMGR_EnumNext(). The function still returned TRUE so it looked like everything there was going ok to me and i didn't catch the problem.
i was getting a warning message on build, but i have so many of them i just skimmed past it. time to clean up my very messy code!!!

thanks for the tips!
as it happened, the problem was a type mismatch. i was writing FileInfo data into a character array in a IFILEMGR_EnumNext(). The function still returned TRUE so it looked like everything there was going ok to me and i didn't catch the problem.
i was getting a warning message on build, but i have so many of them i just skimmed past it. time to clean up my very messy code!!!