The field UI function
FldNewField
returns a pointer to Field, which, if used straight away,
gives no problems, e.g. in FldSetTextPtr(...).
But if I save the field-pointer and try to use it later,
very nasty things happen. Obviously it has been moved
around in memory, I suppose. The FrmGetObjectPtr(...)
function returns a different pointer at a later time.
I understand that the memory model is based upon movable chunks
to deal with fragmentation because a paging model (virtual addresses)
is not being used.
But I wonder if the return pointer from the FldNewField(...)
function was really supposed to return the address of _locked_
memory.
The fact that fields in a form do not seem to be lockable
seems to imply that I can't just save an array of pointers
to my 66 fields which I create dynamically.
Question:
Can anyone confirm that programmers really are expected to
call FrmGetObjectIndex(...) and FrmGetObjectPtr(...)
every time they want to read/write them?
It seems like any create/delete/resize action on the fields of
a form could result in the fields moving around.
So if I fetch a field-pointer, and then do something
else with the form, then an access to the field-pointer could
be invalid.
Question 2:
Under what circumstances can I assume that a field-pointer
will _not_ change, and therefore is safe to use?
Cheers,
Alan Kennington.
--------------------------------------------------------------------
name: Dr. Alan Kennington
e-mail: [EMAIL PROTECTED]
website: http://www.topology.org
city: Adelaide, South Australia
coords: 34.89744 S, 138.58970 E
pgp-key: http://www.topology.org/key_ak1.html
saying1: `The Internet is the parliament of the people.' ak 28/5/1999.
saying2: `Seek truth from facts.' mao or deng, 1970s?
