Thanks for the reply, Joe. Responses inline below, text moved around a bit...
"Joe Malone" <[EMAIL PROTECTED]> wrote in message news:88544@palm-dev-forum... > > > I have a memory leak (2 blocks) in my application that only > > happens if the user taps the home/launcher button while in > > my first modal dialog. > > The OS simulates a tap on the default button if you switch to another > app while a modal dialog is up. Is it possible that the default button > isn't the one you want tapped? Could it be that the code for one > button releases the memory, but the code for another button doesn't > release the memory? ... > FrmDoDialog() closes the dialog when any button on the form is tapped. > > If a form's event handler returns false, that means it did not handle > the event. So, I don't understand where and why you are returning > false. I've read that is how it is supposed to work, but I've experimented and found that the Palm never hits my OK button's code. I'm completely at a loss for how it's getting out of this dialog... my theory is that the Home/Launcher button sends some sort of event that triggers FrmDoDialog to immediately return if it can't find a default button. The form looks somewhat like this: Enter password: ____ [7] [8] [9] [4] [5] [6] [1] [2] [3] [Reset] [0] [OK] Clicking Reset clears the text field. Clicking a number button adds the number to the text field. Clicking OK either closes the window quietly if the password is correct or presents an error and leaves the form open if not. All of the buttons return true (which causes the OS to not look at the event and thus not close the form) except the OK button, which returns false (and thus allows the form to close) if and only if the password is correct. Otherwise, it shows a "Wrong password, dummy!" screen and returns true to keep the form open. What I've found is that the Home/Launch button and hardware switch app buttons somehow bypass my OK code and just close the form silently. Execution resumes on the line immediately following FrmDoDialog. > I don't think you need FrmDrawForm() here. I have never had any > problem calling FrmSetFocus() before FrmDoDialog() and FrmDoDialog() > will draw the form for you. (Unless you are doing something weird in > SetFormFocusById().) I'm not. I just got tired of typing FrmSetFocus and FrmGetObjectIndex. :) However, the docs warn again doing any drawing before FrmDrawForm is called, and FrmSetFocus can do drawing can't it? > You might find this simpler: > > FrmSetActiveForm( oldActiveFormP ); > FrmDeleteForm( formP ); I came up with my sequence through trial and error. Your sequence seems to work as well and seems a great deal less kludgey, so I've switched. :) Am I right in assuming that these memory leaks will *not* be cleaned up by the OS when my application exits, so I can't really get away with shipping it like this? For reference: Here's the OK code. It's the only button that has the potential to close the dialog. static Boolean ClickOKButton(FormPtr formP) { FieldPtr fieldP; MemHandle fieldTextH; char* fieldTextP; Boolean passwordMatch; fieldP = GetObjectById(formP, UnlockEntryField); fieldTextH = FldGetTextHandle(fieldP); if (fieldTextH) { fieldTextP = MemHandleLock(fieldTextH); passwordMatch = TestPassword(fieldTextP); MemHandleUnlock(fieldTextH); } else { passwordMatch = TestPassword(""); } if (passwordMatch) { return false; // close } else { FrmAlert(PasswordFailedAlert); return true; // keep open } } -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
