Bug 88274 - Wizard generated form fails in several ways; TAB focus in List box when List box is first control in sub form
Summary: Wizard generated form fails in several ways; TAB focus in List box when List ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Wizard
  Show dependency treegraph
 
Reported: 2015-01-10 16:51 UTC by Bill Gradwohl
Modified: 2022-12-26 07:44 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
File to demonstrate Form bugs in Base. (20.95 KB, application/vnd.oasis.opendocument.base)
2015-01-10 16:51 UTC, Bill Gradwohl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Gradwohl 2015-01-10 16:51:02 UTC
Created attachment 112066 [details]
File to demonstrate Form bugs in Base.

On a freshly installed and updated Fedora 21, I installed 4.3.5.2. from the LibreOffice site.

I set up a test database and created a form to populate it using the Wizard, and then modified that to my needs.

The form is supposed to tab through to each field in turn (Main form and sub form) left to right, top to bottom but that doesn't happen. Also, after the first iteration through the form, the subform becomes grayed out and unusable.

The database is attached and the two tables it uses are empty. I believe them being empty may have a bearing on the anomalies to be described.

Execute the form and enter anything reasonable per field and you'll notice that the first field (Product) in the subform isn't on the tab path even though it is first in the list for the subform. Tab bypasses that field and lands on the second field (Weight) in the tab order list. Continuing to tab and entering data (and never touching Product) leads to 2 failure messages instead of only one. Finally entering a Product allows the subform to be saved, and a refreshed screen appears.

After entering one screens worth of transaction, the next screen has the sub form grayed out and there's no way to enter any data into it. 

Exit out of the form and re execute the form.

Again enter a transaction. Here' I've had two outcomes. Sometimes It's a repeat of what is described above, and sometimes I can enter a subform transaction. YMMV.

After having submitted several bug reports lately, I know I'm wasting my time entering this one. But I've done my duty and now I'm moving on by abandoning LibreOffice Base in favor of hand crafted HTML 5 using JavaScript and node.js .

For the average person using Writer, Calc, etc, the product is a good replacement for MS Office. Once one wants to write code using the API Set, the product falls apart due mostly to lousy documentation. Absolutely dreadful. BTW - The people writing the code are the ones that should be writing the documentation, as they're the only ones authoritative on the matter.
Example: The entire documentation I was able to find for the "Before Submitting" event was via a Google search 'libreoffice "before submitting event"' that returned 3 references. I've never gotten only 3 references on a Google search ever before. The one at LibreOffice https://help.libreoffice.org/Common/Events_1 was absolutely useless. Read it for yourself.

The documentation for the entire LibreOffice API suite is the worst I've ever encountered, and I'm a professional software developer. If it weren't for Andrew Pitonyak's book, I would never have been able to do anything with the product line in Calc. Thank You Andrew. You're a talented author and should use your skills on something better than LibreOffice.

The developers haven't seen fit to produce an Xray equivalent. They crippled one of Xray's features when they reworked the API docs. Genius! Take something that was trying to help and kill it.

The floppy disk icon representing that data has changed and needs to be saved when working in LibreOffice Basic has been broken for years. Sometimes it turns blue, but most of the time it stays grayed out even though source code changes have been made. Broken for years. Such a little thing. Broken for years. That alone says were the state of bug annihilation rests for the product line.

Adios.
Comment 1 Joel Madero 2015-01-10 17:26:41 UTC
Please provide clear steps that aren't written in a long paragraph. 

See: https://wiki.documentfoundation.org/QA/BugReport#Paragraphs_of_Text &
https://wiki.documentfoundation.org/QA/BugReport#Adding_Superfluous_Information


We're having to deal with hundreds of bug reports and reading paragraphs of text like you have provided slows us down tremendously. Also please exclude superfluous language (e.g., " Once one wants to write code using the API Set, the product falls apart due mostly to lousy documentation. Absolutely dreadful. BTW - The people writing the code are the ones that should be writing the documentation, as they're the only ones authoritative on the matter."). 

If you want to get involved with documentation to help improve it (as this is a volunteer project, that requires volunteers to do the work) please email the documentation team at http://www.libreoffice.org/get-help/mailing-lists/
Comment 2 raal 2015-01-11 20:42:22 UTC
(In reply to Bill Gradwohl from comment #0)
> Created attachment 112066 [details]
> File to demonstrate Form bugs in Base.
> 

> 
> Execute the form and enter anything reasonable per field and you'll notice
> that the first field (Product) in the subform isn't on the tab path even
> though it is first in the list for the subform. Tab bypasses that field and
> lands on the second field (Weight) in the tab order list. Continuing to tab
> and entering data (and never touching Product) leads to 2 failure messages
> instead of only one. Finally entering a Product allows the subform to be
> saved, and a refreshed screen appears.
> 

I can confirm with Version: 4.5.0.0.alpha0+
Build ID: a272f5b7b30f356418ecf28eb95d066f081d1624
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-01-09_09:50:59

Steps to reproduce:
 -open form "testDataEntry"
 - click to field Date; enter date; TAB key; choose Vendor; TAB key; enter invoice; TAB key

Actual behaviour
 Focus is in the field Weight

Expected behaviour
 Focus is in the field Product 

When I change tab order (https://help.libreoffice.org/Common/Tab_Order) and field Product (List Box) is second in tab order, then TAB key works as expected -> changing Summary.

Other bug (sub form grayed out and there's no way to enter any data into it. ) I cannot reproduce.
Comment 3 Robert Großkopf 2015-01-13 21:32:29 UTC
The listbox in the subform isn't activated before there is a row created in the mainform. Seems it works only while a form is used for modifications, not for input new rows.

I have tested the first available LO-version. Doesn't work in LO 3.3.0beta1. So I will set the version to "Inherited FROM OOo".
My test-system. OpenSUSE 12.3 64bit rpm Linux with different LO-versions.
Comment 4 QA Administrators 2016-01-17 20:03:41 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2017-03-06 14:13:42 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2019-12-03 14:29:34 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2021-12-03 04:34:00 UTC
Dear Bill Gradwohl,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug