Closed ssweber closed 1 year ago
This is another one that I'm pretty sure worked properly not long ago.
Another thing I want to address with virtual rows is that I would actually like to allow multiple virtual rows. For instance, perhaps you want to force some data to always be present. I think virtual should change from a bool to an int, and allow for None, VIRTUAL_ROW, and VIRTUAL_INSERTED. A row marked VIRTUAL_ROW will have its own marker style in the themepack (which defaults to no marker), and does not save to the data ase. VIRTUAL_INSERTED would have the current behavior where it has a default marker, and is expected to save to the database.
On Mon, Mar 6, 2023, 8:54 AM ssweber @.***> wrote:
In previous pulls, I had fixed a few edge cases with virtual records, by assuming dirty and update_elements if No to save.
But now seeing bugs like what happens on discard virtual on a previous(), I’m wondering if we should make it more clear that a decision is needed on the current row: either save or delete.
New behavior: Disable insert/nav/duplicate/search if current row is a virtual Add checks in insert/nav/duplicate/search if called directly in code “Current record is virtual. Please save or delete before proceeding”
I don’t know about set_by_pk or set_by_index - I think prompt_save can catch those instead of disallowing?
Excel does something similar when editing a field.
— Reply to this email directly, view it on GitHub https://github.com/PySimpleSQL/pysimplesql/issues/124, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQX2REVWREJWIVT3OOKBXMLW2XUDHANCNFSM6AAAAAAVRE5I3Y . You are receiving this because you are subscribed to this thread.Message ID: @.***>
The previous bug is fixed currently by my recent pull.
I like your ideas!
For testing and to play with ideas, set frm.set_prompt_save(False). You can then add however many virtual rows as you would like.
Looks like current limitations:
In previous pulls, I had fixed a few edge cases with virtual records, by assuming dirty and update_elements if No to save.
But now seeing bugs like what happens on discard virtual on a previous(), I’m wondering if we should make it more clear that a decision is needed on the current row: either save or delete.
New behavior: Disable insert/nav/duplicate/search if current row is a virtual Add checks in insert/nav/duplicate/search if called directly in code “Current record is virtual. Please save or delete before proceeding”
I don’t know about set_by_pk or set_by_index - I think prompt_save can catch those instead of disallowing?
Excel does something similar when editing a field.