Persistence woes

I'm still missing something about persistence. Today (so far) was much like the Disastrous ListMaker day. Deleting items wasn't working -- my solution in place at the moment is to call fill_edit_display both in the Page_Load and at the end of the remove_Item method. (fill_edit_display just draws the pretty table and puts data in it from the dataset...)

If it's just in the Page_Load method, then when you click Remove to remove the item, neither my debug label nor the list_display update until you click another button that refreshes the page (no matter that Remove appears to refresh the page). If it's just in remove_item, then remove_item doesn't even seem to be called -- note that fill_edit_display is responsible for creating the remove_item buttons -- but how can I see them if they aren't there, hm?

delete_this, which deletes an entire list, has this characteristic as well -- that is, it calls populate_edit_list before it ends, and this is also featured in the Page_Load.

I think it must be because both remove and delete buttons are programmatically created rather than originally in the default document. It must be related to when the app actually creates the controls themselves in the lifecycle of the page. For now, I'm just glad it seems to work.