Power Edit not working correctly in Add mode


Legendary Poster
<Editorial Mode Begin>
I like Powerforms and what they allow you to do and build, but I swear they are quite possibly the buggiest and most inconsistent development tool I have ever worked with.
<Editorial Mode End>

This power edit form has me on the ledge, please, someone talk me down.

I have a VERY simple APPL to edit a table. For the sake of my problem lets say the table has five fields:


*Key fields

The Power Edit form has the first three fields as header Fields (FC). These serve as data entry and filter fields. When editing records they must contain values. The last two fields are in a grid. To summarize:


In EDIT_MODE the user can add, edit, delete records w/o any problems. In ADD_MODE the user can also add records w/o any problems. In both cases it uses the values entered in the FC variables when writing multiple records to the table. However, if I pass values in the FI variables and assign to the FC variables during dialog initialization as in:

FC_BranchPlant = FI_BranchPlant
FC_ItemNumber = FI_ItemNumber
FC_Lot = FI_Lot

ADD_MODE stops working, as in it wont add any records to the table. No errors, or anything just closes the form and returns to the calling form like nothing happened... which is exactly what happens... nothing.

I have tried too many things to count. Here are some of the things I remember having tried:
1. Set BC_xxxx = FC_xxxxx in various events like the Form's "Add Record To DB..." event(s) and various Grid events.
2. Assigning the FC_xxxxx = FI_xxxxx in various form initialization events (Dialog Init and Post init).
3. Creating additional form interconnect params that are not directly connected to the BV and then assigning the FC values from those. Thought for sure this would work. Nope.
4. Exactly 1 billion other things.

Basically it seems like as soon as I touch the FC variables in either the "Dialog Intialized" or "Post Dialog Init" events, ADD_MODE quits working (BTW, also tried assigning BC values in these form events as well). Just as a test I even hard coded values into the FC variables instead of using FI variables in the "Post Dialog Init" and it still breaks ADD_MODE. One very weird thing I noticed. In the debugger, the grid's "Add Grid Rec to DB" is not firing (neither is the "Update Grid Rec..." event). Litterally, as soon as I assign a value to an FC variable it doesnt even attempt a table insert or update.

I know I am probably missing something silly and I feel rediculous for having to ask this question, but I'm about ready to recreate the printer scene from the movie Office Space with my PC assuming the role of "printer". I am sure someone can tall me what little check box I forgot to check or property that needs to be set, etc.


VIP Member

Unfortunately, I don't have a solution for you...just a couple of troubleshooting ideas. It seems to be a very odd issue, indeed.

Have you tried viewing the value of SV Form_Mode in the debugger right after one or all of your FC = FI assignments? I am wondering if the engine automatically wants to assume EDIT_MODE in that scenario. That doesn't explain why the "Update Grid..." event is not firing, however.

In case this isn't one of the 1 billion things you've tried: you could try adding the remaining PK fields to the grid as hidden columns just for giggles. It would require a bit of code in add mode, but might be a worth a try.

That's all I've got. Sorry and good luck. Let us know what you find as I'm sure it will be valuable info.


Active Member
Hi Booster, Can you place those same header fields in the grid also and hide it. Assign the FC values to Grid columns(Like GC = FC) in any event like Row Exit changed - Inline or Asych.

GC Branch plant = FC_BranchPlant
GC ItemNumber = FC_ItemNumber
GC Lot = FC_Lot



Legendary Poster
Is it the subform data that's not being saved?
Does the subform data structure have the keys you mention?

Forgive me if you are doing this, but I think you need to call system Notify child to pass your keys down into the subform, no?

Plus Trigger Default Child Action needs to be used in the powerforms OK button to save both header and detail

As I said, forgive me if this is already understood but if you dont' call them the subform never knows what to save


Legendary Poster
you could try adding the remaining PK fields to the grid as hidden columns just for giggles.

[/ QUOTE ]

Good idea. I have not actually tried that. And yes it feels like I have tried a billion things but I am open to any and all suggestions. I am sure I have just done something stupid and I am not seeing it... will report back if/when I find a solution.


Legendary Poster
The grid is "connected" directly to the Power Edit form - I didn't really clarify that very well in my original post. I do have a subform on this form but it is for display purposes only.


Legendary Poster
Ok I think I figured it out. Kinda did this one to myself... and its kinda dumb... think you will like this... it's kinda funny.

On the three FC fields I had code on the changed-inline event that basically checked to see if the user had entered all three of the FC values, if so I would press the "Find" button to get any existing records. I wanted this behavior even when the user thought they were adding new records because it needed to pull up any existing records based on the three FC values (there was some validation on the form that neededs to display all records for a given set of FC key values). This all worked fine as long as I didn't try to programmatically set any of the FC variables. SO, when I programatically set the FC_xxxx variables in the dialog init event it effectively queued up the FC_xxxxx changed-inline events. It didn't fire it right away - not during form init. It fired the changed-inline events for the FC field when the user clicked OK. So this is what was happening:

1. Form Init, set FC_xxxxx = FI_xxxxxx
2. User enters records into grid
3. User presses OK
4. FC_xxxxx changed-inline event fires for all three FC fields which ultimatly presses the "Find" button..... which clears the grid... which means there is nothing to add to the DB... which means there are no "Add/update to DB events" being fired in the debugger.
5. I post rant to jdeList.com