Created attachment 125694 [details] Test database Running Version: 5.2.0.0.beta2 Build ID: ae12e6f168ba39f137fc110174a37c482ce68fa4 CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; Locale: en-GB (en_GB.UTF-8) On ubuntu 16.04. Open the attached database. In Forms, edit AlbumArtists. Modify the size of the Filter Button. The form is marked as modified (on the 'save' button). But nothing happens when I try to save, and there is no 'save' option on the file menu.
Hi Tim, FYI, this is a known issue, but I need to find the previous report.
Hmm, the previous issue I was looking for was the fact that the Save button always appears as if changes were made even if the form had been saved and no other changes were made, whereas you are saying that there is no Save entry in the menu. I will check against my master build.
Version: 5.3.0.0.alpha0+ Build ID: 637371d4d90c2403f02d588ebe745368014b1032 CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; Locale: fr-FR (fr.UTF-8) Tim, there should be an entry in the main File menu called "Update -", the keyboard shortcut for which is Ctrl-S (or Cmd-S on the Mac). This saves the form changes for me. Quite why the wording was changed to Update is beyond me, that was clearly a UX decision, probably because of the new Save button with the dropdown menu. The fact that the Save button doesn't change to represent the new state of the form is bug 95214. Setting as WFM unless there is something I have missed.
(In reply to Alex Thurgood from comment #3) > Version: 5.3.0.0.alpha0+ > Build ID: 637371d4d90c2403f02d588ebe745368014b1032 > CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; > Locale: fr-FR (fr.UTF-8) > > Tim, there should be an entry in the main File menu called "Update -", the > keyboard shortcut for which is Ctrl-S (or Cmd-S on the Mac). This saves the > form changes for me. Quite why the wording was changed to Update is beyond > me, that was clearly a UX decision, probably because of the new Save button > with the dropdown menu. > > The fact that the Save button doesn't change to represent the new state of > the form is bug 95214. > > Setting as WFM unless there is something I have missed. I tried 'update'. It doesn't work, and the 'save' button still indicates that there are outstanding edits. On closing the edit form and re-opening it has not changed.
And if I do an edit and close the form without attempting to update/save it doesn't ask if I want to save the form.
I have reopened this (apologies if that's a break in protocol). There is no method by which I can save an edited form. That's critical for me.
(In reply to Alex Thurgood from comment #3) > Version: 5.3.0.0.alpha0+ > Build ID: 637371d4d90c2403f02d588ebe745368014b1032 > CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; > Locale: fr-FR (fr.UTF-8) > > Tim, there should be an entry in the main File menu called "Update -", the > keyboard shortcut for which is Ctrl-S (or Cmd-S on the Mac). This saves the > form changes for me. Quite why the wording was changed to Update is beyond > me, that was clearly a UX decision, probably because of the new Save button > with the dropdown menu. > > The fact that the Save button doesn't change to represent the new state of > the form is bug 95214. > > Setting as WFM unless there is something I have missed. Can you reproduce the problem I have in 5.2? If this is not fixed, version 5.2 will be totally unusable.
With Version: 5.2.0.0.beta2 Build ID: ae12e6f168ba39f137fc110174a37c482ce68fa4 CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; Locale: fr-FR (fr.UTF-8) 1) Opened test ODB file. 2) Opened form in Form edit (design) mode. 3) Re-sized push button. 4) Closed form without saving 5) Crash
Retried using same steps as in comment 8, except that I tried : - saving with Cmd-S - saving via the File - Update menu entry Made no difference, each time I close the form window, I get a crash. Additionally, whilst the menu entry appears to be activated, the changes to the form are not saved. Confirming
Caolan : the sudden crashing on window dispose sounds like something you might be interested in ?
Note that I couldn't reproduce in my master build so maybe a fix has gone in that needs backporting ?
The crash referred to in comment #11 is (fixed) bug #100140
(In reply to Alex Thurgood from comment #10) > Caolan : the sudden crashing on window dispose sounds like something you > might be interested in ? My system doesn't crash in 5.2 beta at the time I try to save, it just refuses to save (or update as it is now called for reasons that escape me).
The save problem was also fixed by the commit of Bug 100140. *** This bug has been marked as a duplicate of bug 100140 ***
I just tested this for the failure to save in 5.2.0.0. So, in Version: 5.2.0.1 Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; Locale: en-GB (en_GB.UTF-8) All is OK. There is no crash, and I can save the edited form. I'm also happy to see that I can still 'Save' rather than 'Update' :-) Should I close this?
(In reply to tim from comment #15) > I just tested this for the failure to save in 5.2.0.0. > > So, in Version: 5.2.0.1 > Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d > CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; > Locale: en-GB (en_GB.UTF-8) > > All is OK. There is no crash, and I can save the edited form. > > I'm also happy to see that I can still 'Save' rather than 'Update' :-) > > > > Should I close this? @Tim : it is already closed, since marking as DUP closes the report, but adds a link to the other report.
(In reply to Alex Thurgood from comment #16) > (In reply to tim from comment #15) > > I just tested this for the failure to save in 5.2.0.0. > > > > So, in Version: 5.2.0.1 > > Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d > > CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; > > Locale: en-GB (en_GB.UTF-8) > > > > All is OK. There is no crash, and I can save the edited form. > > > > I'm also happy to see that I can still 'Save' rather than 'Update' :-) > > > > > > > > Should I close this? > > @Tim : it is already closed, since marking as DUP closes the report, but > adds a link to the other report. Sorry. Since neither it, nor 100140 is, marked 'closed' I assumed I should do so. Further, the actions causing a crash on this report are quite different from those in 100140, and I saw nothing about being unable to save a form there, so I had no proof that 100140 actually fixed this problem as well as that in 100140. Does 'Closed' not mean anything extra?