[dev] File-locking problem with no delete rights
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mikhail, all, One users reported that there is a problem with the newly introduced file locking mechanism. Currently I do not have to much information about the problem (eg. sw environment) but I asked for more detailed information. So the user have no rights to delete file (just create and modify) so deleting file-locking file is not possible. Then the second user can only open to read the document even the first user has closed the document. Do you have idea how to solve this problem whitin OOo? Best regards, KAMI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm2FaAACgkQRR9zu0ZB/GlC4ACgjSco2hL37OQbt5f8/NIb8Rwg qU8An0vIy8fHp6jAhtOKTl5UddRMGoNL =3Qug -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Frank Schönheit - Sun Microsystems Germany wrote: Hi Mathias, When we talk about seldom, hard to reproduce errors, then let's introduce a logger which is permanently switched ON, or at least switched ON for log levels = LogLevel.SEVERE. (by default, loggers are OFF, i.e. do not log any event, regardless of the LogLevel.) Everything that must be switched on doesn't help read again, please: ¨permanently switched on¨ was what I wrote :) OK, that would be an option that could work. Logging errors until an error handler starts and perhaps creates an error report. But it works with exceptions and IMHO is the more natural approach. I agree with you that it's unfortunate not to have a user compatible way of handling and reporting errors. But we shouldn't clutch at straws and (mis)use something that comes close to that, we should find out what is the right way. User oriented error reporting in many (most?) cases can't be done by taking a message from the point where the exception occured, quite often it needs a context and perhaps even more. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Frank Schönheit - Sun Microsystems Germany wrote: Without having the bigger picture how good error handling should look like while we are at it, and mentioned UNO incompatibility already ... I just came across (yet) another issue where a severe error was silenced instead of propagated to the caller (and thus caused document corruption), simply because the respective UNO method (XFilter::filter) was poorly designed, and did not allow to throw any but a RuntimeException. However a reasonable error handling would look like, IMO carefully re-designing UNO to add more exceptions specifications to (a lot of) methods is a must-have. +1 Just to play the devil's advocate: without careful considerations that would end in adding throws css.uno.Exception to any method, though perhaps it's the right approach for all generic APIs (generic APIs need generic exceptions - don't they?). While this would be an improvement wrt. being able to fix design flaws, I doubt that this is what we want in every case. It just would create a lot of silently caught exceptions. OTOH designing exceptions right is very hard and often needs a lot of thinking. So I don't expect that we can fix that in a big bang release, we will need quite some time to fix that. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Simplify Reference Casts by template constructors
Hi everyone,
After a period of time of developing with URE, I find the C++ UNO
class Reference is not very comfortable for use sometime.
The problem is, when I have a reference of base interface XA and a
reference of derived interface XB, I can't make xA = xB directly.
Instead I have to query XA from xB like this xA = ReferenceXA::query(xB).
I wonder that whether we can use template constructors to simply this
situation.These constructors may something like this:
template typename interface_type
class Reference
{
template _interface_type
Reference(const Reference_interface_type rRef)
{
interface_type* p = NULL;
_interface_type* _p = NULL;
p = _p; // compiling time cast check.
_pInterface = iquery( rRef.get() );
}
// copy constructor
Reference(const Reference_T another)
{
...
}
}
Now we can simplify the cast code above to
xA = xB;
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
