Apache OpenOffice (AOO) Bugzilla – Issue 78522
forms: checkboxes and listboxes are disabled when EscapeProcessing = false
Last modified: 2017-05-20 10:44:55 UTC
To reproduce: Create a form with jdbc-connection, which is basing on a stored query. The form should contain listboxes and checkboxes. Change the query, so that EscapeProcessing = false (native sql). Reopen the form: all listboxes and checkboxes are disabled. The same occurs if you edit a listbox and modify the wizard-generated sql (e.g. add a ORDER BY).
do you mind attaching a bug doc (If this is about JDBC, then an embedded HSQDB should do, so you could create a self-contained file)?
Here is an simple example; yes, with HSQL it's reproducable too. Open the form, some controls are disabled. Open the query and turn native sql off, then you can work with the form.
Created attachment 46029 [details] odb to reproduce disabled controls
The reason for this is: When the escape processing is disabled ( setting "Run SQL Direct" in the SQL view window ) the result set is Read Only. When this query is used as the data source for a form then all controls on the form are automatically set to read only also. In the case of the combo, list and check boxes this also grays out the text. You can verify that nothing is 'broken' by simply scrolling the result set with the data navigator. The values in the controls will update as the record pointer is changed.
You mean ResultSetConcurrency? Yes it's READ_ONLY. But would like to know the reason for that...
because OOo cannot update statements which it cannot parse. However, I'm a little bit confused that we disable the controls then, we normally simply set them to read-only. However, for list boxes I know that when they're set to read-only, they're rendered as if they were disabled (this is another issue in our windowing layer, fixed for 2.3, hopefully). For check boxes, I'm not aware of such a behavior, but it might in fact be there.
clu->fs: bug or feature enhancement?
Well, depends on the point of view ... :) The problem here is that the forms runtime tries to put a lock onto the fields which cannot be edited. For text input fields of all kinds, this is possible by setting them to read-only. For all others, it's simply not possible by UNO API, so the (ancient) code decides to set the control to "disabled". While this is not really a big problem in itself (IMO), I think we can do better than this. fs->fs: need to - introduce a UNO API which allows to set a control to read-only - properly implement read-only-ness for VCL's list boxes, which currently *also* decide to switch to "disabled" when they're read-only (Don't we have an issue for this already?) - implement read-only support for VCL's CheckBox class, which currently doesn't have this.
Reset the assignee to the default "issues@openoffice.apache.org".