QGIS » QGIS Application

To reach a wider audience you should post your question also on the developers mailing list.

Alessandro Pasotti wrote:

Raul Sangonzalo wrote:

This resets any variables we are using to the values set in formOpen.

I don't understand: if the form was originally opened in readOnly mode (because the layer was not editable) what variable values are you loosing?

I believe that the current implementation is correct: the form is basically re-opened because all widgets need to be updated and there are some widgets that have a complete different representation when in edit mode.

We set indicator variables in other functions throughout the script, which we use for validation, feature locking, spatial intersection information etc. This is what we lose when we toggleEditing. These variables are usually initially set within the formOpen, and then changed later. So a reset of the form resets these variables. We have found the ability to manage input in the front end (QGIS) to be very valuable. The forms are often left open, with multiple edits and saves occurring before the user closes it.

You are correct that some widgets have a different appearance in edit mode, we have created some of that functionality for our own custom items, by capturing the editingStarted and editingStopped signals (which is a way all widgets could know when to change state). The entire form should not be re-opened until the user chooses to close and re-open it. This is how it has been in previous versions, our forms worked very well, and were stable. This change to the toggleEditing action re-setting the entire form is a very big and unfortunate step backwards for our internal GUI development, as it wipes out many of our control mechanisms at the touch of a single button.

Hopefully this makes sense. Again, any help would be greatly appreciated.

I'm afraid this is a won't fix, the changes that introduced this issue [*] were necessary in order to fix other serious issues in the "normal" workflow (for "normal" I mean no custom code or custom forms, just plain QGIS standard forms).

If you've built complex logic inside the formOpen functions you might consider to change your logic into a plugin with custom forms and/or persist the state of the forms in some other way or instruct your users to not quit the edit state without saving (you can decide to load the custom values only when the layer is editable after all).

I'll have a second look to the code that triggered the change, but I cannot promise anything.

[*] wether this is an issue or not is debatable: I don't think that it was documented anywhere and it's something that relies on custom code and no public API.

Alessandro Pasotti wrote:

I'm afraid this is a won't fix, the changes that introduced this issue [*] were necessary in order to fix other serious issues in the "normal" workflow (for "normal" I mean no custom code or custom forms, just plain QGIS standard forms).

If you've built complex logic inside the formOpen functions you might consider to change your logic into a plugin with custom forms and/or persist the state of the forms in some other way or instruct your users to not quit the edit state without saving (you can decide to load the custom values only when the layer is editable after all).

I'll have a second look to the code that triggered the change, but I cannot promise anything.

[*] wether this is an issue or not is debatable: I don't think that it was documented anywhere and it's something that relies on custom code and no public API.

While I can't pretend to understand what these other serious issues are/were, I am glad that QGIS3 does seem more stable than QGIS2, and very much want to migrate our system to it.
I would very much appreciate you taking a second look at the code, thank you. And I also appreciate your snippets of advice. It would be a shame if we have to change everything, but we are always up for a challenge!