Teflon fields

[Greg Fong]

I have a form "FORM1" that refuses to save values that I enter into certain fields. None of these fields are set as read only.
The form restrictions are as follows:

enter records
delete records
navigate
continuous enter
browse mode

The FORM1 is closed with a button containing the following code:
parentform.resynch()
parentform.close()

The weird part is that I have a button on FORM1 that calls up FORM2 and when FORM2 is opened the user is asked for a value in a field called :FORM2.QUANTITY. This value is put into the QTY field in FORM1 with the syntax :FORM1:QTY.value=QUANTITY when the Save button in FORM2 is pressed. Please note that the QTY field in FORM1 is set as a readonly field in this form.
A parentform.resynch()/parentform.close() is run and the value appears in the QTY field of FORM1. At this point I could enter a value into any one of the fields I had mentioned at the top of this message. When I press the save button on FORM1 I find that the value expected in the QTY field is there but the other values didn't stick. Any ideas?

[whanigsberg]

RE: Teflon fields

Greg:

I assume we are tring to save changes here because enter is restricted.

Why would you resynch a form just before closing it? Have you saved any changes first?

Take a look at the close-form code generated by the genie. If first commits the record (if the form is in change mode) and only then closes the form.

Bill

[Greg Fong]

RE: Teflon fields

You are right I don't need the resynch(). But when I pasted in the close form code from the genie I found that after the record was committed I can see the fields on the form going blank for a second before the form closed, I believe that the pointer went to the top of the indexed table and landed on the first record before the form closed. The result of this is that I end up with my first record being overwritten by blank fields. This doesn't happen when I simply close the form with a parentform.close(). Furthermore , I found that the information that I typed into the teflon fields didn't save with the genie generated close code either.

Perhaps it would help if I explained how my form worked.

I have the form set up so that the user can type in a partnumber into the PARTNUM field and the OnChange script of the Partnumber field will bring up the rest of the fields related to the record for the user to edit. FORM2 is set up to control the values the user is permitted to enter. The teflon fields are descriptive in nature but I would like the user to be able to change them. It is just so curious that the script in FORM2 can set the values into the record while the button containing the save/close code can't.

[Greg Fong]

RE: Teflon fields

Damn! Caught myself lying.
Please accept my apologies I gave you some incorrect information regarding FORM2.

The following section is wrong:
"This value is put into the QTY field in FORM1 with the syntax :FORM1:QTY.value=QUANTITY when the Save
button in FORM2 is pressed. "

As it turns out :FORM1.QTY is updated with a "table change_begin and a table change_end.

Sorry. Maybe this has an effect on the teflon fields.

[Tom Cone Jr]

RE: Teflon fields

Greg,

Sounds like you're writing the Qty value to the table using a reference to that table initialized in Form2. Form2's record pointer is not the same as Form1's. When the record is saved from Form2 perhaps the other fields in 'that' record are empty, so when you resynch Form1 you see the blanks. -- tom

[Greg Fong]

RE: Teflon fields

No actually the fields update with the new data when I resynch FORM1 from FORM2. When I close FORM1 I can see that the new values are in place in FORM1. At this point I am in FORM1 and I can change values as I please. It is just that when I do a parentform.commit(), I find that all the fields in the first record on the table gets overwritten by blanks except for the PARTNUM field which is changed from 0000001 to whatever the partnum was when the user edited the record in FORM1.

[Tom Cone Jr]

RE: Teflon fields

Greg,

I'm lost. Will be happy to look at the app, but I'm not getting it with the word pictures. If you can't post a working model (with detailed, step by step, keystroke by mouseclick instructions on how to see the problem), perhaps you should carefully trace through each step along the way. Alpha Five is doing what it's been told to do, the problem is that it's not obvious exactly what that might be. Something is moving the record pointer to first record, placing table in change mode, and inserting blanks in all fields except partnumber. It's going to be in your field rules, or in your form.

-- tom

[Greg Fong]

RE: Teflon fields

Perhaps it may further clarify if I told you that the table connected to FORM1 is an inventory table and FORM1 is used to edit the records in it.

The PARTNUM field has an OnChange event that enables the user to type in a partnum value. The script opens up another instance of the Inventory table and does an indexed search for the record. When the user leaves the PARTNUM field all the rest of the record appears in the form for editing. I believe that this is a common mechanism for getting an existing record on screen. Maybe there are some problems with using this mechanism when the lookup table is the same as the table you are editing.

Anyway, I have buttons on FORM1 that allows the user to manipulate the quantity and total value of inventory items. For example, one button calls up FORM2 which asks the user "How many Items are you adding to stock?" The user would type in a number and the script on the "ACCEPT QUANTITY" button on FORM2 would call up another instance of the inventory table do a fetch of the Partnum in question and update the record with the new quantity info using tbl.change_begin and tbl.change_end. After FORM2 closes I can see that the new quantity info has been entered into the record. I can at this point I can press a button called "SAVE" on FORM1. This button does nothing but a parentform.close() there is no commit()in the button push event. For all intents and purposes the forms do what I want them to do which is to allow the user to change specific values in a highly controlled environment. That is the purpose of FORM2 and it does the job well.

What has me baffled is that if I added a commit() to the "SAVE" button in FORM1, I get the behavior that I outlined previously.

[Tom Cone Jr]

RE: Teflon fields

Greg,

Perhaps the display on Form1 is out of synch with the underlying table. When commit() is received it acts on the table, not the objects displayed on the form.

And.... you're not doing commit() AFTER closing the parentform, are you? That's always problematic, since there really should be no code executing after the form closes, or is closing...

-- tom

[Greg Fong]

RE: Teflon fields

What should I use to act on the objects on the form?

I caught that one about the sequence of parentform.close() a while ago. I managed to spot that possibility and actually avoided it!. Thanks

[Tom Cone Jr]

RE: Teflon fields

Greg,

The usual approach is to resynch the form, or refresh objects known to be out of synch.

I'm out of ideas, until you are able to post a working model with step by step instructions on how to cause the problem you're describing.

-- tom

[Tom Cone Jr]

RE: Teflon fields

Greg,

I went back through this thread and now realize that you're opening multiple instances of the same inventory table at times when I would not think it's necessary.

For example, your buttons that add or subtract a quantity of an inventory item can manipulate the current instance of the table, without opening yet another instance with a second form.

Also, I don't understand why the partnum field would have an event field rule which would cause another instance of the same table to open using another form? Can't the user quick-find the partnumber before beginning edits?

The difficulty here is that you can see everything and we can only see what you describe. Will be much easier to get to the bottom of this if you can post the database... or email it to me (with instructions for triggering the problem). -- tom

[CALocklin]

RE: Teflon fields

I didn't follow this whole thing either but using the OnChange event seems a possible problem. The OnChange event triggers as soon as the first letter typed in that field.

Also, I noticed this in one of the early posts:
:FORM1:QTY.value=QUANTITY when the Save button in FORM2 is pressed. [b]Please note that the QTY field in FORM1 is set as a readonly field in this form.[b]

Is it possible that the :FORM1:QTY.value=QUANTITY seems to be putting the text in that field box but it isn't actually being put in the field because it is read only? If the field is read-only, using :FORM1:QTY.value=QUANTITY in Xbasic will not circumvent the read-only status unless you first disable read-only, THEN set the value, then reset read-only.