Hi Stephan,
So it is affected as well (does not work
anymore).
In the meantime I have de-installed all OpenOffices (1.1.4, 1.9),
deleted all remainders of these installations in the file-system, tried
to find traces in the Windows registry and deleted them.
Then - after reboots - I re-installed OOo 1.9 only, but to no avail.
Are there any registry-entries which might affect this behaviour that
have keys other than "OpenOffice" or "soffice" ? Or could it be, that
some cache is being used that contains erroneous data?
There should be no registry entries that have any influence on this.
Did you re-use any old user installation (its location is determined by
line "UserInstallation=" in program\bootstrap.ini? Normally, soffice
finds services like "com.sun.star.beans.Introspection" in
program\services.rdb, which it locates via the line "UNO_SERVICES=" in
program\uno.ini ("$ORIGIN" should expand to the soffice program
directory); but if something is broken there, soffice itself would most
likely not start up at all.
Hmm, will look at that as well.
Here the "latest" news:
- did de-install OOo 1.1.4 and OOo 1.9.113 and rebooted
- re-installed 1.1.4, doesn't work
- de-installed 1.1.4, rebooted, ran two different registry
cleaners
- re-installed 1.1.4, worked a few times, then stopped working;
- de-installed, ran registry-cleaners
- re-installed .1.9.113
- worked; after a few tests decided to become a little bit
happy and haven't touched it since yesterday...
;)
>From your answer I infer that you have not encountered this behaviours
so far. Could it be that (again being an OOo rookie) using Java
reflection to use the OOo reflection has to do with it, maybe that I am
instantiating classes in the wrong order? Or (*pure* speculation) that
the Java runtime itself is caching data causing the recurrence of that
very bug, once it appeared?
Any idea, speculation that might help solve this situation would be
highly appreciated.
Regards,
---rony
|
