Nettalk NetWebBrowse -- After Delete

[KevinErskine]

I have asked ClarionAssistant and Claude.ai and can not find the right embed to add code after a successful delete from a NetWebBrowse inline delete button for a row/record.

Anyone have an idea?

[Nardus_Swanevelder]

@KevinErskine

can not find the right embed to add code after a successful delete from a NetWebBrowse inline delete button for a row/record.

I asked my Clarion Assistant to use the NetTalk book and then I asked him your question. This is the answer:
Found it, and the reason they can’t find the embed is that they’re looking in the wrong procedure.

The delete isn’t done by the browse — it’s done by the form. The in-row Delete button on a NetWebBrowse routes to the form procedure in Delete mode. The confirmation dialog (“Prompt for Confirmation”, Title, Question, Yes/No text on the browse’s Form tab) is just browser-side; when the user confirms, the browse hands off to the NetWebForm and the form does the actual delete. That’s why there’s no “after delete” embed anywhere in the browse — it doesn’t exist there.

So the embed they want is the PostDelete routine in the NetWebForm procedure that the browse’s Delete button calls.

From the book (page 407, “Understanding Generated Code”):

The first is to the ValidateAction routine, where action is one of Insert, Copy, Update or Delete (for example ValidateInsert)… If loc:invalid and loc:alert are not set then the record is written to the disk, and the form called for one last time. This time it is the PostAction routine which is called. This allows you to embed code that will happen after a record is written to the disk, such as add to a log or something of that nature.

That gives them the pair they need:

• ValidateDelete — runs before the delete, and is where you abort it. Set loc:invalid and loc:alert (both generated locals) to stop the delete and show the user a message. Note the book calls out that ValidateDelete is the one action routine that does not call ValidateRecord.
• PostDelete — runs after the record is gone from disk. This is the “add code after a successful delete” embed.

Two things worth warning them about:
The form is an event handler, not a procedure, so tables are not left open for you — in PostDelete they should assume tables are closed and open/close what they need manually. And they should work with session values rather than file fields; by PostDelete the record is deleted, so if they need field values from the deleted record (for a log entry, say), they must grab them in ValidateDelete and stash them in a session value or local.

To find it in the app: open the form procedure (not the browse) in the embeditor and search for PostDelete. If they’d rather use the embed tree it’s under the form’s routine embeds.

One caveat on sourcing — the book’s page 407 explicitly confirms the ValidateDelete/PostDelete routine pair and what they’re for. The “browse hands off to the form” architecture I’ve pieced together from the NetTalk 14 template docs (the browse’s Form tab has a per-button “Procedure for Delete” setting, which only makes sense if the delete goes through a form) plus the same design in the ABC book. If their browse’s Delete button has no form procedure set, that assumption may not hold — worth a quick check before they go hunting.

[KevinErskine]

Thank you - I was just having brain fog i guess - i appreciate your help

[Jane]

Another option if you want the effect not to be limited to that particular browse/form - you can try global embeds in the File Manager for the particular table.