Hi,
Dave Lippincott worte:
>>The only obvious difference is that before I lounch form C, I call
>>DmQueryRecord(). Does that function have weird side effects ?
> None that I know of. I use DmQueryRecord allot without any consequences. I
> would start looking at any strings used by form C and make sure they are not
> stomping on other variables.
Well all the strings in form C are stored in memory chunks that, as far as I
can tell, are allocated and released properly when I enter/exit the form (I
will re-check that one more time).
> You could also remove any processing done in your FrmInitForm and see if it
> returns.
I am not sure I understand that well. FrmInitForm(formID) is a system call.
I am not doing anything in there since I have absolutely no control over it!
Basically I tried many thing to switch between the forms (and all fail in
the same way).
1. call FrmGotoForm(formID) when the appropriate control was hit
2. Manually generate the sequence of action that FrmGotoForm() does (as far
as I understand it, and cutting some corners...):
myevent.eType = frmCloseEvent;
FrmDispatchEvent(&myevent);
frm = FrmInitForm(newform);
FrmSetEventHandler(frm, theformeventhandler);
FrmSetActiveForm(frm);
myevent.eType = frmCloseEvent;
FrmDispatchEvent(&myevent);
It works great most of the time, it even feels a lot snappier, but it
still fails in the same way as the "normal" FrmGotoForm method
(FrmInitForm() does not return).
> There is also a possibility you are running out of heap space. You can use
> MemHeapFreeBytes to compare the available heap before, during and after your
> routines are called.
I will look at that for sure. However I would expect a system call to return
something appropriate if it was running out of heap space, not just hang!
Anyway, I will try to check the heap regularly using MemHeapFreeBytes() and
see where I go from there.
I have been fighting with the debugger a bit also, and so far I have not
been able to examine the heap with it at all... MW on windows NT does not
tell me anything, and on my Mac with Macos 8.6, it dies as soon as the
application has finished downloading... really annoying.
I have not seen that CodeWarior R5 has issues with Mac OS 8.6, and there is
nothing on the MetroWerks web site... Does anybody have the same setup and
run without problems ? If yes what are the versions of metronub, palm os
plugin, etc in the code warrior environment ? I feel more and more like I am
in Weirdland here...
> Your description of your code is a little vague, if you are still having
> problems you may want to consider posting snippets of your code.
I know, I will look some more, and try to cut as much as necessary to
identify the common thread around the problem (or fix my bug).
Here is a preliminary run down on the sequence of system calls being
performed in 2 scenarios:
1. when I edit an existing record (the case where it fails)
2. when I create a new record (in this case everything works)
here is what happens when I edit an existing record (the case where it
freezes)
----------------------------------------------------------------------
// - in the list form
DmQueryRecord()
MemHandleNew() // a few times to put the record in the heap for editing
FrmGotoForm(the record form);
-> frmCloseForm event
MemHandleFree(some memory used to draw the list)
FrmInitForm(the record form)
FrmSetEventHandler()
FrmSetActiveForm()
-> frmOpenForm event
MemHandleNew() // memory for the form itself
// edits on the current form here...
// then when switch back to any form:
-> ctlSelectEvent
index = DmSearchRecord(myDB, myDBRecord); // to find where in the DB it is
DmGetRecord(myDB, index); // to lock it
// if by looking at the info in the DB record and in my edited record
// I think that I need to change the position of the record in the DB...
newindex = DmFindSortPosition(myEditRecord, ...)
// now we store the edited record in place
DmResizeRecord(myDB, index, requiredsize);
DmWrite(), DmStrCopy(), ...
DmReleaseRecord(myDB, index, true);
DmMoveRecord(myDB, index, newindex);
MemHandleFree() // release the memory we held for the record while editing
it
FrmGotoForm(newform);
-> frmCloseForm event
MemHandleFree() // memory held by the form itself
-> frmLoadForm event
FrmInitForm(any form) // this calls fails: it never returns...
<manual reset>
Now here is the "creation" case that works like a charm
-------------------------------------------------------
// - in the list form
-> ctlSelectEvent "clik on the new record button"
MemHandleNew() // a few times to create the record in the heap for editing
FrmGotoForm(the record form);
-> frmCloseForm event
MemHandleFree(some memory used to draw the list)
FrmInitForm(the record form)
FrmSetEventHandler()
FrmSetActiveForm()
-> frmOpenForm event
MemHandleNew() // memory for the form itself
FrmDrawForm()...
// edits on the current form here...
// then when switch back to any form:
-> ctlSelectEvent (click on button to return to the list)
newindex = DmFindSortPosition(myEditRecord, ...)
DmNewRecor(myDB, &newindex, 1)
// now we store the edited record in place
DmResizeRecord(myDB, index, requiredsize);
DmWrite(), DmStrCopy(), ...
DmReleaseRecord(myDB, index, true);
MemHandleFree() // release the memory we held for the record while editing
it
FrmGotoForm(newform);
-> frmCloseForm event
MemHandleFree() // memory held by the form itself
-> frmLoadForm event
FrmInitForm(any form) // works well, the form will appear and function...
FrmSetEventHandler()
FrmSetActiveForm()
-> frmOpenForm event
MemHandleNew() // memory for the form itself
FrmDrawForm()...
Thanks for the help.
Patrick.
--
Patrick Bihan-Faou, email: [EMAIL PROTECTED]
MindStep Corporation tel: (613) 526 5062
fax: (613) 526 2417
web: www.mindstep.com
