Show Buttons (Insert button) on Browse

[CaseyR]

Hi,

Because I often use memory forms to receive user input this situation comes up fairly often:

a browse with the physical table;
the form procedure associated the browse is just used to delete the physical record by a Delete button on the row;
a button (Other) on the row for updates that calls the memory form procedure with the ID for the physical record that is used to populate the form.

The problem is the insert.  If I use the Show Buttons Insert that calls the memory form,  it includes the last selected physical record ID as a value which causes the memory form to populate.

The Delete button does not work as a separate procedure call as Show Buttons Delete, so the delete procedure stays as the primary form procedure associated with the browse.

So, is there a way to call the memory form procedure as a Show Buttons insert without including the physical record ID as a value?

OR

How do I put a stand alone button that calls the memory form on a NetWebPage which I will follow with the browse as a simple tag?

I have worked around this problem by menu item placement and button/browse placement on parent forms, but it looks and is cumbersome.

Thanks.

[Bruce]

Hi Casey,

just so I'm clear:

By "Show Buttons Insert" you mean the insert button below (or above) the browse itself, not an in-row browse button?

And basically you are wanting a different form to be used for Insert and Delete? Is there a Change button in the mix, or not?

And lastly - On Insert, you want the memory form to clear the record presenting the user with a "blank form" whereas currently it presents it with a "pre-poulated" form?

Am I on the right track?

Cheers
Bruce

[CaseyR]

Hi, Bruce.

Sorry for the delay.  I went camping for the weekend.

By "Show Buttons Insert" you mean the insert button below (or above) the browse itself, not an in-row browse button?

Yes.

And basically you are wanting a different form to be used for Insert and Delete? Is there a Change button in the mix, or not? 

The default Change button would work if the Delete procedure wasn't different from the Insert/Change procedure and needed to be the primary form procedure for the browse.  Instead, I use an 'Other' button on the browse row that calls the Insert/Change memory form with the record ID, which triggers populating the memory form with the relevant data.

And lastly - On Insert, you want the memory form to clear the record presenting the user with a "blank form" whereas currently it presents it with a "pre-poulated" form?

Am I on the right track?


Almost.  The memory form doesn't have to clear anything, it just has to skip the populating step.  It is the existence of a passed record ID that triggers the populating and determines whether the parent record is updated or added on Save.

My current approach is to call the form for Insert as a separate sub item on menu,  or having the Insert button and the browse as two separate items on a tab of a larger form when available.   Works, but makes for a cluttered menu and inconsistent UI.   Another alternative is to make a duplicate form for each of these situations, identical except of the populating and record update code.  Easy to do, but future maintenance issues abound given the number of duplicates involved.

So the best situation would be having the Insert button pass another value that can be used to skip the populating routine,  or having the Delete button procedure work without being the primary form procedure for the browse.

Second best, would be a way to include both a Insert button and a browse on a NetWebPage

Thanks

[Bruce]

Hi Casey,

this paragraph needs some more digging;

>> The memory form doesn't have to clear anything, it just has to skip the populating step.

Memory forms don't have a populating step. By definition, they are not tied to any Table, and so can't populate from any table. If you are seeing stuff as the form opens, then what you are seeing are the current contents of the Session variables.

Yes, some session values are primed when the _bidv_ value is included in the link, but the correct thought then would be for the Mem form to just clear the session values it wants to be blank.

>> It is the existence of a passed record ID that triggers the populating and determines whether the parent record is updated or added on Save.

again, a memory form isn't bound to a table, so there is no update / insert on save - unless that is code you have handled yourself.

I'm thinking that maybe this would be an excellent question to explore in the webinar on thursday as it sounds like you have a number of factors in play here, and possibly the odd misunderstanding.

Cheers
Bruce