Michael S. Davis wrote:

> On Mon, 21 Jun 1999, Elia J. Freedman wrote:
> 
> > That should bomb.  What you need to do is use FldSetTextHandle or call
> > FldDelete and FldInsert.  With FldDelete and FldInsert, however, you will
> > need to make the field editable first, change the text, and than make it
> > uneditable again.
> 
> It does not bomb at all.  But, I need to get to the bottom of this.  I
> have a function SetFieldText that does use FldDelete and FldInsert for
> editable fields and FldSetTextPtr for non-editable fields.  But, what does
> FldInsert do that allows me to use these literal strings?  
> 
> I guess I could take your suggestion and make the field editable then
> change the text and switch it back to non-editable but I'd like to
> understand what happens that makes one method work and the other not work
> (even though it seems to work).
> 
> Thanks
>  
> > -----Original Message-----
> > From: Michael S. Davis [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 21, 1999 11:49 AM
> > To: [EMAIL PROTECTED]
> > Subject: Field Pointers: Data persistency
> > 
> > 
> > I have noticed something in my code that might be a problem.  So, far I
> > have not experienced any problems but I'm wondering if this is a bad way
> > of doing this.
> > 
> > I have a status field where I display a string of one char.  That field is
> > a non-editable field and I use FldSetTextPtr to set the text value to
> > display.  My problem is that I use FldSetTextPtr within an event handler
> > and use a literal string.
> > 
> > I'm wondering if there will be a problem since this pointer only exists
> > within the handler might not be valid pointer at some later time.  Or,
> > does the fact that I am using a literal string guarantee that the pointer
> > will always be valid?
> > 
> > For instance, within the OK button handler, I might have:
> > 
> > FldSetTextPtr(fldP, "Y");
> > 
> > Now if I redraw the Form or Field at some later time, will the
> > pointer still exist?  Should field data be kept in Global variables?

It works because your C compiler puts the "Y" somewhere in memory, then 
pushes that address onto the stack when preparing to cal FldSetTextPtr. 
In my experience, that memory is valid when your app has been launched 
normally, but is not valid when your app doesn't have its globals (i.e. 
when it's been launched due to an alarm, etc.). If your app is never 
launched "abnormally" (so to speak) then you have no reason for 
concern.

--
Roger Chaplin
<[EMAIL PROTECTED]>

Reply via email to