can you attach such a broken document for evaluation?

sorry, but a target milestone of "next build" is not appropriate for a
bug which has not even been confirmed - resetting.

could not reproduce this with any of my tables in 1.0.3 - Andre, is
there something special about the tables you use, or something like
this? Can you describe the structure of a table which you use for this?

Created attachment 6227 [details]
simple form with invisible fields for PostgreSQL db

Created attachment 6228 [details]
simple PostgreSQL schema  for db used in the test

Hello,
As you can see at the attached files, everything is simple.
nothing exoteric.
I would like to not loose this opportunity to introduce OO, Pg, and
Linux at the department of my new job.
A few minutes ago, a coleague told that a previous one tried 2 years
without success.
Now that the project I presented get the "OK" to start, I must
accomplish it in the narrow timeframe to get OO, Pg and Linux here.
Well, linux at least at the backend of the department.
The corporate lan is well another story...
Regards.
Andre Felipe

Hello,
I consistently reproduced the exact steps when the problem appears and
when it does not appear.

steps to create forms with invisible fields for PostgreSQL backend:
1) boot w98.
2) call OpenOffice with a blank page.
3) call autopilot > forms
4) create a simple form for the Pg db with more than 2 fields and with
a layout other than standart spreadsheet and standard background.
5) save and exit.

***** At this very moment, the PostgreSQL window shows a message:
NOTICE: Adding missing FROM-clause entry for table "pg_namespace" 


6) open the saved form.

***** At this very moment, the PostgreSQL window shows a NEW message:
NOTICE: Adding missing FROM-clause entry for table "pg_namespace" 

Now, from the second field onwards, all others are invisible.
they are still there, as showed by form navigator and by clicking at
the area.



Steps for NOT having invisible fields on forms for PostgreSQL backend:
1) boot w98
2) open a previouly created form for the same database. It will ask
for password and then connect.
3) call autopilot > forms
4) create a simple form for the Pg db with more than 2 fields and with
a layout other than standart spreadsheet and standard background.
5) save and exit.

***** At this very moment, the PostgreSQL window DOES NOT show any
message.


6) open the saved form.

***** At this very moment, the PostgreSQL window STILL DOES NOT show
any new message.

Now, all fields are visible.


Maybe this behaviour is only at w98.

I hope this help.
Regards.
Andre Felipe

fs->msc: still failing to reproduce this with the postgress
installation on clu-3111. Admittedly, I do not have Win98, but somehow
I doubt that it's a platform problem.
Do you have a chance to look at this?

Hi,

I can't reproduce this, for me all fields are still there, no problems.
The only thing I can reproduce is the notice message in the Postgres
window.

Bye Marc

Works os is fixed in OOo 1.1 Beta2.

closed ...

 Hello, Sir 
Yesterday, I executed more tests regarding this issue. 
I saw that the system load and memory used have direct connection to 
this. 
The more system load, more memory use, more swap, lead to the 
problem repetition. 
So, I deduced that there is some kind of time-out (hard coded?) 
affecting OO odbc communications with postgresql. 
This also could explain why you, using powerfull machines and better 
OS could not reproduce the problem. 
Regards. 
Andre Felipe 
 

somehow I don't believe that it's simply about performance - there
must be another difference -, but can you try to check this, Marc?
Andre, which version of OOo are you using (I suppose a spanish one?),
and where did you get it from?

Hello, 
Thanks for your attention. 
I am running the official brazilian portuguese 1.0.3 beta 4 translation (linked 
from openffice.org to openoffice.org.br) at w98 at an old Pentium 200 mmx. 
I can reproduce the problem, following the previously sent descriptions, all 
times. 
I really suspect there is something around performance issues and timings 
when used in low end machines and low end OS. 
Today I configured for dual boot with linux and will try to reproduce the 
problem in linux. 
Regards. 
Andre Felipe 
 

Hello, 
I tested OO 1.0.0 portuguese (portugal)  for linux and it WORKED. 
I was unable to test 1.0.1 portuguese, 1.0.1 brazilian portuguese, 1.0.2 and 1.0.3 
brazilian portuguese  for linux because of another error that crashes OO all times when 
form autopilot is called. 
Alread opened an issue for these. 
Best regards. 
Andre Felipe Machado 

Hello, 
I tested OpenOffice 1.1RC1 for linux and it has the same weird behaviour of 
opening saved forms with , now, invisible fields. 
Forms navigator shows that fields are part of document. 
By clicking over "invisible" fields area, one is able to select them! 
I hope this help to find the cause. 
Regards. 
Andre Felipe 
 

Hello, 
I contacted the unixodbc.org team about this bug. 
Please, see the answer: 
.... 
> Ok, but the thing is the windows PG driver is not the one I distribute 
> its done by the Postgres folks, so if there is a common problem its more 
> likely to be in OpenOffice. 
... 
 
The problem can be recreated with any table you create, with more than 13 fields 
when using OO 1.1RC1 for linux english, and unixodobc 2.2.6. 
When using OO 1.0.x and unixodbc 2.2.4, the problem pops up even with 2 fields. 
Please, try yourself. 
 
Regards. 
Andre Felipe 
 

I can reproduce this. When I click on the create button several times, then I
get a second save as dialog and when I save the form again I have broken fields.

set target and set to new.

*** Issue 22375 has been marked as a duplicate of this issue. ***

change subcomponent to 'none'

Change the status to 'new' as MSC wanted.

Because of limited resource for OOo2.0, it was decided to shift this tasks to
the next milestone. If somebody will be found, who can implement this until
OOo2.0, then this tasks will be re-targeted.

Hi,

msc -> bc: 

Thsi still happend also with the new form wizard.

to reproduce:

- open biblio.odb
- start form wizard
- select all fields
- click next
- click next
- select the first layout
- click next until last page
- click twice on the finish button

==>> the form has no fields

BC: This should be a general problem of all Java-implemented wizards. Double
clicking the finish button is not handled properly.

bc: I think this should be fixed within a OOo2.x target, especially as all java
wizards are affected.

Hello,
I have the same or an similar behaviour - but I'm not shure if it's exactly the
same problem.

When I create more complex forms after a while (closing, reopening, editing)
some of the fields are not visible anymore in the form-editing-mode. When I
close the edit-function for using the form everything is all right. So using is
no problem, editing is. If I cut an unvisible field (to mark it is possible) and
paste it again it's visible again - but soon the next field disappear. 

I can reproduce this with 2.0.2 and 2.0.3, mysql 5.0, unixodbc 2.2.11, but it
doens't seem to depends on an specific database connection due to the fact that
the phenomenon also occurs when the form is disconnected from the database.

When I delete the configurations of openoffice in ~/.openoffice.org2 and
reinstall openoffice it appears for a short time a little bit better.

Is this the same Bug? Did anybody find a workaraound?

bc: changing target to OOo 3.0

resetting target to OOo.3.x

fixed.
Finish Button can't press twice.

targeting to 3.2, since the fix is part of a CWS aiming for this release

please verify

reopen, now I get many java null pointer exceptions inside the terminal window
where I start the office, when creating a new form.

reassign back to lla. Please have a look on the exceptions

Fixed

verified in CWS dba32a

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba32a