Re: [dev] Instance of soffice.bin remains running after closing OOo
Hi Jan, hm, that sounds strange, I see no difference between a new document and a loaded one in this context. It is hard for me to say what goes wrong here without debugging. Would it be possible for you to provide a small testcase that allows to reproduce the problem? Thanks, Mikhail. On 12/07/10 17:09, Jan private wrote: Hello Mikhail, please try to send .uno::CloseWin dispatch request to the frame of the background.odt document to close the document as an experiment. I think you mean .uno:CloseWin dispatch request. I inserted this code: ReferenceXDispatchHelper xDispatchHelper(mxMCF-createInstanceWithContext(OU(com.sun.star.frame.DispatchHelper), mxCC), UNO_QUERY_THROW); // xMaster has the XModel of background.odt ReferenceXDispatchProvider xDispatchProvider(xMaster-getCurrentController()-getFrame(), UNO_QUERY_THROW); xDispatchHelper-executeDispatch(xDispatchProvider, OU(.uno:CloseWin), OU(), 0, SequencePropertyValue()); The code is executed and I also checked that both References actually exist. This works if I load a new document instead of myDocument.odt (Untitled.odt). After closing Untitled.odt I get the generic Openoffice interface (which lets you choose to open a new Text Document, Spreadsheet, etc.) . After closing that, there is no soffice.bin process left over. But if I load myDocument.odt there is no change from my previous post (no documents visible but process remains running). Same thing happens if I use .uno:CloseDoc Using both CloseWin and CloseDoc crashes after closing background.odt Any more ideas? Thanks, Jan
Re: [dev] Instance of soffice.bin remains running after closing OOo
Hi Jan,
please try to send .uno::CloseWin dispatch request to the frame of the
background.odt document to close the document as an experiment.
This request is triggered when you click with the mouse to close the
document window. It checks whether there are other frames that prevent
termination and terminate the office if necessary. The problem is that
your extension seems to close background.odt too late, when the UI
part has already done its work. In this case the code that closes the
last document is responsible to terminate the office. So the easiest way
would be to just use the dispatch request to close the remaining
background.odt as well.
Thus, if I understood the scenario correctly, the dispatch request
should let the office be terminated in this scenario.
Hope that helps.
Best regards,
Mikhail.
On 12/03/10 19:15, Jan Rheinländer wrote:
Hello Mikhail,
sorry for the delay. I was away without internet access for a while.
I am not quite sure what do you mean with destructor of the extension.
The extension is defined as a class
class iMath : public cppu::WeakImplHelper6
XDispatchProvider,
XDispatch,
XInitialization,
XServiceInfo,
XDialogEventHandler,
XContainerWindowEventHandler
{ ... }
and I am using the constructor to initialize the extension and the
destructor to clean up (e.g. close background.odt)
Are you sure that the code that should close the document is called?
Yes
And if it is called, do you get any exception from the close() call?
no, I put it in a try { ... } catch (Exception e) { ... } block but
nothing comes up.
Some more detail:
1. I open a document e.g. by calling openoffice.org -writer
myDocument.odt
2. The extension automatically loads background.odt (code see initial
posting)
3. I close myDocument.odt (manually by clicking with the mouse)
4. The destructor of the extension is called automatically, and the
close() executed for background.odt
Back at the command line, ps -eaf lists a running
/usr/lib/openoffice/program/soffice.bin -writer myDocument.odt .
-splash-pipe=5
which needs to be killed manually to terminate.
I tried some other stuff: If I load background.odt in the foreground,
then close it manually by clicking with the mouse, then close
myDocument.odt, the problem disappears.
If I insert the code to close background.odt somewhere else (e.g.
activated by a menu item in the extension), the problem disappears
Maybe the iMath destructor is the wrong place to close background.odt?
If yes, what is the right place? And what about the constructor?
Thanks for any ideas
Jan
Re: [dev] com.sun.star.packages.zip.ZipIOException
Hi Michele, another possibility is that the file is OK, but you use the package format instead of zip-format. The package format requires META-INF/manifest.xml to be in the package, it is a part of the package format. To create ZipPackage that supports zip-format, please try to provide the following argument during initialization aNamedValue.Name = PackageFormat aNamedValue.Value = false That should let the package handle the file as a plain zip format file. Hope that helps. Best regards, Mikhail. On 12/09/09 12:23, Michele Zarri wrote: 2009/12/9 Mikhail Voytenko mikhail.voyte...@sun.com: Hi Michele, [snip] It could be that the repairing mechanics should be improved. But you have mentioned gunzip, is the archive in gzip format? In this case the office can not handle it at all, since only zip-format is supported. The file is a .zip but gunzip can handle them with the -S switch. I used it also to test the archive and I got OK, this is why I wrote about my surprise on how strict the check OOo makes is. OTOH I am probably misusing the package service which is intended for odf documents so I will stop using it even if it was rather convenient. As I wrote the files I am working with are publicly available you can download some samples here: http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_46/Docs/ Thanks again for the clarifications, Cheers, Michele - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] com.sun.star.packages.zip.ZipIOException
Hi Michele, On 12/08/09 04:01, Michele Zarri wrote: Thanks for the quick reply Mikhail, I did what you suggested and it now works in most of the cases: thanks! I now have a different problem since in many cases when I create the zipPackageFolder with the method getByHierarchicalName() I discover that this is empty even if gunzip, file-roller, Karc, winzip 7zip tell me that there is at least a file in the archive. It could be that the repairing mechanics should be improved. But you have mentioned gunzip, is the archive in gzip format? In this case the office can not handle it at all, since only zip-format is supported. No big deal since all I had to do was to add a test for empty archives which should have been there in the first place, but I still wonder why OOo has to be s strict :-) OOo is working with user documents and so it should strictly check that the document is consistent. Any inconsistency could mean data-loss or manipulation. Thus the office has to detect and report such cases. Best regards, Mikhail. The zip files I am working on are publicly available in case you want to take a look at a couple of them. Cheers, Michele Mikhail Voytenko wrote: Hi Michele, The implementation of the package checks the zip format more strictly starting from OOo3.2, this is why some files that could be handled in OOo3.1.1 can not be handled any more directly. But it is correct so, because the file is indeed broken, if the package throws the exception. I must confess, I do not quite understand what kind of documentation would you expect. Improvement of the broken zip file check is a bug-fix and is definitely no new feature. In case you would like to repair the file please try to insert object of type NamedValue into the arguments ( args(1) ), with the values aNamedValue.Name = RepairPackage aNamedValue.Value = true That will let the package ignore the errors in the broken zip file and try to repair it. Hope that helps. Best regards, Mikhail. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] com.sun.star.packages.zip.ZipIOException
Hi Michele, The implementation of the package checks the zip format more strictly starting from OOo3.2, this is why some files that could be handled in OOo3.1.1 can not be handled any more directly. But it is correct so, because the file is indeed broken, if the package throws the exception. I must confess, I do not quite understand what kind of documentation would you expect. Improvement of the broken zip file check is a bug-fix and is definitely no new feature. In case you would like to repair the file please try to insert object of type NamedValue into the arguments ( args(1) ), with the values aNamedValue.Name = RepairPackage aNamedValue.Value = true That will let the package ignore the errors in the broken zip file and try to repair it. Hope that helps. Best regards, Mikhail. On 12/07/09 05:37, Michele Zarri wrote: Hello, I have downloaded the snapshot OOo-Dev_m7 and I get an error when I run a macro that inspects a zip file using the com.sun.star.packages.zip service. The same macro trying to work on the same file works fine on OOo3.1.1 This is the StarBasic code I use and it dies on oZipService.initialize(args()): Function fnGetArchivedFileFullName( sArchiveWithFullPath As String ) As String Dim args(0) As Variant Dim oZipService As Object Dim oTestArchive As Object oZipService = createUnoService(com.sun.star.packages.Package) args(0) = ConvertToURL( sArchiveWithFullPath ) oZipService.initialize(args()) [etc...] End Function The error message is as follows: BASIC runtime error. An exception occurred Type: com.sun.star.packages.zip.ZipIOException Message: /so/ws/OOO320/ooo/package/source/zippackage/ZipPackage.cxx: :766; Bad Zip File.. So my two questions: 1. has something changed in the zip package between OOo3.1.1 and OOo3.2? if so is there any documentation of such change? 2. if the answer to the first question is no, I will file a new issue. would it be possible for someone to confirm it? Thanks in advance for your help. Cheers, Michele - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OLE can not be activated in Windows OS after Java integration
Hi He Feng Su, Please try to use com.sun.star.awt.AsyncCallback service to get a callback from the office main thread. You will need an own object implementing com::sun::star::awt::XCallback interface. This object will be provided to the com::sun::star::awt::XRequestCallback::addCallback() call. Just to explain the mechanics for better understanding. When java application calls an UNO API method through a bridge, a new thread is created on Office side and the method is executed in this thread. When the XRequestCallback.addCallback() is called it sends a notification with arguments to the main office thread and returns. After a while the main thread calls XCallback::notify(), and if this method does a call to the office back, the call is handled in the office main thread. Hope that helps. Best regards, Mikhail. On 08/19/09 02:43 PM, He Feng Su wrote: Thanks Mikhail! The error is 0x8001010E The application called an interface that was marshalled for a different thread . It's true that the OLE creation and activation happen in different thread. I make use of LoadComponentFromURL UNO interface to load the MS office document and it happen in OOo non-main thread. And activation happens in OOo main thread. How can I make sure the loading happen in OOo main thread by UNO API calling on java side? Best regards, Humphry Su (He Feng) Symphony Common App and Performance, IBM China Software Development LAB, Beijing Tel: 86-10-82452452 Fax: 86-10-62982924 NOTES:He Feng Su/China/IBM E-mail: suhef...@cn.ibm.com Inactive hide details for Mikhail Voytenko ---08/19/2009 03:04:48 PM---Hi,Mikhail Voytenko ---08/19/2009 03:04:48 PM---Hi, From: Mikhail Voytenko mikhail.voyte...@sun.com To: dev@openoffice.org Date: 08/19/2009 03:04 PM Subject: Re: [dev] OLE can not be activated in Windows OS after Java integration Hi, If the object can be activated when the document is loaded in the normal office, that would mean for me that a threading problem takes place. COM does not support multi-threading ( as well as actually OOo ), so the object should be activated from the same thread where it was created. So I suspect that either the object is created in OOo non-main thread or activated in OOo non-main thread, or both is done in two different OOo non-main threads. Which exactly error do you get from DoVerb() call? Best regards, Mikhail. On 08/19/09 03:55 AM, He Feng Su wrote: Hello all, After I integrated OO3 into Java window, everything is OK. But I find that the OLE object in MS Office file can not be activated in windows OS. Per my debugging, the Windows APIs calling failed as below in lib\embeddedobj\source\msole\olecomponent.cxx. hr = m_pNativeImpl-m_pOleObject-DoVerb( nVerbID, NULL, m_pOleWrapClientSite, 0, NULL, NULL ); If you had any idea on that, please help. Thank you very much! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OLE can not be activated in Windows OS after Java integration
Hi, If the object can be activated when the document is loaded in the normal office, that would mean for me that a threading problem takes place. COM does not support multi-threading ( as well as actually OOo ), so the object should be activated from the same thread where it was created. So I suspect that either the object is created in OOo non-main thread or activated in OOo non-main thread, or both is done in two different OOo non-main threads. Which exactly error do you get from DoVerb() call? Best regards, Mikhail. On 08/19/09 03:55 AM, He Feng Su wrote: Hello all, After I integrated OO3 into Java window, everything is OK. But I find that the OLE object in MS Office file can not be activated in windows OS. Per my debugging, the Windows APIs calling failed as below in lib\embeddedobj\source\msole\olecomponent.cxx. hr = m_pNativeImpl-m_pOleObject-DoVerb( nVerbID, NULL, m_pOleWrapClientSite, 0, NULL, NULL ); If you had any idea on that, please help. Thank you very much! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] New Option 'Save with same password'
Hi, On 06/29/09 11:59, Malte Timmermann wrote: Well, first - OOo already remembers the document specific password in memory while the document is open. There is no API for getting the password, so someone would need to have access to the raw memory to find it somewhere - not very likely. The password is not stored persistently somewhere. But I agree that there is a possibility to retrieve the password, and I guess this could be fixed quite easily with encryption via some session key. If you like, let's discuss this in the security project, http://security.openoffice.org/ I am not sure that encryption of the password would really help. The problem is the following, to encrypt it with the session key, we have to have the key in the memory ( or at least the way it is generated should be good known ). As result the password in the memory is just replaces with more keys in the memory, that have to be retrieved to decrypt the document. Although it would need more actions, I do not think that somebody who got access to the memory and was able to read the password would not be able to read more keys. Please correct me if I have misunderstood something. Best regards, Mikhail. PS: I have redirected the discussion to disc...@security.openoffice.org second - you normally don't send raw data to some company. OOo doesn't use raw data for crash reports, and Windows FWIK also doesn't send such data. Would be some 100MB of data you would need to send out via the normally quite small upload bandwidth you have. In the end - would be fixed with the encryption suggested above. third - to come back to Alexanders question: I wouldn't introduce such seldom used feature to OOo, which makes things unnecessarily complicated (more code and more GUI). Right now, you don't have to provide the password when you loaded a password protected document, and simply use Save instead of Save-As. For versioning you might want to use the built-in versioning, see File/Versions... OOo won't ask you for the password when creating a new version. Malte. tora - Takamichi Akiyama wrote, On 06/26/09 16:23: Hi, Alexander Ritter wrote: It's all said by the title: I would prefer a new option box in the save dialog where the user can specify to take the old password to save the document with instead of typing a new one or even the same old password twice again. A nice tool for versioning e.g. confidential documents! Precondition - of course - would be that the actual document was already saved using a password. Otherwise the option box has to be disabled. That would be a nice feature to achieve needs that you mention. To securely implement it, we might need additional feature such as handing with a master pass-phrase to encrypt the password that a user types to open the document file. It comes from a technical reason. 1. A user tries to open a password protected document file. 2. An application prompts the user to enter a password. 3. The application opens the file with the password. 4. The application memorizes the password somewhere. 5. The user revises the document. 6. The user tries to save the document. 7. The application retrieves the password which has been kept somewhere. 8. The application save the document with the password. 9. The user close the document. 10. The application erases the password. The password could be leaked during the step 2 to 10 since the password should be physically stored in a system memory, disk device or something else. If the password is stored without encryption, it could be leaked. You might have experienced this type of behavior of one operating system. 1. The operating system (OS) finds that an application crashes. 2. The OS asks the user if the OS can send data to their laboratory via the Internet for investigation. 3. If the user answer 'Yes' to the OS, the OS sends data which might includes the password stored in the memory. If the password is stored in a disk device, there would be a chance to directly read it using a special tool, although the file is protected with a permission managed by the OS. I guess, that would be the primary reason why most application do not have the feature that you are proposing. Any good idea? Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Eike, The idea sounds good. The problem is that we can not currently 100%-correct say whether current user is able to open the document ( ACL and so on in heterogeneous network can make life complex ), we have to try to open it to know it for sure. In those circumstances it would be problematic to detect whether other users would be able to edit the document. Another possible minus, it could be confusing for some users, who do not know much about access rights. Best regards, Mikhail. On 06/23/09 12:51, Eike Rathke wrote: Hi Mikhail, On Monday, 2009-06-22 07:26:03 +0200, Mikhail Voytenko wrote: In other words, there should be a possibility to configure office in the way, that it opens the documents readonly always. If user wants to edit the opened document, he has to switch the document to edit mode explicitly. Just a quick idea: let the preferred open mode also depend on the file's access permission properties. If a file's permissions allow only the current user write access there's no reason to open it read-only. Eike
Re: [dev] Document file lock system could be enhanced
Hi Tora, The current design is quite easy, if a document is opened read-only it is not locked. If document is opened for editing it is locked. I must confess, I do not quite understand which scenario do you expect from me. Actually we have discussed scenario you have provided, and I have only suggested a possible solution for it. It would help in the scenario you have described, since to edit document the user would have to explicitly switch to edit mode using Edit button: Another scenario, Locked out by a reviewer 1. User A has created an Impress document for a meeting held this afternoon. 2. User A sends an e-mail to her college User B to ask reviewing it. 3. User B opens the document file stored in their file server. 4. Lunch time has come and User B goes to the restaurant. 5. User A has found some errors in the document. 6. User A tries to load the document, but gets warned The file is locked by the User B. Best regards, Mikhail. On 06/22/09 08:09, tora - Takamichi Akiyama wrote: Hi Mikhail, Mikhail Voytenko wrote: although the provided document handling scenario looks to be a little bit strange for me, opening the document readonly as Mathias has already suggested would be the solution. In your case the documents are opened from the file explorer. So you need probably a possibility to let office open every file readonly by default. Could you provide us with a user scenario using a possible solution opening all documents readonly by default? case A) a single user handling an existing document file; when the file gets locked and when unlocked? case B) two users sharing one document file in a file server and one user editing it case C) multiple users sharing one document file in a file server and some users unexpectedly editing it simultaneously case D) File - Save As, previous one unlocked and new one locked, become readonly? case E) Starting with an empty file (couldn't be readonly) and File - Save, become readonly, locked? ... I have been trying to imagine that, and found it is hard for me. In other words, there should be a possibility to configure office in the way, that it opens the documents readonly always. If user wants to edit the opened document, he has to switch the document to edit mode explicitly. The feature would be a consistent part of the current design, so please submit a new feature request to me ( m...@openoffice.org ) for this. PS: Please try to avoid writing words with capital letters without necessity, ... Thank you for the suggestion. I will keep it in mind. Best Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, although the provided document handling scenario looks to be a little bit strange for me, opening the document readonly as Mathias has already suggested would be the solution. In your case the documents are opened from the file explorer. So you need probably a possibility to let office open every file readonly by default. In other words, there should be a possibility to configure office in the way, that it opens the documents readonly always. If user wants to edit the opened document, he has to switch the document to edit mode explicitly. The feature would be a consistent part of the current design, so please submit a new feature request to me ( m...@openoffice.org ) for this. Best regards, Mikhail. PS: Please try to avoid writing words with capital letters without necessity, this let the sentence look like a cry, such emails usually get less attention on the list. I have now answered because we continue the already started discussion. On 06/19/09 14:01, tora - Takamichi Akiyama wrote: Hi, Please DO NOT LOCK a file when a user just loads a file. Mikhail, I do not want to bother you, but, ... Please, please, make productive office suite more PRODUCTIVE. Another scenario, Locked out by a reviewer 1. User A has created an Impress document for a meeting held this afternoon. 2. User A sends an e-mail to her college User B to ask reviewing it. 3. User B opens the document file stored in their file server. 4. Lunch time has come and User B goes to the restaurant. 5. User A has found some errors in the document. 6. User A tries to load the document, but gets warned The file is locked by the User B. 7. User A calls the User B, but hears a message from B's answering machine. 8. The meeting is arranged at 1:00pm. It is 12:30 now. 9. User A tries to call User C to ask to close User B's document. 10. User C, however, is also at the restaurant with B. 11. User A runs to User B's booth located in another building. 12. I know, they are not so stupid. But this type of scenario could be seen here and there since office suite software products are widely used by from children to elderly people. The similar situation could be also observed in an elementary school, etc. Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, I think I see the problem. Probably you have exactly the case when file system locking does not work. And the current implementation checks whether the file was changed only if system file locking is not used by the document. That is of course a bug, actually the OOo locking mechanics was introduced to workaround the known problems with the system file locking, so the check should be active always. I have just submitted a new issue to myself http://qa.openoffice.org/issues/show_bug.cgi?id=102701 Thank you for finding the problem. By the way, SAL_ENABLE_FILE_LOCKING does only affect sal implementation. So if it is not set the framework and office implementation still believes that the system file locking is used, at least the implementation requests sal to use it ( actually this variable looks to be a hack for me ). To let the framework not use the system file locking, there is a configuration entry /org.openoffice.office.Common/Misc/UseDocumentSystemFileLocking, that let framework request no system file locking from sal for documents. Best regards, Mikhail. On 06/18/09 11:55, tora - Takamichi Akiyama wrote: The step 4 can not overwrite the file because the system file locking is active. If it was turned off, it would overwrite the document and the step 6 should show the warning. I am not sure about the reasons. The file (a) is /home/tora/z.odt . The directory /home/tora is NFS auto-mounted. I can do the step 4 without error. I have confirmed again and again. It seems that the file is not locked by the OS or NFS. I have not touched the Shell script /opt/openoffice.org3/program/soffice . It has the lines below: === # file locking now enabled by default SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING === Anyway, I would be browsing the CWSs. Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, On 06/19/09 09:25, tora - Takamichi Akiyama wrote: Hi Mikhail, Mikhail Voytenko wrote: I think I see the problem. Probably you have exactly the case when file system locking does not work. And the current implementation checks whether the file was changed only if system file locking is not used by the document. That is of course a bug, actually the OOo locking mechanics was introduced to workaround the known problems with the system file locking, so the check should be active always. I have just submitted a new issue to myself http://qa.openoffice.org/issues/show_bug.cgi?id=102701 You mean this? http://www.openoffice.org/issues/show_bug.cgi?id=102931 Yes, sorry for the copy-paste error. By the way, there would be some ways to confirm if a target file has been modified. (a) time stamp of a target file (b) digest value of a target file (c) original content of a target file The current OOo implementation uses (a). The (b) could be discussed if there is necessity for check improvement, but it would still affect the performance. The (c) is no option from my point of view. As you know, Subversion is not using (a) to find modified files. Subversion has completely different task, and has to handle much more complex scenarios. So it's behavior can not be treated as argument here from my point of view. A criteria of modified could be reconsidered. Yes of course, but the coefficient efforts/benefits should be always in mind while doing so. As time goes, there would be more and more heterogeneous computing environments surrounding users. Somewhat unconvincing scenario: 1. A user downloaded (or checks out) her document file from the Internet disk yesterday. 2. Today, she starts editing the file with OpenOffice.org. 3. She downloads it again since she forgets when she downloaded it and ensures she has the latest one. 4. She attempts to save current document on the OpenOffice.org to the file. 5. She faces ... On the step 5, what should happen? A) A dialog window appears with a message: The file has been MODIFIED after you had loaded the file (in fact, the content of the file has not changed, though) B) Nothing happens since the content of the file has NOT CHANGED, even its time stamp has been changed, and she successfully saves the document to the file. Actually the step (3) should not be possible. Unfortunately it is possible because of bugs in system file locking, in those circumstances (A) looks quite good from my point of view. Without merging functionality, the action with downloading of the document to get up-to-date version has no sense anyway. And sorry, but I see no reason to sacrifice the storing performance to let an absolutely theoretical from my point of view scenario look a little bit nicer. Especially if the scenario is only possible because of bug in system file locking. I am not sure that which is better for current the generation of users: (A) comparing a time stamp of the file to determine modifications (B) comparing contents of the file to determine modifications But I bet (B) would be better for the future. Please see above. (B) seems to make sense only for the case of shared documents if there is merging functionality. Best regards, Mikhail. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, On 06/18/09 11:27, tora - Takamichi Akiyama wrote: Hi Mikhail, Mikhail Voytenko wrote: OOo3.1 has already collision detection system, although it is mostly useful in case system file locking is turned off. If the document was changed during the editing the user gets notification that he might remove changes from somebody else. If the system file locking is on, the mentioned scenario is only possible when the system file locking does not work as expected. That might happen in heterogeneous networks. Is there any document, reference, issue, ... on that? There was a feature mail notification regarding this. Please take a look to the changes introduced for cws mav43. There are a number of issues related to the file locking. With DEV300_m48 locally built on OpenSolaris x86, I cannot know how to enjoy with it. 1. Prepare two existing .odt files: (a) and (b). 2. Start OpenOffice.org DEV300_m48. 3. Open (a) with the OOo. 4. Overwrite (a) with (b) using 'cp' UNIX command. 5. Make modifications on OOo. 6. Save the document by pressing Ctrl-S. Nothing seems to happen. Maybe, I am doing somewhat wrongly. The step 4 can not overwrite the file because the system file locking is active. If it was turned off, it would overwrite the document and the step 6 should show the warning. Best regards, Mikhail. Regards, Tora On 06/17/09 06:42, tora - Takamichi Akiyama wrote: 2. Collision detection User A |++-+-- time line ^open^modify ^save 12 3 User X |+++- ^open^modify ^save 456 User X could be informed that the disk file has been altered by someone else -(6) and prompted: (a) Overwrite the file with yours (Warning: someone else's changes will be lost) (b) Save your document as another file (c) Cancel - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Document file lock system could be enhanced
Hi Tora, OOo3.1 has already collision detection system, although it is mostly useful in case system file locking is turned off. If the document was changed during the editing the user gets notification that he might remove changes from somebody else. If the system file locking is on, the mentioned scenario is only possible when the system file locking does not work as expected. That might happen in heterogeneous networks. Best regards, Mikhail. On 06/17/09 06:42, tora - Takamichi Akiyama wrote: Hi, Why don't we, at least, consider letting OpenOffice.org have a collision (or conflict) detection system to prevent loosing someone else's efforts. tora - Takamichi Akiyama wrote: 2. Collision detection User A |++-+-- time line ^open^modify ^save 12 3 User X |+++- ^open^modify ^save 456 User X could be informed that the disk file has been altered by someone else -(6) and prompted: (a) Overwrite the file with yours (Warning: someone else's changes will be lost) (b) Save your document as another file (c) Cancel Related scenarios: http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=24974 Regards, Tora - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Using Macros
Hi Albert, That sounds strange. A simple OOo basic test shows that there is no problem with loading of a template using API calls you have used ( with correct property name and value 4 ), the macros are executable afterwards. Just to be sure that the macro execution mode is the problem, can you execute the macros in Tools/Macros/Organize Macros/OpenOffice basic... dialog? Best regards, Mikhail. On 05/26/09 08:33, Albert Arnau wrote: I know but it doesn't work either. Salutacions, Albert Arnau Director Tècnic Valen Computer Ctra. Valls (Urb. Sant Salvador) C/Poeta Mistral, 2 - 43130 - Tarragona Tel (34) 977 52 30 02 - Fax (34) 977 52 30 05 e-mail: a...@valen.es www.valen.es -Mensaje original- De: Mathias Bauer [mailto:nospamfor...@gmx.de] Enviado el: lunes, 25 de mayo de 2009 22:58 Para: dev@openoffice.org Asunto: Re: [dev] Using Macros Hi, I think Mikhail wanted to point out that the name should be MacroExecutionMode, not MacroExecMode. Regards, Mathias Albert Arnau wrote: Hi I've use it with value 4 and it doesn`t work. Salutacions, Albert Arnau Director Tècnic Valen Computer Ctra. Valls (Urb. Sant Salvador) C/Poeta Mistral, 2 - 43130 - Tarragona Tel (34) 977 52 30 02 - Fax (34) 977 52 30 05 e-mail: a...@valen.es www.valen.es -Mensaje original- De: mikhail.voyte...@sun.com [mailto:mikhail.voyte...@sun.com] Enviado el: lunes, 25 de mayo de 2009 15:43 Para: dev@openoffice.org Asunto: Re: [dev] Using Macros Hi Albert, Please use MacroExecutionMode as argument name. Best regards, Mikhail. On 05/22/09 10:00, Albert Arnau wrote: Hi everybody, I've a little problem with the macros in OpenOffice. I've a template where I have developed macros inside, when i open this template the macros as executed correctly. The problem is when i open that template in my application (in visual basic) the macros are no executed, i don't know why. Here is the code that I use *Set oDesk = CreateUnoService(com.sun.star.frame.Desktop)* *Set oParam(0) = MakePropertyValue(MacroExecMode, 4)* *Set oDoc = oDesk.loadComponentFromURL(ConvertToUrl(SelDoc), _blank, 0, oParam())* I also attack the template Any help? thanks Salutacions, Albert Arnau Director Tècnic Valen Computer Ctra. Valls (Urb. Sant Salvador) C/Poeta Mistral, 2 - 43130 - Tarragona Tel (34) 977 52 30 02 - Fax (34) 977 52 30 05 e-mail: a...@valen.es mailto:a...@valen.es www.valen.es http://www.valen.es - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring
Re: [dev] Using Macros
Hi Albert, Please use MacroExecutionMode as argument name. Best regards, Mikhail. On 05/22/09 10:00, Albert Arnau wrote: Hi everybody, I've a little problem with the macros in OpenOffice. I've a template where I have developed macros inside, when i open this template the macros as executed correctly. The problem is when i open that template in my application (in visual basic) the macros are no executed, i don't know why. Here is the code that I use *Set oDesk = CreateUnoService(com.sun.star.frame.Desktop)* *Set oParam(0) = MakePropertyValue(MacroExecMode, 4)* *Set oDoc = oDesk.loadComponentFromURL(ConvertToUrl(SelDoc), _blank, 0, oParam())* I also attack the template Any help? thanks Salutacions, Albert Arnau Director Tècnic Valen Computer Ctra. Valls (Urb. Sant Salvador) C/Poeta Mistral, 2 - 43130 - Tarragona Tel (34) 977 52 30 02 - Fax (34) 977 52 30 05 e-mail: a...@valen.es mailto:a...@valen.es www.valen.es http://www.valen.es - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voyte...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring
Re: [dev] xslt filters as extensions - swext
Hi Emmanuel, On 03/31/09 19:51, Emmanuel Bégué wrote: Mikhail, This does not appear to be a filter based on XSLT? It is an extension that installs such a filter filter. As I understood you were interested in installation of xslt filter in extension, this is exactly what happens here . Please take a look to http://svn.services.openoffice.org/ooo/cws/mav46/swext/mediawiki/build.xml, there is uno-package target that builds the extension package including a number of xslt transformation files. In the following folder the xcu files related to filter registration are built. http://svn.services.openoffice.org/ooo/cws/mav46/swext/mediawiki/src/registry/data/org/openoffice/TypeDetection/ Best regards, Mikhail. Regards, EB - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] filters as extensions -- still no luck -- looking for one working example
Hi Emmanuel, The new version of Sun Wiki Publisher extension in mav46 childworkspace does it. Actually the MediaWiki filter will no more be installed as a part of OOo installation starting from OOo3.2, the extension will install it. So you could try to checkout swext module from this cws and investigate it. By the way, if two extensions install the same filter, the result is unpredictable if I remember correctly. Best regards, Mikhail. On 03/31/09 17:48, Emmanuel Begue wrote: Hello again, I believe I have just checked all extentions from the extensions repository here: http://extensions.services.openoffice.org/ and could not find one case of a simple XSLT filter packaged as an extension. Is there such an example anywhere or can anyone provide one? (The example mentionned below does not in fact install a filter; this is not immediately obvious because it has the same name as a default filter (MediaWiki) but when one removes the original filter, or even does a fresh install with no filters, and then tries to install this extention, this does not create a MediaWiki filter (or any other one for that matter)). Regards, EB -Original Message- (...) if I try to install the extension provided as an example on this same page: http://wiki.services.openoffice.org/w/images/6/66/Mwikidemo.oxt with zero alterations, the extension installs properly but the filter is not accessible...? Neither in the filter list from the tools menu, nor in the filter list from file/export. (I tried several times on fresh oo installs). - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voite...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring
Re: [dev] generate first page thumbnail
Hi Aaron, On 03/27/09 18:48, Aaron Ehrensberger wrote: 1. A quick way to snag a snapshot of the first page of the doc using OO for the thumbnail? Unfortunately there seems to be no general API to create a thumbnail of a document. May be there is an application API that would allow this. Actually it would be no problem to implement it generally in framework, I have just submitted an enhancement for this http://qa.openoffice.org/issues/show_bug.cgi?id=100663 2. A faster way to convert the doc? Currently, I'm loading the file from a URL, then storing the file (which does the conversion). Is there a faster utility that doesn't force me to open and save the doc? Currently all the documents that were stored using 2.4 and 3.x versions contain an internal thumbnail. It is in png-format and has size 256x256 pixels. If it is enough, you could try to get the storage from the loaded model using css::document::XStorageBasedDocument::getDocumentStorage(), open the substorage Thumbnails and then open the stream thumbnail.png in the substorage. The stream contains the thumbnail. Please remember that very old versions of the office do not store the thumbnail, so there is a probability that a document has no thumbnail. In this case the way you are doing it currently looks to be reasonable. Hope that helps. Best regards, Mikhail. Aaron Aaron Ehrensberger Software Architect DocFinity(r) by Optical Image Technology, Inc. 100 Oakwood Avenue, State College, PA 16803 ph: 814.238.0038 ext. 270 fax: 814.238.0011 email: aehrensber...@docfinity.com web: www.docfinity.com -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voite...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Typo in sal/osl/unx/file.cxx
Hi, The new issue is http://qa.openoffice.org/issues/show_bug.cgi?id=100351 Best regards, Mikhail. On 03/18/09 09:54, Mikhail Voytenko wrote: Hi Pavel, You are right, it looks like a typo. Could you please write an issue to me ( m...@openoffice.org ). Thanks, Mikhail. On 03/17/09 18:01, Pavel Lastovicka wrote: Hello, I was looking at the source code in sal/osl/unx/file.cxx. And there in function osl_openFile() is the following code: /* remove the NONBLOCK flag again */ flags = fcntl(fd, F_GETFL, NULL); flags = ~O_NONBLOCK; if( 0 fcntl(fd, F_GETFL, flags) ) return oslTranslateFileError(OSL_FET_ERROR, errno); The second fcntl call should be fcntl(fd, F_SETFL, flags), shouldn't it? -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voite...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Typo in sal/osl/unx/file.cxx
Hi Pavel, You are right, it looks like a typo. Could you please write an issue to me ( m...@openoffice.org ). Thanks, Mikhail. On 03/17/09 18:01, Pavel Lastovicka wrote: Hello, I was looking at the source code in sal/osl/unx/file.cxx. And there in function osl_openFile() is the following code: /* remove the NONBLOCK flag again */ flags = fcntl(fd, F_GETFL, NULL); flags = ~O_NONBLOCK; if( 0 fcntl(fd, F_GETFL, flags) ) return oslTranslateFileError(OSL_FET_ERROR, errno); The second fcntl call should be fcntl(fd, F_SETFL, flags), shouldn't it? -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voite...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - 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.
Hi Frank, On 02/26/09 09:20, Frank Schönheit wrote: As much as I agree that error handling needs to be improved, I don't like the idea to pollute exception messages with information about the file where the exception happened. This information should be separated from the mere message, since the latter is (potentially) to be shown to the user, but the former usually isn't. But perhaps I get you wrong here, since you also talk about a details window provided by the InteractionHandler, which would imply that either the handler needs to strip the error location from the message (ugly and error prone), or that you want to transport the location by other means than by appending it to the message. My intention was to allow user provide the developer with information that identifies the source of the error. It would be useful in case of problems that appear once a year, and look to be mysterious from the first view. Ugly is a taste-related comment, so it is hard to argument for/against it. As for error prone transportation, a screenshot solves this problem easily. In case of exceptions that have no arguments ( and we have many of such cases ), Shouldn't we change those exceptions to actually *contain* a message? And, more important, teach ourself to *not* throw exceptions which do not contain a message? If our exceptions had a message, it would be easy to search for the message in our code base, and find the place where it is thrown. By the way, the rework would take much more time, than the script adding the lines. From this point of view, it is better to let the script run and have at least the line numbers in the messages, than to dream how we change all the extensions in our office. Anyway, I have nothing against adding messages to all the exceptions, if we have resources to do it. I see no conflict between those two tasks. But even if all of them have messages ( thousands of unique messages? ), the filename and linenumber will stay the best unique identifier, as actually assertions prove. As said above, exception messages are often displayed to end users (imagine Basic scripts), so I always strongly disliked the throw FooException() places, since this results in FooException. being displayed to the end user, which is in no way helpful, and simply a usability bug. So, to make it short: We should provide meaningful error messages when throwing exceptions, this would solve the problem, too, in an even broader context. Completely agree, we should. But again, I would not mix those two solutions.. http://wiki.services.openoffice.org/wiki/Category:Logging We have good experiences with this. For instance, our JDBC-SDBC bridge is paved with logger calls. When logging (for this particular logger) is not enabled, then this costs nearly no time, since it is just about noticing that nothing needs to be logged. However, when it is enabled, then the result is a log file which we can use to examine what went on on the user's machine (Since the user has to explicitly enable this, and send us the log file, this isn't a privacy problem). In particular, the component has a central method for throwing exceptions, and there, all to-be-thrown exceptions are logged. Together with method entry guards (enter foo( bar ), leaving foo with result x), this allows a pretty good analysis. So, my suggestion would be to create dedicated loggers for your components, and log the to-be-thrown exceptions. This is a nice solution. It would help in our case, although the minus is that it has to be turned on before the problem happens. And some problems of the mentioned kind, are hardly reproducible. Thanks, Mikhail. - 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.
Hi Stephan, On 02/26/09 09:28, Stephan Bergmann wrote: On 02/25/09 15:51, Mikhail Voytenko wrote: This is of course nothing new, the discussions regarding better error-handling design can be seen regularly. But in our case, even an information, which exactly exception has caused the problem ( in our scenario there is a high probability that an exception takes place ) would be helpful. On a somewhat related note, also see http://qa.openoffice.org/issues/show_bug.cgi?id=94351 pass information about uncaught/unexpected C++ exceptions to crash reporting. I have added a comment to the issue. This is from my point of view another argument to have the file name and line information in the exception. Best regards, Mikhail. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Error handling in OOo, shouldn't we show additional info.
Hi All, While discussing with Mathias a mysterious non-reproducible problem, we came again to conclusion that OOo error handling is not the best one from the developer point of view. It is quite hard to understand what exactly goes wrong sometimes. This is of course nothing new, the discussions regarding better error-handling design can be seen regularly. But in our case, even an information, which exactly exception has caused the problem ( in our scenario there is a high probability that an exception takes place ) would be helpful. The first idea was to provide information similar to the assertions. Each extension could use the macros wrapping the existing text and adding the file name and line number. Since usually the text is based on the constant string literal, the generation of the string would not affect the performance. In case of exceptions that have no arguments ( and we have many of such cases ), we could use a default macro for each type of extension, that would not take so much time I think. That could be actually done by a relative simple script. In result the InteractionHandler could get the requests containing additional information. This information could be shown in a kind of details... subwindow of the error message. There were already suggestions from UX to extend the error messages with such a details window. The framework and applications also would have a chance to provide this additional information in this way. In general it looks from the first view to be realistic even for OOo3.2. From other side it is only a very quick first view, so any suggestions, corrections and etc are very welcome. Best regards, Mikhail. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
