Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||forms: checkboxes and listboxes are disabled when EscapeProcessing = false|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||UNCONFIRMED ---||QA Contact:|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description eberlein 2007-06-15 12:15:57 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).
Comment 1 Frank Schönheit 2007-06-18 11:26:09 UTC
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)?
Comment 2 eberlein 2007-06-18 12:45:12 UTC
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.
Comment 3 eberlein 2007-06-18 12:46:46 UTC
Created attachment 46029 [details] odb to reproduce disabled controls
Comment 4 drewjensen.inbox 2007-06-19 16:50:50 UTC
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.
Comment 5 eberlein 2007-06-20 08:55:54 UTC
You mean ResultSetConcurrency? Yes it's READ_ONLY. But would like to know the reason for that...
Comment 6 Frank Schönheit 2007-06-20 09:58:14 UTC
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.
Comment 7 christoph.lukasiak 2008-06-17 17:07:56 UTC
clu->fs: bug or feature enhancement?
Comment 8 Frank Schönheit 2008-06-17 20:56:37 UTC
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.