Apache OpenOffice (AOO) Bugzilla – Issue 16700
Form autopilot creates invisible date/time fields
Last modified: 2006-05-31 14:29:06 UTC
Hi, This problem existed before OO1.1RC so it is not new to the RC. When creating a Form using the Autopilot based on a MS Access MDB file connected using ODBC date/time fields are not correctly layed out. They are correct until the Create button is pressed. Once the create button is pressed the date/time fields are redrawn out of alignment. I've included a screen shot and a very simple mdb file for testing. Hope it helps Kelvin
Created attachment 7571 [details] Screen image showing date/time field not aligned from autopilot
Created attachment 7572 [details] MS Access XP mdb file. Single table with two fields, one a date/time field
set target and send to the right developer. The same problem occurr in OOo 1.0
BC: Duplicate to #4868# *** This issue has been marked as a duplicate of 4868 ***
Hi, I think a mistake has been made here. This issue has nothing to do with issue 4868 so I am reopening the issue. In fact I just checked with OO1.1RC3 and the date/time fields no longer appear at all. This is very bad as the Form Pilot is now close to useless for handling date/time fields. I am changing this to a priority 2 as it means a feature which previously worked (albeit badly) now works worse. Kelvin
I can reproduce the invisibility of the fields in RC3. If you ungroup the shape, then the two missing fields appear (but are still improperly positioned). I'm adjusting the summary accordingly. fs->tz: Do you approve a 1.1.1 target for this?
BC: Sorry: This bug is duplicate to 14868 (and not 4868)but it definitely is! *** This issue has been marked as a duplicate of 14868 ***
for the records: the fact that both fields seem to not exist in RC3 is probably the problem covered in issue 18447.
correction: not completely the same as issue 18447. 18447 is about controls grouped with non-controls, which produces permanently invisible controls. This one is about a control (the label) which is grouped with another group of two other controls (the edit fields for date and time). This seems to persist until the document is reloaded.
Hi, Should I reopen this issue since it is not an exact duplicate of 14447. Also 14868 is what this issue was about until RC3 came out. Then the problem changed and this is not mentioned in 14868. IMHO it is better that all variations of a problem be logged and tested that they have been fixed, and then closed. Having this issue closed may result in the problem/variation being missed. Just wondering. Kelvin
Kelvin, you're absolutely right with your concerns about potentially missing variations of a problem. So normmally, I would agree that you re-open the issue, until the responsible developer explicitly says that it's a duplicate (which is an assumption only so far). In such a case, the person verifying an fix (the developer, and/or the QA engineer) has to also verify all duplicates. But in this special case, please refrain from doing so. Oliver (OD) already found the fix for bug 18447, and it also fixes the invisibility of the datetime fields in this bug. So this aspect is definately a duplicate of 18447, while the original bug is still a duplicate of bug 14868.
change subcomponent to 'none'
close issue.