Ok, my bad, I should have mentioned that having an overall plan would be best before embarking on drastic measures like removing a resource. As there are simpler approaches to overriding runtime code (mentioned in a prior post), there are simpler solutions to this too (as noted by RP). I would suggest starting with a program structure that is flexible enough to grow and withstand enhancements and maintenance as suggested by Jay. Adding new code to a sound structure is much easier than struggling with something less than sound and it allows easier integration of existing FB runtime tools. I know this has been conveyed on the list before, but I'm sure many of us can feel the pain based on the road currently being traveled by your program and are trying to help you avoid extra work later. Brian S. On Sep 19, 2004, at 1:06 PM, Brian Heibert wrote: > That worked I opened the application after compiling it (compiling it > for a > test) changed the DLOG resource to what I wanted and it now displays > my > dialog. However I realize I will have to save my test app till my > final app > is built then copy the DLOG resource over to the final app. That's ok. > > Brian > > On 9/19/04 2:42 PM, "Brian Stevens" <brilor@...> wrote: > >> Maybe just remove the FB DLOG resource (and DITLs) from the final >> built >> application. >> >> >> On Sep 19, 2004, at 11:47 AM, Brian Heibert wrote: >> >>> I am using a custom STOP dialog instead of the one FB provides >>> My dialog appears but so does the FB STOP dialog how do I get it so >>> The FB STOP dialog does not appear? Is that possible? >>> >>> Brian >>> >>> LOCAL FN doStop (MSG$) >>> CALL PARAMTEXT (MSG$,"","","") >>> controlnum%=FN STOPALERT (131,0) >>> long if controlnum% = 4 >>> END >>> end if >>> long if controlnum% = 2 >>> gosub "main" >>> return >>> end if >>> END FN = controlNum% >>> >>> >>> ON DIALOG FN doDialog >>> ON MENU FN doMenus >>> ON STOP FN doStop ("Stop Program?") >>> >>> Do >>> HANDLEEVENTS >>> UNTIL gFBQuit >>> >>> -- >>> >> >> -- >> > > -- >