Re: [dev] Lifetime of Java objects representing UNO_ENUM values ?
On 07/15/10 22:10, Rony G. Flatscher wrote: today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] That DisposedException had more than likely a different reason. Java objects representing UNO enumeration type values are completely "local" -- none of their methods initiate any URP communication. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Lifetime of Java objects representing UNO_ENUM values ?
Hi there, today I stumbled over the following interesting (read: time-consuming) problem: while caching Java objects representing individual UNO_ENUM values, all of a sudden om.sun.star.lang.DisposedException started to be thrown. Here is one such received exception message: ... getCause(): [com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bri...@105b99f is disposed] Caching the Java class object and querying it for the field values in the same use-case (and timing) conditions worked. Question: is caching of Java objects representing individual UNO_ENUM values really unsafe, i.e. the UNO side may garbage collect them? (This seems to happen even if the Java class object representing the UNO_ENUM gets cached!) ---rony
[dev] Default path setting ?
Hi everyone, I'm trying to set a default template with an extension. Here is the xcu configuration file : http://www.pastie.org/1045423 The configuration works on 2.4, 3.0.1, 3.1.1 but it didn't work on 3.2.X. Is there any change in the path settings on OOo 3.2.X, it seems %origin% didn't work anymore ? P.S = Is it more accurate if I post on api dev mailing list ? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] please help where file to fix this export filter bug
Am 15.07.2010 06:23, schrieb Tantai Thanakanok: I want to fix this bug http://qa.openoffice.org/issues/show_bug.cgi?id=93503 . (Calc export of Buddhist date to Excel is broken) Steps to reproduce: 1. Start OpenOffice.org Calc 2. Tool -> Option -> Language Setting -> Languages and set Locale setting to Thai 3. Type a date (ex. 15/05/2008) in a cell 4. Click the cell and choose Format -> Cells -> Numbers, then changes the following 3.1) Change Category to Date 3.2) Change Language to Thai 3.3) Change Fomat to 31 ธันวาคม 2542 5. Click OK 6. Save as Microsoft Excel 97/2000/XP (.xls) 7. Exit OpenOffice.org Calc 8. Open the xls file in Microsoft Excel Excel will show error dialog box "Some number formats may have been lost." 9. Observe the Date will be formatted as an integer number This bug caused by format code in xls file created by OpenOffice.org contain "[~buddhist]" and excel can't resolve "[~buddhist]" to "[-107041E]". I test by use hex editor open file with [~buddhist] format code and and change it to [-107041E]. after I fix it, xls file is display correctly. After testing I want to fix code but I can't find where to fix it. can anyone help me to find it. Hi, the export of number formats to Excel format is implemented in File: sc/source/filter/excel/xestyle.cxx Class: XclExpNumFmtBuffer special handling may be added to the function XclExpNumFmtBuffer::GetFormatCode() that already contains special handling for e.g. the "General" or for Boolean format codes. Regards Daniel - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Fwd: Is there a dictionary in the format of text file?
Hi *, On Wed, Jul 14, 2010 at 11:06 AM, Caolán McNamara wrote: > On Wed, 2010-07-14 at 10:00 -0500, Peng Yu wrote: > > In theory, those there are bugs in it unfortunately, hunspell's > "unmunch" is supposed to do this, i.e. unzip the dict-en.oxt (or > whatever is its exact name) and use unmunch en.dic en.aff and it should > stick the -ing, and -s etc onto all the stem words and expand the > dictionary+aff files back into a text file containing all variants. Not related to bugs, but to the compound word feature in hunspell (and if the dictionary makes use of it), the flat list can easily grow many gigabytes, and of course not all of the compounds will make sense. I.e. you don't only get a list of valid words, but you also get a list of nonsense-words that nobody is going to write anyway. The dictionaries are there to check for mistakes, not check for correctness :-) ciao Christian - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
