[api-dev] Re: Displaying Multiple Dialogs from BASIC
On 16.06.2011 09:22, Hal Vaughan wrote: I've mentioned the sticky-note project I'm working on yesterday in two emails. Now I'm running into a problem: I'd like to display a number of sticky-notes, but to display any kind of dialog in BASIC, I need to do something like this: oSticky = createUnoDialog(DialogLibraries.HalLib.StickyNote) oSticky.Execute() And the program will stop until I close the dialog, either by the close button, a cancel, or OK, or another button. That means the only way to have multiple dialogs open is to open one and from there, open the next, and then open the next and so on. Is there some way, from BASIC, to display a dialog and leave it open without it stopping a script? Execute() starts a modal mode, so it is not only understandable but also required that further *linear* execution of the script stops (handlers registered to buttons still we be called). If you want to have more than one dialog, you have to execute them in a modeless way. I don't know if oSticky.SetVisible(True) works (I even don't know if UnoDialogs export an XWindow interface), but that's how it is done with C++ dialogs. Besides that you will need to redesign your dialog a bit, modeless dialogs usually don't have OK or Cancel buttons, because they directly act on the document when their buttons are operated by the user. If your dialog logic makes it necessary to have an OK button, most probably a modal dialog is recommended and no other dialogs (except sub dialogs) should be operable while it is visible. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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 send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help
[api-dev] Re: Toolbar items: how to get them to show the shortcut letter underlined ?
On 25.05.2011 10:34, Rony G. Flatscher wrote: On 25.05.2011 08:35, Mathias Bauer wrote: On 24.05.2011 22:31, Rony G. Flatscher wrote: Hi there, in the meantime I have been able to add shortcuts to the toolbar items and they are operational. However, the shortcut letter is not underlined, although using the tilde (~) before the letter to be underlined in the Label property of the toolbar item. Is there a different property that I would need to use for having OOo underline the shortcut-key? (Again it works, using SHIFT+ALT+letter, where ALT is the META2 KeyModifier.) TIA, ---rony What do you mean by again it works, using SHIFT+ALT+LETTER ? Just that the defined shortcut-keys are operational. E.g. the shortcut for the ~Import toolbar item gets defined as SHIFT+META2+I and if you press SHIFT+ALT+I (META2 is ALT on my Windows keyboard) the toolbar item gets executed. It is just the case that the I does not get underlined in the toolbar item (a button where the text and the assigned icon get displayed). Sorry for being dense ;-), where did you define the shortcut? If a shortcut is defined in a menu, it will executed only if the menu has the focus. I don't think that this works in toolbars. If I just ad a tilde to a toolbar item label, I don't see a way to execute this label as a command like in a menu. Are you sure that you don't talk about accelerators (those who are assigned to commands using tools-customize-keyboard)? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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 send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help
[api-dev] Re: Toolbar items: how to get them to show the shortcut letter underlined ?
On 25.05.2011 12:06, Rony G. Flatscher wrote: Are you sure that you don't talk about accelerators (those who are assigned to commands using tools-customize-keyboard)? O.K., I think the best is that I show you the code snippets then. The code is in ooRexx but excersises the Java API behind the curtain. The tilde in ooRexx is the message operator, so left of the tilde is the receiving object, right of it the message. In case a queryInterface() is needed, the ooRexx UNO support allows one to merely send the unqualified interface name to the UNO object in order to retrieve that interface. Line comments start with two consecutive dashes (--), block comments are C-like (but can be nested in the Rexx language). Having said that, here's the snippet, which should give you the exact information, please look for the area after the comments lead in as /* (snip) /* *** shortcut *** */ -- got shortcut manager, define key with Shift+Alt combination oShortCutManager=x_UIConfigurationManager~getShortcutManager xShortCutManager=oShortCutManager~XAcceleratorConfiguration modifiers =bsf.getConstant(com.sun.star.awt.KeyModifier, SHIFT) -- Shift-key modifiers+=bsf.getConstant(com.sun.star.awt.KeyModifier, MOD2) -- Alt-key KeyEventClz=bsf.importClass(com.sun.star.awt.KeyEvent) Exactly, these are accelerators, not shortcuts. This is not about the words (others might even use them the other way around), but about the way they are executed. In OOo accelerators work independently from any other UI elements, e.g. menu or toolbar items. In the default configuration CTRL-O will always execute the command .uno:Open, even if no toolbars or menus are present. OTOH, the *menu shortcut* (specified by putting a tilde in front of the letter O in a corresponding menu item label) for this function ALT-F, O (in the English version) can only be used by operating the menu with the keyboard. A comparable functionality does not exist for toolbar items. Thus, a tilde in a toolbar item label does not have any effect and is just considered as garbage. OTOH, toolbar quickhelp texts can show *accelerators* that are configured for the same functionality, in the same way as the menus do. (We don't do that in the item text as in menus as space in toolbars is more limited.) The quickhelp for the Open button shows Open (CTRL+O) because CTRL+O is the accelerator for the .uno:Open command (in the default configuration that may be changed via tools-customize-keyboard). And the menu item for Open also shows CTRL+O. There is some code in OOo's framework that adds the accelerators to the label or quickhelpt text. In menus this code works immediately as menus are always created at the very moment they are opened. Toolbar quickhelp texts need an update notification when the shortcut was changed. As it seems, this update notification is not sent. But the quickhelp text of a new document would be correct as the accelerator is already known when the toolbar is created. As an example, I configured SHIFT-ALT-G for Insert-Gallery in the keyboard configuration. The view menu (don't ask me why the menu has it in view, the config in insert ;-)) immediately shows the new accelerator, the toolbar quickhelp doesn't. If I now open a new document, its toolbar shows the accelerator in the quickhelp text of the Gallery button. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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 send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help
[api-dev] Re: Toolbar items: how to get them to show the shortcut letter underlined ?
On 25.05.2011 14:32, Rony G. Flatscher wrote: How can I define a quickhelp text for each toolbar item? It seems that by default the label of the toolbar item is used as the quickhelp (tooltip?) text, and that does not exhibit the shortcut key by underlying it. Indeed the quickhelp text is the label. It *should* exhibit the shortcut key that is assigned to the same command as the toolbar item, if you make sure that the keyboard configuration was created before the toolbar was created. If not, this would be a missing feature ;-). As I wrote, the accelerator key was shown for built-in commands and for basic macros. So I don't see a general reason why it shouldn't work for scripts. As an example, I configured SHIFT-ALT-G for Insert-Gallery in the keyboard configuration. The view menu (don't ask me why the menu has it in view, the config in insert ;-)) immediately shows the new accelerator, the toolbar quickhelp doesn't. If I now open a new document, its toolbar shows the accelerator in the quickhelp text of the Gallery button. Just tried this via Tools-Customize, but it did not work with the toolbar item. *what* did you try? My example with .uno:Gallery or your script/macro? In case you didn't notice, it is necessary to create the toolbar *after* you have configured the shortcut, e.g. by opening a new document window. P.S.: One observation: it is not possible to delete the programmatically created toolbar using Tools - Customize as the delete option is greyed out. One can delete the individual toolbar items and make the toolbar empty and on the next restart the toolbar seems to have gone. I don't know if this is a bug or by intent, sorry. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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 send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help
[api-dev] Re: Toolbar items: how to get them to show the shortcut letter underlined ?
On 25.05.2011 17:35, Rony G. Flatscher wrote: As an example, I configured SHIFT-ALT-G for Insert-Gallery in the keyboard configuration. The view menu (don't ask me why the menu has it in view, the config in insert ;-)) immediately shows the new accelerator, the toolbar quickhelp doesn't. If I now open a new document, its toolbar shows the accelerator in the quickhelp text of the Gallery button. Just tried this via Tools-Customize, but it did not work with the toolbar item. *what* did you try? My example with .uno:Gallery or your script/macro? Your example. In case you didn't notice, it is necessary to create the toolbar *after* you have configured the shortcut, e.g. by opening a new document window. Did try that, even shut down all instances of OOo writer. It's OOo 3.2.1 though, so maybe that does not work with that old version? Hm, probable. I tested with 3.3. Maybe if I come across a 3.2.1 I might try it again. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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 send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help
[api-dev] Re: Severe PrinterSettings Problems, need confirmation
Hi Fernand, AFAIK Philipp Lohmann (pl) is working on it or at least should know who else. If you prefer an open communication channel, please try dev@gsl. Regards, Mathias On 16.03.2011 09:10, Fernand Vanrie wrote: Mathias, Any idea, who is working on or in what version we can do some testing ? thanks Fernand Hi Fernand, On 09.03.2011 14:24, Fernand Vanrie wrote: Hallo Sinds 3.3 (windows) all PrinterSettings except the Printer Name are no longer persistent and not stored anywhere not in the profile, not in the document. Within the settings we have the options who are not Printer specific and we have Settings who are bound to a specific printer. Both are all lost after reloading the document, but we can only use the Printer specific settings during the printing itself. So PageSizes set PrinterSettings must been redone while actualy printing. Setting the PageSizes using the API is also broken, please trye the included code with a printer who accept to changes the PaperSizes PLease can someone confirm this, so i can fill a issue AFAIK the new printer dialog implementation brought this unfortunate side effect. Also AFAIK this is already being worked on. Regards, Mathias -- - To unsubscribe send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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 send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help
[api-dev] Re: embed OO-Window in a Qt Window
On 22.03.2011 09:59, Konstantin Tokarev wrote: 19.03.2011, 17:08, Goran Markicgo...@markic.ch: Dear Sirs We are developing a multi platform (Windows, Linux, Mac) software for communication with our scientific instruments. Therefore we use the qt framework. We would like to embed a spreadsheet or a writer window within our qt window. Because we are developing for several operating systems we think that Open Office could be appropriate for our needs. After studying the UNO framework I haven't found the possibility to integrate an Open Office window into another Application. As far as I have seen, with an axtiveX component it should be possible, but then we are restricted to Windows. Could you please inform us if this is possible with Open Office for the mentioned platforms. Thank you very much Best regards, Dr. Goran Markic Markic Scientific Instruments Disclaimer: I'm not an expert in OOo or UNO programming Nevertheless your answers are excellent. :-) I just want to add something. 3. On X11 platforms you can try to use QX11EmbedWidget to embed OOo window. In general OOo can reuse system windows as OOo windows. We are using this technique not only for the ActiveX component that was mentioned above, but also for the Mozilla browser plugin that works on all platforms. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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 send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help
[api-dev] Re: How to retrieve the state of the feature Format AutoCorrect While Typing in Writer ?
On 28.02.2011 14:07, Thibault Vataire wrote: Hi, I need to programmatically retrieve the state of the feature Format AutoCorrect While Typing in Writer. I've tried two ways but none works properly : 1/ Reading the corresponding property in the Writer.xcu configuration file. But this value don't seem to be updated when application is running, only when the application is shutting down. That's intended; you should see the xcu files as an implementation detail that shouldn't be accessed at runtime. 2/ I can read the state of the menu's entry : myFrame.LayoutManager.getElement(private:resource/menubar/menubar).XMenuBar.getPopupMenu(itemId1).(...).isItemChecked(itemId2) But this value is really updated only if the menu AutoCorrect is displayed one more time after the value has changed. This isn't a good idea. Is someone known another way to retrieve this value ? You could register a StatusListener for .uno:OnlineAutoFormat (IIRC). But this means that you have to do that at every frame. It should be possible to register a ConfigurationUpdateListener for the corresponding key in the xcu file, but it's possible that it doesn't work either because Writer caches this setting internally. That would be a bug, but I assume that this doesn't make it better. I'm afraid you have to find that out. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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 send email to dev-unsubscr...@api.openoffice.org For additional commands send email to sy...@api.openoffice.org with Subject: help
Re: [api-dev] Working with embedded OLE files/packages
Hi David,
On 07.12.2010 12:24, David Roe wrote:
I have some Excel spreadsheets that contain files embedded as OLE packages
(Insert-Object- From file). I want to retrieve the data for those files.
I've managed to use the API to retrieve the Shape object and get at the OLE
data but I don't fancy writing my own OLE reading code. Is there an API to
get at the data inside? I saw css.embed.OLESimpleStorage but I can't seem to
get anywhere with that. My code so far is (in Python):
# ... setting up of OOo ...
sheet = doc.Sheets.getByName('Sheet1')
draw_page = sheet.DrawPage
shape = draw_page.getByIndex(0)
# CLSID ---- is a file??
print 'CLSID:', shape.CLSID
obj = shape.EmbeddedObject
# Create a storage object to hold the data from our embedded
object
storage_factory =
service_manager.createInstance('com.sun.star.embed.StorageFactory')
storage = storage_factory.createInstance()
# Store the data into the Something entry of our storage object
obj.storeToEntry(storage, 'Something', (), ())
str_elem = storage.openStreamElement('Something', ElementModes.READ)
stream = str_elem.getInputStream()
sfa =
service_manager.createInstance('com.sun.star.ucb.SimpleFileAccess')
sfa.writeFile(file_url('test.txt'), stream)
Thanks,
David Roe
As you are asking here, this code obviously doesn't work. Can you tell
us where something goes wrong?
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Footnote service not starting
On 29.11.2010 09:27, Swati Soni wrote:
Dear Sir,
I tried executing the Following code. The mxDocFactory is unable to open the
footnote service.
How to resolve this error.
Request you to please reply to this problem.
try
{
// Create a new footnote from the document factory and get it's
// XFootnote interface
XFootnote xFootnote = (XFootnote) UnoRuntime.queryInterface(
XFootnote.class,
mxDocFactory.createInstance ( com.sun.star.text.Footnote ) );
I don't know what mxDocFactory is in your code. If I take it from a
text document, creating a footnote works as expected, e.g. in Basic:
Sub Main
obj = ThisComponent.createInstance(com.sun.star.text.Footnote)
print obj.dbg_supportedinterfaces
End Sub
This will display all interfaces of the implementation class SwXFootnote.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Document Server Memory Leak Suspicion
Hi Chris, On 02.11.2010 13:40, Chris Rider wrote: I hope this is an active mailing list ~ we have a serious issue with the document server and are trying to track down some more knowledge that might exist about it. I have new information from further testing, but here's a quick summary: We have a program that calls the document server to load a PPT file (as explained below). That goes fine, and then we call it to close the file after some time... also goes fine -- mostly. The file will close, but then the memory continues to be eaten up by document server until the machine becomes non-responsive. We've run strace and can't find anything. We're calling the server over port 2803. We're calling the close method (which I've learned also calls dispose, etc.). We've got hundreds of products at customers and some are beginning to doubt OpenOffice as a platform... please help! We still don't have enough information, or perhaps not the right one. OOo in general definitely does not have a memory leak of that kind - you wouldn't be the first to find it in case of. I know that OOo is used as a server in a lot of installations without such huge problems. So there must be a particular issue that is special for your setup. So let's summarize and see where we can make progress. We should try to describe everything exactly as possible. You are talking about a document server and a DocumentLoader. The latter seems to be a C++ application and the former seems to be an instance of OOo that is talking with the C++ application though a remote UNO bridge. The DocumentLoader seems to use this instance of OOo to load a ppt file and then it seems that something is eating up your memory. Is that the correct picture? If not, can you describe it better? Especially we need to know most exactly how OOo is used in this scenario. Next question - this something that eats up your memory - did you verify that it is the OOo process whose memory consumption goes through the roof? Another question: did you try the same with other kinds of documents (not ppt)? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/28/2010 10:03 AM, Frank Schönheit wrote: Hi Mathias, I think that editing of OLE objects (and linked sheets are just a variant of them) should stay as they are: while you are editing the object, you might be able to undo parts of the editing, but after leaving the OLE object all changes made in this session can only be undone as a whole. A new API can't remove the intrinsic limitations of this concept. Not sure I'd sign this. Technically, I could imagine the embedded object adding Undo actions to the Undo manager of the container document (letting those actions survive/handle the temporary destruction of the embedded object when it is deactivated is, well, a challenge only, not an impossibility, I suppose :) ). Whether this is desired from an UX point of view might be a different question. This will break at least if the OLE object is not an OOo object. :-P Besides that, of course nothing is impossible in software. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/26/2010 03:07 PM, Andrew Douglas Pitonyak wrote: Although I am ignorant in much of this, I do have some random thoughts. Mathias Bauer mentioned allowing the container to control changes for some items (such as he did with notes2), but that this may be a problem with larger objects such as graphics objects and even OLE objects. Right, it doesn't work for OLE objects, but in case the object could provide undo actions that don't require to be in edit mode, it should work for even the largest graphic objects. The difference between graphic objects and OLE objects is that the graphic object does not vanish after editing - it just may be in a different mode. But that is also true for the container itself where different shell objects are created and removed depending on the current editing context. On the other hand, I do not expect that an OLE object will have any ability to actively participate in the undo process, which forces implementation back to the container (or you simply state that changes made to an OLE object internally are not undoable). For some reason, I keep thinking about the implications of a linked sheet in a Calc document. I think that editing of OLE objects (and linked sheets are just a variant of them) should stay as they are: while you are editing the object, you might be able to undo parts of the editing, but after leaving the OLE object all changes made in this session can only be undone as a whole. A new API can't remove the intrinsic limitations of this concept. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] DocumentLoader memory leaking on cleanup
On 10/26/2010 05:26 PM, Chris Rider wrote: As you can tell from the log file, the close method is being called, but not the dispose. Do I need to dispose also? Couldn't really find enough documentation to figure out *exactly* what those two methods entail. I kind of assumed it was something like the difference between clearing the objects memory or not. No, it a component supports XCloseable, you must call close(), otherwise dispose(). As close() will call dispose() internally, all you can get from an explicit dispose() call is a DisposedException. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: Attempt for an UNO Undo API
On 10/18/2010 05:16 PM, Malte Timmermann wrote: Or implementations w/o support for ref counting: For example, each EditEngine Undo action needs to have an EditEngine*. And EditEngines in OOo are destroyed and re-created quite frequently. Maybe using an own Undo manager for the EditEngine is wrong. When we implemented Notes2, I finally ended up with letting the container (Writer) tracking the changes, I didn't create an additional undo manager for the note(s). That means, each time when an undo entry shall be created, the Writer just copies the content of the outliner object inside the note. For more complicated cases this could be improved by a better encapsulation of what needs to be copied by providing suitable methods in the Outliner class. This way we got an Undo that is not prone to crashes and that doesn't depend on whether the user is editing the note or the text of the document. It also appeared that giving access to all entries of the undo stack while editing in a note doesn't create a problem if the implementation of the notes view is aware of sudden destruction (something that IMHO is necessary anyway). I think that we could apply this idea to drawing objects also. For OLE objects OTOH this probably wouldn't help as copying the whole object each time it changes surely would be too much. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] DocumentLoader memory leaking on cleanup
On 10/25/2010 07:10 PM, Chris Rider wrote: We are using DocumentLoader to manage the opening of PowerPoint files, and have recently discovered what appears to be a memory leak. As a quick background, these are self-advancing presentations, created using Microsoft by the end-user, who then uses our product (CentOS based) to display the files. When the cleanup routine is called, it appears to do its thing, but a bit of time later, the machine is almost frozen from all of its memory being used up... and after taking a look at the processes on the machine, we tracked it back to this. Below is from our log file... It looks like it reaches the end of the slideshow (event OnEndPresentation) and fires the Cleanup routine... but is it working past that point? Appears to not be. Are there any known issues with this sort of thing? Anyone else seeing this? Thanks! Chris 1288025660 : pid: 6935 - Acquiring lock... 1288025660 : pid: 6935 - Lock acquired! 1288025660 : pid: 6935 - Connected successfully to the office 1288025660 : pid: 6935 - XComponentloader successfully instantiated 1288025660 : pid: 6935 - argv[1]=/home/silentm/public_html/multimedia/951918099.Clarian.ppt 1288025660 : pid: 6935 - Document: file:///home/silentm/public_html/multimedia/951918099.Clarian.ppt 1288025661 : pid: 6935 - Starting Presentation... 1288025661 : pid: 6935 - Presentation Started! 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Releasing lock... 1288025661 : pid: 6935 - Lock released! 1288025661 : pid: 6935 - Wait for end! 1288025661 : pid: 6935 - Event : OnUnfocus received 1288025661 : pid: 6935 - Event : OnStartPresentation received 1288025661 : pid: 6935 - Event : OnFocus received 1288025661 : pid: 6935 - Event : OnLoad received 1288025662 : pid: 6935 - Event : OnEndPresentation received 1288025662 : pid: 6935 - Ending! 1288025662 : pid: 6935 - Event : OnViewClosed received 1288025662 : pid: 6935 - Event : OnUnfocus received 1288025664 : pid: 6935 - Cleanup 1288025664 : pid: 6935 - Cleanup - close - dispose I don't know how you created your logs, but at least in this log I don't see traces of the document being closed (Event OnClose, disposing etc.). But maybe that's part of the last line. Besides that, the document being closed does not mean that it is removed from memory. It's possible that it is still referenced somewhere and so the object is not destroyed. I think that eating up the memory completely - as you described it - would require thousands of such dangling references, but you never know. So look for references to documents (models) in your code. In case your application is implemented in Java, don't rely on the garbage collection doing the work for you, it might kick in just too late. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/22/2010 09:01 PM, Frank Schönheit wrote: As a sketch for the later evolution, we think that the XUndoManagerSupplier comes handy here: The chart model would be such a supplier, and for the moment, it would return an own, model-local instance of the XUndoManager. The later extension would be to let it provide the XUndoManager of the embedding document. In theory, this should be completely transparent to the client, which would simply add its actions to another instance, without actually noticing it. In practice, the concrete XUndoAction implementations of course might need to be adjusted (what if you do changes to the chart, then delete the chart, then do Undo multiple times? The chart Undo actions might have a reference to an outdated chart model then.). Also, you would not want to provide, in the menu/toolbox, Undo actions of the embedding document while the Chart is activated. I'm still worried about the problem I foresee, but we can postpone that until things get more concrete. Regardless of this, we agreed that in this first step, we will migrate Chart's XUndoManager to the new one, laying a common ground in all applications this way, which will also be prepared for the above-mentioned changes. Ciao Frank PS: If only a Writer developer could lend me a hand for implementing the new ::svl::IUndoManager interface on top of Writer's own home-grown Undo implementation, the whole thing would be nearly finished :) Sure. :-) As promised, we will do our very best. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/22/2010 09:07 PM, Frank Schönheit wrote: Hi Mathias, I think the Chart does qualify for all those Usage scenarios. Changes in Calc can lead to changes within the Chart that should be offered as one UNDO action together. Further the changes made within the Chart should be visible in the global UNDO stack also. I'm not sure if that is a good idea. IMHO an undo action only should record direct actions in the document core of the undo provider. If this action causes changes elsewhere (e.g. by a listener mechanism), they should not be recorded as it can be assumed that the opposite change in the core (when the undo action is executed) will cause the appropriate change in the listening component also. Well, one scenario Ingrid and I discussed here is the deletion of rows/columns which are part of a source range for a chart. If this is undone, the best chart can currently notice is the insertion of a row/column. Whether or not this column was part of the source range is not part of the broadcast event - not much of a chance for Chart to find out. This implies that chart source range handling/undo should be done in Calc. On the other hand, this means Calc (or any application embedding charts) needs to know pretty much details about Chart's handling of data source ranges - imagine all the different chart types, and the degrees of freedom you have for their defining their data sources. Which means that extensions to the Chart core might require extensions to the core of the embedding documents - not really desirable. Those problems are probably solvable (and as said, we don't aim for those solutions for 1.0), but I am not convinced it is as easy as saying undoing an instigating change will automatically undo the resulting change - simply because currently, listeners might not always transport enough information for this. Let me put it that way: undo actions should only record direct actions. If changes in a component cause indirect changes elsewhere (e.g. by a listener connection), these changes should not be recorded in an undo action. Or the other way around: if actions in a sub component are recorded, they should be made directly by the super component. Otherwise you will get ugly code that always needs to know whether it is currently in an undo action or not. This code is very prone to regressions. Been there, done that, got to hate that. If the information provided to a listener is not sufficient, that should be changed. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Moin, sorry for being late. There have been a lot of mails to read in the last days. ;-) On 15.10.2010 20:23, Ingrid Halama wrote: I think the Chart does qualify for all those Usage scenarios. Changes in Calc can lead to changes within the Chart that should be offered as one UNDO action together. Further the changes made within the Chart should be visible in the global UNDO stack also. I'm not sure if that is a good idea. IMHO an undo action only should record direct actions in the document core of the undo provider. If this action causes changes elsewhere (e.g. by a listener mechanism), they should not be recorded as it can be assumed that the opposite change in the core (when the undo action is executed) will cause the appropriate change in the listening component also. Doing that differently will create such a code mess we have in the Writer core when it comes to Undo. :-) So the Chart would be an ideal candidate for a test implementation. I would like to join your efforts, if time fits. :-) There might be some extra complications to expect regarding the OLE inplace editing mode and the OLE swapping mechanism. That could become ugly, maybe ... . Indeed, chart actions that are recorded while the component is activated, are dangerous, as executing them later when the component is no longer active and perhaps even disposed will at least make the implementation rather tricky - if not even a disaster. As the other nice improvements we can bring to extension developers should be ready rather today than tomorrow, I would opt for a simple implementation that does not try to use combined undo stacks from different components. Being able to group actions caused by API calls that - from the POV of the extension - should be one combined entry in the undo stack is worth the implementation already. Whether we want to use that for combined undo stacks also is something we should decide for version 2.0 of the implementation (it wouldn't influence the API, IMHO). Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Questions ad XPrintable.print(properties) ...
On 14.07.2010 11:37, Rony G. Flatscher wrote: Hi there, so far I have been under the assumptions that the list of properties that one is able to supply to the XPrintable.print(...) method matches the options that can be given in the GUI of the respective component type. This way each document type would have a common set of properties, but also additional print properties it would honor. Then, that's what I was expecting, the task would be to find the documentation of the print properties of the respective document type. Now, trying to print a presentation and taking advantage of its GUI defined print properties programmatically (i.e. print the presentation in form of handouts, where each page would depict a programmatically defined number of slides per printed page) seems to not be possible. At least I cannot find any documentation or working examples for this. So, two questions: * Is it intended that the print properties for XPrintable.print(...) allow for defining all print options that the document type's GUI allows for? There are two different kinds of such properties - the print options (those are passe to the print call) and the print settings (that are general printer options set with a setPrinter call). The generic services are defined in the css.view package. At least that was the plan. Reality obviously is different. To my knowledge none of our applications have own print options (though the API would allow to treat it as you described it). At least there is no documentation for additional print options, so basically they don't exist. ;-) Writer has its own PrintSettings Service (css.text.PrintSettings) defined, but I failed to find comparable service definitions for the other applications. * How can one exploit the GUI print options for presentations (simpress components) such, that one can programmatically print handouts with multiple slides per printed page? It seems that the Impress developers didn't implement that. I also couldn't find a setPrinter() implementation in Writer, though - as mentioned above - there is a service definition for PrinterSettings in the css.text IDL. It seems that printer settings are set through the DocumentSettings services of the applications. I discovered the text PrinterSettings properties in the css.text.DocumentSettings and, amongst others, a IsPrintHandout property in the css.presentation.DocumentSettings. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] XSlideshowListener dispose()
Hi Cameron,, I had a short look on the SlideShow code. It's quite strange, the class that allows to add and remove listeners is not the same as the class that sends the disposing events. IMHO this cant work as the event source in the disposing() call won't match the object that was used for registration. I have cc'ed the Impress developers, maybe they can shed some light on this. Regards, Mathias On 06/28/2010 05:49 PM, Cameron Flint wrote: Hello Mathias, Thanks for the response. I've double-checked that: - registration of the slideshow listener is successful (I receive all other events as expected), - my listener derives only from the XSlideshowListener class, and - at no other point in my code do I remove the listener. Here are a few more details on the problem: 1. I do not receive a dispose() call both for the case that I have manually called XPresentation.end() (before the slide show is complete), and the case that the slideshow exits normally. 2. Same goes for in-window as well as full-screen presentations. 3. When I attempt to de-register the listener, the actual error preventing me from doing so is that XPresentation2.getController() returns null. Of course, this only occurs when the slideshow has already been disposed by the third party. 4. I am developing on Symphony 3 beta 3, which I am fairly certain uses OO 310m11(Build:9399) (at least, that is the version in its unoil.jar/MANIFEST.MF). I should mention that this issue is not necessarily an impediment, as I've long-since simply removed the de-register without any observable side effects. It would be much more satisfying, however, to get to the root issue. :) -- Cameron On Fri, Jun 25, 2010 at 3:29 AM, Mathias Bauernospamfor...@gmx.de wrote: Hi Cameron, On 06/23/2010 08:47 PM, Cameron Flint wrote: Hello, I have a class which implements XSlideshowListener, and attempts to override the disposing() (from the XEventListener superclass) in order to set a flag to ensure that I don't try to remove it a second time if the target slideshow has already been disposed. However, I never seem to get this call. Consequently, my cleanup routine which calls XSlideShowController.removeSlideshowListener() receives a NullPointerException since the slideshow has already terminated, unbeknown to my listener. It would seem that a listener registered on a slideshow should be notified when that slideshow disposes, or am I mistaken? No, you are right. When an object is disposed, it will notify all registered event listeners. So if an object obviously was disposed, but you didn't receive a notification, the reasons that I could imagine are - your registration failed or was not carried out at all - your class derives from another one that implements the disposing() method and you accidently used a wrong method declaration - your listener was removed already before the slide show was disposed Did you receive any slide show events? Have you made shure that the listener wasn't removed before the slide show was disposed? Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org -- 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Diabling the F1 Keyboard Shortcut
On 06/29/2010 01:33 PM, Andrew Harmel-Law wrote: Hi there, I am developing an applet which embeds OpenOffice 3.2 using the OfficeBean to allow users to redact MSWord documents. To do this I load a read only document and disable all functionality apart from three buttons which i have implemented: one to highlight selected text with a strikethrough and make the test red (mark), one to remove this marking, and the third to turn the marking into ~ characters with a black background (redact). I have been able to to disable all the contectual menus, buttons bars and menus and keyboard shortcuts (with some help from the forum: http://www.oooforum.org/forum/viewtopic.phtml?p=380030#380030) but I am having a problem with the final hurdle; turning off the F1 shortcut to display the OOo Help. Last time I checked that was hard code in VCL. Looks as if this needs some extra code in OOo to make that possible. We could perhaps implement something in sfx2 where the final Help class is implemented. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Tabs in openoffice extension dialogs
On 06/24/2010 06:48 AM, Akila Wajirasena wrote: Thanks Cor, By the way is there any plan to add this in the future? Yes. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] XSlideshowListener dispose()
Hi Cameron, On 06/23/2010 08:47 PM, Cameron Flint wrote: Hello, I have a class which implements XSlideshowListener, and attempts to override the disposing() (from the XEventListener superclass) in order to set a flag to ensure that I don't try to remove it a second time if the target slideshow has already been disposed. However, I never seem to get this call. Consequently, my cleanup routine which calls XSlideShowController.removeSlideshowListener() receives a NullPointerException since the slideshow has already terminated, unbeknown to my listener. It would seem that a listener registered on a slideshow should be notified when that slideshow disposes, or am I mistaken? No, you are right. When an object is disposed, it will notify all registered event listeners. So if an object obviously was disposed, but you didn't receive a notification, the reasons that I could imagine are - your registration failed or was not carried out at all - your class derives from another one that implements the disposing() method and you accidently used a wrong method declaration - your listener was removed already before the slide show was disposed Did you receive any slide show events? Have you made shure that the listener wasn't removed before the slide show was disposed? Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Compiler for MS Windows
On 16.06.2010 13:44, Patrick Bernard wrote: Hi Patrick, Le mercredi 16 juin 2010 à 12:14 +0200, Patrick Bernard a écrit : I'm writing an extension in C++ and I'm going to distribute a version for Windows. I would like to know what compiler I can use. I know I can use MS Visual Studio, but it costs 1,200 euro for the MSDN version (900 euro for the bare version). Is there a cheaper solution ? Did you try Mingw and cygwin? Regards, No I didn't. Is it possible to use MinGW to compile C++ extensions that are to be used with official releases of OpenOffice.org ? I don't think so. You should use the Microsoft VC++ Express Compiler. Or Java. :-) Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Compiler for MS Windows
On 18.06.2010 21:44, Christian Lohmaier wrote: Hi Patrick, On Fri, Jun 18, 2010 at 4:49 PM, Patrick Bernardpatr...@kilargo.com wrote: Is C++ recommended for extensions ? Can it lead to problems ? It leads to the problem that you need to compile for all platforms separately. Also linux-Distributions compile with system-stlport and not agains the version that comes with OOo sources. So c++ extensions are incompatible between vanilla and distro-version (unless distribution also provides OOo's version) I'd go for java (but mainly because I know java better :-)) Only drawback of java is rather slow start of the JVM - but that's not a problem if the JVM is loaded anyway. On hardware of this century and with the lastest JVMs this shouldn't be problem. If you don't have a problem with Java (technically or ideologically wise), go for it! It's the best programming language for OOo extensions that should run on several platforms. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Sending email to multiple recipients
Hi, Fernand Vanrie wrote: Paolo , Andrew, all Can i have hope to set also the body of a email message ? This is not possible by intent, as (at least to my knowledge) the mailto:; protocol we are using for the implementation of this service on most platforms (at the end, it's a simple mail service) does not allow to pass a body text to the mail client. It could work with the MAPI based implementation on Windows, but if you write platform specific code, you don't need a platform independent API for that. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Questions about the service com.sun.star.frame.GlobalEventBroadcaster
Patrick Bernard wrote: Hello Normal is that your instance will live until references to it have been removed. There could be other references elsewhere that you didn't mention. In case your object is implemented in Java, it's possible that you have to wait until the garbage collection kicks in. I don't know (I'm no Java expert) if this probably never happens in case the VM shuts down before the regular garbage collection has been executed. When the object is created, it is directly passed to the addEventListener function and no reference to it is kept in my extension. Besides, the extension is completely implemented in C++. So it might be that the GlobalEventBroadcaster is not destroyed also. But to verify this it needed some investigation. The interface was set to deprecated because we wanted to fix a name clash. Unfortunately that never happened. So it's time to think about that and either revert that state of that interface or finally fix the problem. I have to investigate that before I can answer you question. I know that unpublished interfaces or service are not yet stable and can be removed, but I don't know how this happens. Can this removal happen in a minor update of OpenOffice.org ? When an unpublished interface/service is replaced by another one, how long is it kept, so that code using it can be modified ? Theoretically an unpublished interface can be changed at any time, in any release. So it depends on the individual case. As I wrote, I have to investigate the GlobalEventBroadcaster case before I can tell what will happen here. A short look tells me that this service declaration is old style, so in practice nothing more than documentation. I assume that the name won't change, but the supported interfaces. I could imagine that the deprecated css.document.XEventBroadcaster interface might be replaced by css.document.XDocumentEventBroadcaster. I don't think that this change will be done in a minor version, perhaps 4.0 would be a good release for that change. OTOH it's still possible that we don't find the time to change our code for that and so it might remain for another few releases. Regards, Mathias - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Questions about the service com.sun.star.frame.GlobalEventBroadcaster
Patrick Bernard wrote: Hello When OpenOffice.org starts, my extension registers an object with the service com.sun.star.frame.GlobalEventBroadcaster using the addEventListener function of the com::sun::star::document::XEventBroadcaster interface. When I quit OpenOffice.org, the registered object isn't destroyed. Is it normal ? Normal is that your instance will live until references to it have been removed. There could be other references elsewhere that you didn't mention. In case your object is implemented in Java, it's possible that you have to wait until the garbage collection kicks in. I don't know (I'm no Java expert) if this probably never happens in case the VM shuts down before the regular garbage collection has been executed. Moreover, the service com.sun.star.frame.GlobalEventBroadcaster is unpublished and the interface com::sun::star::document::XEventBroadcaster is deprecated. Is there a service I could use instead that offers the same functionality and that is more reliable ? If not, how can I emulate it ? The interface was set to deprecated because we wanted to fix a name clash. Unfortunately that never happened. So it's time to think about that and either revert that state of that interface or finally fix the problem. I have to investigate that before I can answer you question. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Windows and Linux portability queries
Madhur Kashyap wrote: Mathias and Irne Thanks for your responses. The home folder concept is useful for setting a current working directory (linux). Although my purpose was little different. I found that help in Andrew Pitonyak's quick reference. OO Basic supports an API getPathSeparator() which returns / or \ depending upon what OS is used. So, my purpose has been temporarily solved. That's completely unnecessary if you use URLs instead of path names. As most API calls in OOo use URLs anyway you also save your don't need to convert your file names when you want to use them in API calls. The biggest problem still is sRootDir. You have to know this and so your idea to write OS agnostic code is only possible with using a root dir that is accessible through one of OOo's path variable, like e.g. the HOME folder. If you are not able to identify the operating system you are working on, how can you guess sRootDir in the correct notation? OTOH, if you know sRootDir, you also know at least if your OS has a Windows type or a Unix type file name notation. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] deploying images in extensions, to be loaded without extension code
Frank Schoenheit, Sun Microsystems Germany wrote: Would should think about a further macro that expands to the extension root directory. If noone vetoes this for some good reasons ;), I'll give the UCP a try. No veto, but IMHO that's breaking the butterfly on the wheel. Jürgen's proposal definitely is something to think about. This is not the first time that extension developers asked for access to the extension root directory. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] deploying images in extensions, to be loaded without extension code
Frank Schoenheit, Sun Microsystems Germany wrote: Hi Paolo, Why not the %origin% placeholder? I just noticed that the graphic provider can handle demacrofyed urls like this one: vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/sJYsUf_/MyExtension.oxt/icons/lightbulb.jpg because you would need to know, at time of creation of your extension, the sJYsUf_ part of the path, which is impossible. Okay, with the brand-new XDeploymentHook interface, you could probably add a hook which is executed when the extension is deployed, and updates the configuration with the proper URL. Possible, but still pretty ugly, and a workaround, not a solution. Sure? IIRC there was a way to have %origin% as a placeholder in entries of xcu files that will be expanded at deployment time or can be resolved at runtime to give you that path. I used that technique in several extensions, without being forced to any such hacks as deployment hooks. A quick search showed me that this technique is still used, e.g. in the presentation minimizer extension. The code in this extension using the images referencing %origin% should show you whether the expansion happens at runtime or already at deployment time (IIRC it was the latter). Regards, Mathias - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] EOF exception when exectuing code the second time
Hi Steffen, sorry, I haven't any idea what might cause the problem. Perhaps you can attach a debugger to the server and get a call stack. Regards, Mathias steb wrote: Hi Mathias, most of the time there is no real printing involved. Instead OO is opend locally with the generated document loaded. But the error occurs way before that. The generated document should be stored with the XStorable.storeAsURL() method before displaying to the user, but it seems like an error occurs on random occassions because a file with the specified name is created but it contains no data. After that the DisposedException occurs but without XStorable.storeAsURL() throwing an IOException which I try to catch. Regards, Steffen I'm not sure in which call you got the DisposedException. You mentioned printing. Does it mean that the document is printed and later gets closed? Regards, Mathias - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org -- 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] EOF exception when exectuing code the second time
Steffen Boersig wrote: Sorry for the previous mail, just ignore it. I missclicked :/ Hi, I encountered a problem today while executing my code several times. I'm connecting to an remote OOServer which is started in invisible and headless mode. From a GUI application the user can execute a printing job to create an openoffice(writer) document filled with the data he selected. The code for this works fine, at least most of the time. Now and then I get the following error ( *** is manually inserted for privacy reasons): java.io.IOException: com.sun.star.io.IOException: EOF reached - socket,host=openoffice,port=8100,localHost=***,localPort=39629,peerHost=openoffice,peerPort=8100 com.sun.star.lang.DisposedException: java.io.IOException: com.sun.star.io.IOException: EOF reached - socket,host=openoffice,port=8100,localHost=***,localPort=39629,peerHost=openoffice,peerPort=8100 at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.run(java_remote_bridge.java:176) I'm not sure in which call you got the DisposedException. You mentioned printing. Does it mean that the document is printed and later gets closed? Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Add Bulleting and Numbering style.
Hi, Mahesh Reddy wrote: Hi, I am trying to create Numbering and Bulleting styles and I am using OO 1.1 SDK. I am using the following link as a reference http://wiki.services.openoffice.org/w/index.php?title=Documentation/DevGuide/Text/Line_Numbering_and_Outline_Numbering So I tried to create an Instance of Paragraph with xMultiServiceFactory with the param com.sun.star.text.Paragraph(as per the UNO api documentation), but I get a Service Not Available Exception. So I tried to List all the Services provided by xMultiServiceFactory and I got the following list. Please note that com.sun.star.text.Paragraph is not listed in the available services. (snip) The provided list lets me think that you are working on a presentation document, not a text document, while the documentation you are using refers to the latter. AFAIK a presentation document is not able to create a text paragraph through its XMultiServiceFactory interface. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: IOException OOo 3.1.1
Petteri Larjos wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I managed to debug my problem to XCloseable.close() function.
Reference XCloseable xCloseable( xComponent, UNO_QUERY );
if ( xCloseable.is() ) {
xCloseable-close( sal_True );
}
This makes my function to throw when it comes out from try block. If I
comment 'xCloseable-close' then everythin works and my function newer
throw. I also got it working by addin sleep call after 'xCloseable-close':
Reference XCloseable xCloseable( xComponent, UNO_QUERY );
if ( xCloseable.is() ) {
xCloseable-close( sal_True );
sleep(1); // works but too slow
}
What this means? BTW 'xComponent-dispose();' causes throwing as well. This
never happened with OOo3.0.
The possible errors mentioned by Stephan and Mikhail put aside, can you
tell us what kind of exception is thrown here? Is it a
com::sun::star::util::CloseVetoException?
Calling close always can throw a css::util::CloseVetoException in case
the document can't be closed ATM, this is not an error. So just catch it
and go ahead. In case you passed true as parameter, the document will
be closed later as soon as the reason for the exception has gone away.
Regards,
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...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] loadcomponentfromrul with whitespace bug?
Hi, Daniel Käfer wrote: Hello, I try to open a document. In the Path are whitespace. I replace the whitespace with '%20', for example file:///C:/Dokumente%20und%20Einstellungen/twc/TWC/Documents/1258539328921.odt. If the ReadOnly property is true or the property is not set, it works well. If the property ist false a IllegalArgumentException is throw. are you sure that you have write access to the file? Can you open it for editing with the same instance of OOo with the same OOo user profile that you are using for your loadComponentFromURL call? The complete call is: PropertyValue[] properties = new PropertyValue[1]; properties[0] = new PropertyValue(); properties[0].Name = Hidden; properties[0].Value = Boolean.valueOf(false); Are you talking about ReadOnly or about Hidden? Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] open document hidden bug?
Carsten Driesner wrote: Daniel Käfer wrote: Hello, I try to open a document hidden. Sometimes it works, the other time the documents open visible. My source code is: [code] this.xComponent = xComponentLoader.loadComponentFromURL( filename, // File folder and name _default, // Open in existing blank frame... FrameSearchFlag.CREATE, // ... if none found, create one. this.documentProperties);// Special document properties [/code] The Property 'Hidden' is alaway true (java.lang.Boolean). If I replace '_default' with '_blank', it work perfect. Is this a bug or a feature? Hi Daniel, Could you please tell me more about the context where your code runs. Especially when you can see that it doesn't work. Currently it looks like a bug, but without more information this is hard to confirm. I would like to debug your scenario, but therefore I need more information. IIRC it is by intent to ignore the hidden property for the _default target as there are situations where it doesn't work or creates surprising effects (like letting the current document window vanish without a poof ;-)). Using _default puts the document window under user control - this is not in line with the idea of a hidden window. Perhaps we should document that. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Openning Open Office Document thru Internet Explorer
Rafelito Comendador wrote: Hi, I browsed thru your website and found out about this SDK thing, I would like to inquire about my issue with open office documents. heres the scenario, I have an ASP.NET / VB 2.0 web application, wherein i have file attachments in Open Office writer formats. The idea is when a selected attachment is opened from the website, it will be opened via internet explorer and not by open office itself to elliminate the save, save as, export to PDF , print and copy, and the open offices toolbar should be invisible and the document readonly. However, eventhough i have set the newly opened windows style properties to hide all toolbars and menubars, open offices toolbar is very much present. the Save , export to PDF , print , mouse right click and select all text are possible which are supposed to be all hidden and not active. I think IE is just executing the open office application thru it. Is there a way that I can do this scenario via IE. I have thought of making a webcontrol that will open the document inside IE but unfortunately i cant find any .net control or API to call that will serve the purpose, are there any in the first place? ex, var style = style: toolbar=no,location=no,directories=no, + status=no,menubar=no,scrollbars=yes, + resizable=yes,copyhistory=no; window.open( c:\myDoc.odt,'', style); OOo comes with an ActiveX Control that can be used to open documents in an OOo window that is embedded in the IE Window. I'm not sure if you are using it. This window still has a toolbar, but by providing a configuration setting in the installed OOo application you can configure it to hide this toolbar. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Long time operations - What's the best way?
Perry Werneck wrote: Hi, I'm not sure if it's the right list to ask for help but I'm having a problem to implement a uno object on C++ and I'm need some help! The problem: I'm working in an OXT module allowing a starbasic script to get informations from a 3270 host using tn3270e; the service itself is ok and all the network stuff is running in a separate thread but, some part of the code needs to wait for any kynd of host response; when I do this all the OpenOffice.org ui hangs. I'm looking for some function cal to keep the UI responsive even if the starbasic script is waiting; something like the gtk_main_iteration() call. Is it possible in uno code? How can I do this? If you want to execute code outside of the GUI thread you have to implement it in Java or C++. OOo Basic does not have support for threads. The wait call mentioned by Andreas is a dirty workaround but perhaps it works for you. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Multithread question
Hi Oscar, Oscar Picasso wrote: Hi Mathias, 3- What is the UNO service that can be called with an object receiving a callback? Have you any pointer about it (documentation, sample code etc.)? I'll dig that out. Thanks for your help. As I need anyway to use a java client, this UNO service does not seem to help. I am still curious but I am starting another thread about how to use OO as a local server in most *reliable* way even if doing so implies that the client access the server in a single thread. Sorry, I forgot about your question. :-[ Working in the main thread of OOo will increase stability in every case. Here's how to do it: use com.sun.star.awt.AsyncCallback service to get a callback from the office main thread. You will need an own object implementing the com::sun::star::awt::XCallback interface. This object will be provided to the om::sun::star::awt::XRequestCallback::addCallback() call. How does it work? When a remote application calls a UNO API method through the remote bridge, a new thread is created in OOo that executes the API call. Both threads (the thread on OOo side and the thread on remote side) are assigned to each other. As now we have at least two threads running in OOo that can call into the application code, race conditions caused by some bugs here and there are possible. If you use the AyncCallback service, it will call the remote application from inside the main thread and this will create another thread on the remote application side that is assigned to OOo's main thread. Every call done in this thread will not create multi threading problems for OOo's own processing. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Idiomatic way to avoid or recover from client crashes?
Hi Oscar, Oscar Picasso wrote: Hi, I am interested to know if there is an idiomatic way to avoid or recover from crashes in the following use case. The program opens an OpenOffice writer document with a custom XInputStream defined below. It changes some user fields and bookmarks contents and save the document as pdf. For saving it uses the XStorable.storeUrl method and a custom XOutputStream, also defined below. When doing the stress test below, it always crashes after having looped around 8500 times with the exception: com.sun.star.lang.IllegalArgumentException: URL seems to be an unsupported one I have put a comment on the code above the line where the program itself crashes. First of all: what you have found is not a crash, because: The OpenOffice instance is still up and running though. 1- Is there something wrong in the code that causes the crash? Maybe some wrong parameter? Something else that needs to be closed or disposed? 2- If not is there a proper way to recover from the crash and retry the operation? What are usually the recoverable exceptions and which cleanup should be done? Maybe we need to reload / refresh / recreate some object for a safe recovery? Any idea? PS.: I find the URL seems to be an unsupported one message quite puzzling since the URL that is used is always private:stream. So why do this URL become unsupported after it has been used for about 8500 times? If a private:stream URL is detected, OOo tries to retrieve the InputStream from the MediaDescriptor. Only if this fails the Unsupported Exception is thrown. The same may happen if no known content type can be detected from the stream. I can't see how this could happen in your code as you seem to use the same file all the time. You could retry the failed call with the same arguments and this time debug the code in OOo to see why it failed. You will need to have the framework libraries and the filterconfig library (in module filter) with debug information. BTW: you shouldn't close the document by calling dispose(), please use close(True) instead. But be prepared to catch CloseVetoExceptions then. In case you get such exceptions that could be a sign that OOo can't close the loaded document and perhaps has a resource problem. Maybe either your application or OOo runs out of file handles?! Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Any way to turn off error reporting in openoffice?
Wei Min Teo wrote:
Thanks. However, won't setting -norestore cause openoffice not to
automatically start up after the crash?
Yes, that's a side effect of this. But for automation purposes I don't
see a problem here as you must re-connect anyway.
Another side effect is that autosave of documents is disable for this
session (it doesn't make sense to store recovery information that is not
used afterwards).
Can I pass this parameter in programatically instead of running via
commandline? I am presently using just the simple bootstrap function for c++.
No. You can do it differently:
create the service com.sun.star.frame.AutoRecovery
It has an interface XDispatchProvider and you can dispatch the command
vnd.sun.star.autorecovery:/disableRecovery to it. Here's some C++ code
for it:
try
{
css::uno::Reference css::frame::XDispatch xRecovery(
myServiceFactory-createInstance(
OUSTRING(RTL_CONSTASCII_USTRINGPARAM(com.sun.star.frame.AutoRecovery)) ),
css::uno::UNO_QUERY_THROW );
css::uno::Reference css::util::XURLTransformer xParser(
myFactory-createInstance(
OUSTRING(RTL_CONSTASCII_USTRINGPARAM(com.sun.star.util.URLTransformer)) ),
css::uno::UNO_QUERY_THROW );
css::util::URL aCmd;
aCmd.Complete =
::rtl::OUString::createFromAscii(vnd.sun.star.autorecovery:/disableRecovery);
xParser-parseStrict(aCmd);
xRecovery-dispatch(aCmd, css::uno::Sequence
css::beans::PropertyValue ());
}
catch(const css::uno::Exception e)
{
}
myServiceFactory is the factory you can get from the ComponentFactory
you have bootstrapped. Of course you can also use the ComponentFactory
directly, but I didn't find the syntax for its createComponent method in
my brain. ;-)
HTH,
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...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Any way to turn off error reporting in openoffice?
Wei Min Teo wrote: Hi all, I've had some error opening the following file: XL8GALRY.XLS (some file in MS office installation files). Openoffice tries to open it and i see a progress bar telling me it's calculating but it gets stuck halfway and crashes openoffice. It then brings up a recovery file screen and prompts me to report the error. My questions are: 1) Any idea why i have problems opening the file? (Initially i suspected that it runs some macro but i passed in NEVER EXECUTE in the media description) 2) Is there anyway to catch this problem or turn off error reporting so that i can continue with automation of openoffice? You can switch off the file recovery process (IIRC by passing --norestore on the command line), but of course the crash caused by this file will happen also. Perhaps you can create a bug report and attach your file so that the Calc developers can reproduce the problem easily. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Multithread question
Hi Oscar, Oscar Picasso wrote: Hi Mathias, 1- The client is written in java so I guess I could run into the garbage collection problems you mentioned. Correct? Yes. 2- If so is there a mean to prevent to run into those problems while still using the UNO service you mentioned. I thought about simply calling OO via a synchronized method in my client. Any idea if it it would be the correct approach (well in that case I wouldn't even use OO multithread capabilities)? Or maybe a better one? If your problem is the Garbage Collection, this wouldn't help. But if not, this could solve your problem. 3- What is the UNO service that can be called with an object receiving a callback? Have you any pointer about it (documentation, sample code etc.)? I'll dig that out. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] adding a method to a published interface
Thorsten Behrens wrote: Hi Malte, you wrote: I think it's better to break AWT API compatibility once, instead of many times in many releases. Which really also might turn out as never - the unlikeliness of the big-bang-change to happen was already pointed out (since when are we talking about awt redesign? I personally think it's 8 years now). If it doesn't happen, the pain to have them obviously is not big enough. If it hurts you that much, go on and make the change. The change basically would be to replace every setSomething() call by an attribute in that interface and to add the (in most cases) trivial implementation everywhere. All in all a few days of work for an experienced developer. In that case I would like to see some more from Carsten's suggestions for awt changes becoming implemented (as much as we can add without holding back the add the get methods task force). 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] adding a method to a published interface
Frank Schönheit - Sun Microsystems Germany wrote: Is there a good reason to not do the changes incrementally? Yes, there is a very good reason. Every incompatible change causes pain, no matter how many individual changes it contains. So putting as much changes together as possible into one change is better. In case you don't see it: the biggest pain is caused by the fact that we have to declare every extension as incompatible in every release where at least one incompatible change has been made, as there is no way to find out which types an extension uses (and it may be exactly the one you have changed). So your plea for incremental incompatible changes even in minor releases basically destroys the idea of extensions more or less completely, as their life cycle effectively would be limited to a maximum of six months. In fact it's even less than that as you would gain 6 months only if the extension was released at the same time as the office version it is compatible to. I don't see a big problem with having an XView2. These are just names, nothing more. The code using XView2 wouldn't be better if it used XView instead. In case your esthetical feelings were hurt by the 2 at the end, a simple macro #define XVIEW XView2 or similar would solve this at least for your code without hurting others by an incompatible change. There is no advantage in the incompatible change except that it could be seen as a little bit less ugly (though I even don't see that). That's not the kind of pain that I would see as a justification for an incompatible change. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: [interface-discuss] adding a method to a published interface
Juergen Schmidt wrote: The given XView interface is effectively *only* implemented in the toolkit module, and chances that it's implemented outside the OOo code base are rather low (since all the code around it does not really allow for pure UNO components outside the OOo code, but that's another topic). So, I'd say we're on the safe side here. i agree that we are probably safe here. But it shows also that a general rule is or can be problematic. Whereas a change like yours is probably harmless other changes of the same category can break many external solutions depending on the usage of the changed interface. That is the reason why we should discuss the changes in public and find a common agreement for the proposed changes... It's my experience that establishing roles with too much preconditions will cause endless discussions, not in every case, but in many. So I would prefer to treat every incompatible change in the same way. I could accept to make one exception: if an API is not implemented or used in OOo at all we can safely assume that changing (or better: replacing) it will not cause problems in extensions or code working with OOo. But if an interface is implemented or used in OOo it's just wild guessing whether it is used somewhere else and leaves too much room for discussions. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] adding a method to a published interface
Frank Schönheit - Sun Microsystems Germany wrote: So, if this turns out to be too much effort (means I simply do not have/get the time for this), then I would still argue for a lot of small steps which actually happen, than a little big step which never happens at all. XView::getZoom is a problem I have *now*. Sorry, where is the problem? Does a 2 in an interface name let your code crash or create maintenance problems? Does it create bugs, make your program slower? I don't buy your argument that a 2 in an interface name makes our API less compelling. It didn't prevent millions of developers from using COM APIs on Windows and no serious developer will be held back by it in OOo. It would be embarrassing to have each and every interface in AWT doubled for the get methods, and I can see value in the complete overhaul, but I don't see an urgent need for changing this in a single interface. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] adding a method to a published interface
Frank Schönheit - Sun Microsystems Germany wrote: IRC, you already made another exception in another thread where we discussed that, namely you agreed that adding non-optional properties to published services should be allowed. Using your arguments from above, I could say that this shouldn't be allowed, as there could be extensions which implement this service, and thus we would need to invalidate all existing extensions if we ever add such a property. Of course this would be nonsense, as an educated guess would probably tell us that not a single extension in the world exists which implements this service. This is an insufficient comparison. I was talking about old style services and you should know that their specification has only documentary purpose. Adding a property here can't break existing code and by adding a since tag you can make clear for new code that it must be aware of older implementations not supporting it (means: plan for catching an exception). But anyway, if you feel the need to forbid that also, no problem. All in all, I am much less pessimistic than you are about the acceptance of such changes. And that's probably the central question, like with every change: Would it please more users than it would repel? In the concrete case, not repelling users is a matter of having control over what we do (instead of just allowing any kind of change for any release), and that's where we disagree: I think we *are* able to retain that control. So how do we proceed? Who's to finally decide that? Exactly this question is the reason why I want to have a black and white rule, and it should be simple to apply it. The best I can see so far is: as long as an interface is used or implemented inside OOo, it's possible that changing it can break code. Anything that can break existing code should be possible only in major releases and there should be a good, commonly accepted root cause for the change (changing a single interface just for language esthetical feelings IMHO isn't one of them). Otherwise we will always have lengthy discussions like this one. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Developing a tool to recognise MS Office file types ( .doc, .xls, .mdb, .ppt )
Professional wrote: Dear Sir/Madam, I am supposed to develop a tool which can identify the correct Microsoft Office File types (.doc, .xls, .mdb, .ppt). The tool will take an MS office file ( .doc, .xls, .mdb, .ppt) as input and will return the file type. OpenOffice opens the correct type of application for each of these MS office files so it means OpenOffice have some way to differenciate between MS office file types. Can you please help me with this problem? Any OpenOffice library which can be helpful to me? anything else you want suggest? OOo has a library (sot) that is able to load the OLE storage format. One of the sub streams in such a storage tells the format. Using the sot library of OOo standalone is not possible, you will need some others too. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Error Code 283 (Java)
Hi, this error code usually is returned if an operation was canceled or handled by the user. If it is used elsewhere, it's probably a bug. Handled means that an error box was shown to the user explaining the real error. Regards, Mathias Miguel Tablado wrote: Hello, I have had the same problem since the file path was wrong. And I found out there that the error was ERRCODE_IO_ABORT. Andreas Bröker wrote: Hello Laurent, yes - storeToURL. The code is ok. We only get the error on one machine. Regards Andreas -Ursprüngliche Nachricht- Von: Laurent Godard [mailto:lgod...@indesko.com] Gesendet: Donnerstag, 16. Februar 2006 15:56 An: dev@api.openoffice.org Betreff: Re: [api-dev] Error Code 283 (Java) Hi Andreas i try to store a writer document as pdf - but i get an exception with the error code 283. What does this mean ? a code snippet ? do you use storeToURL (and not stroreAsURL) method Laurent -- Laurent Godard lgod...@indesko.com - Ingénierie OpenOffice.org Indesko http://www.indesko.com Nuxeo CPS http://www.nuxeo.com - http://www.cps-project.org Livre Programmation OpenOffice.org, Eyrolles 2004 - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org -- 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] XMetadatable
muddybeemer wrote: Hello, I am not able to get an XMetadatable interface from XTextDocument or TextEmbeddedObject. UnoRuntime.queryInterface returns null. What OOO Writer components, if any, currently implement XMetadatable? I've searched extensively and found documentation on the rdf API, and how it is implemented in ODF, but no info about which components implement the interface. I'm using Openoffice 3.0.1 on Windows. I appreciate the help, This part of the API is work in progress. We hope to get the meta data support for textual content done in 3.2 (fingers crossed). It took much longer to implement that as expected because basically we had to make larger changes to our document core than we had planned. The good thing is that Michael Stahl, who is working on this, found and fixed several bugs in our current API implementation while doing the refactoring. :-) If you are interested in trying out the new API as beta tester once it is implemented, please watch our API announcements and the GullFOSS blog. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Macro ODB documents
Frank Schönheit - Sun Microsystems Germany wrote: Hi Mathias, This was one design decision we had to make when Base was created in the current form. Finally, the decision for SDI was because of technical constraints, since OOo doesn't have an infrastructure for MDI. Chosing SDI in favor of MDI was not because we didn't have an infrastructure for MDI (we could have created one, we already had two different ones in the past ;-)), it was done by intent. SDI enables better integration into the Desktop and into other applications. I beg to disagree. When we decided to promote Base to an own top-level application (this was back in 2.0 times), we considered SDI vs. MDI. And IIRC, the iTeam had a slight favor towards MDI - which for a document with sub components seems more natural, your arguments about desktop integration do not really hold here IMO. However, since the task itself was big enough, and at that time, even the SDI infrastructure - as far as UNO was concerned, and we deliberately decided to use the UNO and not the SFX framework - was not completely mature, we decided against MDI. AFAIR having MDI for Base while staying with SDI for other applications of OOo wasn't an option that had any chance to get implemented. If we wanted system MDI windows where available, that was even impossible. So the decision we had to make in every case was: should OOo as a whole use MDI or SDI. And in that context we always wanted to have SDI, for the reasons explained. Whether sfx was used or not is totally irrelevant in that regard. With sfx we could have used floating windows as child windows for the different parts of Base. IIRC we indeed discussed that and abandoned that idea for varous reasons, but that wasn't MDI, as floating windows have a different relationship to their application window as MDI windows have (e.g. wrt. focus treatment, toolbar and other tool windows handling). 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] How to reload current opened document via API
bvoll...@informatik.uni-bremen.de wrote: Quoting Mathias Bauer nospamfor...@gmx.de: bvoll...@informatik.uni-bremen.de wrote: Unfortunately the solution with .uno:Reload does not work anymore since OO.org 3.1 was released. Under Windows I cannot update the opened document externally because it is locked. I need a workaround with close and then reopen the document. Is there also a Dispatch API command for close? I found .uno:CloseDoc, but it doesn't work as aspected. Nothing happens when I use .uno:CloseDoc instead of .uno:Reload. As dispatching this command does the same as choosing Reload from the file menu this would mean that reloading does not work at all?! I couldn't reproduce that on Windows. Hi, The .uno:Reload command is not the problem. The problem refers to my extension context. I overwrite an opened document via copy() in java code and then reload the document via API. With OOo 3.1 this is not possible anymore (on windows). So I need to find another solution for that. My idea was to close the doc via dispatch command and then reopen it again (not really a nice solution). I change the code with .uno:Reload to .uno:CloseDoc, but the document does not close. I don't understand why closing doesn't work, but maybe there's a workaround. Obviously the lock of the document causes the problem. so perhaps switching the document to readonly mode can help: please try to first dispatch .uno:EditDoc (this should switch the document to readonly mode) and then overwrite the document, then dispatch .uno:Reload and then .uno:EditDoc again. If the code works as expected, switching to readonly mode and back should not cause any further reloads, maybe some toolbar flickering possible. BTW: the missing lock was a bug in OOo3.0, so basically your code worked just by luck because of this bug. In general you can't assume that an application does not lock a file that it has opened for editing. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] How to reload current opened document via API
bvoll...@informatik.uni-bremen.de wrote: Quoting Mathias Bauer nospamfor...@gmx.de: Benjamin Vollmer wrote: Hello, I work on an extension where in some cases the opened document is updated externally. So I have to reload my document. In a snippet I found this way: PropertyValue[] aLoadProps = new PropertyValue[0]; // reload current document xComponentLoader.loadComponentFromURL(this.xFrame.getController().getModel().getURL(), _self, 0, aLoadProps); But in my context this snippet doesn't work. Under Ubuntu nothing happens when the code is executed, under Windows there occurs an UNO Runtime Error. At the moment I reload the file manually over File - Reload. This works but it is not really a solution. What is the right way to reload a document via API? You can use the Dispatch API to achieve that. The command you have to dispatch at the documents' frame is .uno:Reload. Unfortunately the solution with .uno:Reload does not work anymore since OO.org 3.1 was released. Under Windows I cannot update the opened document externally because it is locked. I need a workaround with close and then reopen the document. Is there also a Dispatch API command for close? I found .uno:CloseDoc, but it doesn't work as aspected. Nothing happens when I use .uno:CloseDoc instead of .uno:Reload. As dispatching this command does the same as choosing Reload from the file menu this would mean that reloading does not work at all?! I couldn't reproduce that on Windows. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Macro ODB documents
Frank Schönheit - Sun Microsystems Germany wrote: Hi Mathias, I still think that defining ThisComponent as the component from which the macro was invoked (as opposed to the component which the macro is embedded into) was the better choice, and causes less hassle. Finally, this means that only newly written code needs to care for the new concept. If we had changed ThisComponent otherwise, then every existing code (implementing such a functionality as sketched above) would have needed to be rewritten. I'm not sure that the new concept would change a lot at all - except for those cases where the old concept creates an undefined situation anyway. Up to 3.0, database documents, and its sub components (forms, reports, queries, tables, relation designer) didn't participate in the ThisComponent game (since the implementation of this global property was purely SFX based). So, if somebody wrote a (global) macro and triggered this from within one of the DB components/documents, ThisComponent was effectively undefined. This scenario - executing such macros from with DB components - is the only one I know where 3.1 differs from 3.0. So, yes, you're absolutely right :) The only situation where the new concept would be wrong is when a macro from one document is executed while another one is active. But perhaps this does not make a lot of sense anyway and we should forbid that?! This is forbidden already: The Run Macro dialog lists the global macros, plus the ones from the current document, nothing else. You still can execute the macros from Tools-Macro-Organize. It is of course still possible to programmatically execute a macro which resides in a non-current document, and therein, ThisComponent points to the embedding doc, not the active one. Yes, this is the old concept. I thought you wanted to change that. And in that case we would have a different behavior here. But that would be bearable, IMHO. We could define that as undefined. :-) So indeed your case is the only relevant case where both concept lead to different behavior. If you think that the new concept fits better to that (is that true and what will your users think about that?), we can think about a change. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Macro ODB documents
Frank Schönheit - Sun Microsystems Germany wrote: This was one design decision we had to make when Base was created in the current form. Finally, the decision for SDI was because of technical constraints, since OOo doesn't have an infrastructure for MDI. Chosing SDI in favor of MDI was not because we didn't have an infrastructure for MDI (we could have created one, we already had two different ones in the past ;-)), it was done by intent. SDI enables better integration into the Desktop and into other applications. I don't want to argue here whether this decision was a good one or not, I just want to prevent the impression we would have done something because we were not able to do differently. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Macro ODB documents
Frank Schönheit - Sun Microsystems Germany wrote: I still think that defining ThisComponent as the component from which the macro was invoked (as opposed to the component which the macro is embedded into) was the better choice, and causes less hassle. Finally, this means that only newly written code needs to care for the new concept. If we had changed ThisComponent otherwise, then every existing code (implementing such a functionality as sketched above) would have needed to be rewritten. I'm not sure that the new concept would change a lot at all - except for those cases where the old concept creates an undefined situation anyway. The only situation where the new concept would be wrong is when a macro from one document is executed while another one is active. But perhaps this does not make a lot of sense anyway and we should forbid that?! When else do you think that in a common situation where the old concept works fine the new concept would introduce a problem? Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Unfortunate document event name - how to fix it?
accept the backward compatibility burden, this point now is moot anyway. -- 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Proposal: first convention to discuss API changes in the future
APIs without telling anybody, and without providing a migration path, will lead to this impression. Clearly and early saying what has changed, why it has changed, and how clients need to be adjusted, will relax this, IMO. You still ignore the fact that people evaluate something before they invest into it. If the system looks as if it *might* require code fixing work every 6 months it becomes less compelling. Try to see it from the other side - which library would you choose: the one that guarantees to force you to change your code only once a few years or the one where the maintainers say we can't guarantee that you don't need to change your code every 6 months; we try to avoid it, but it might happen? We now live with some bad APIs for a lot of years. It didn't kill us and the problems in our code base are not primarily caused by bad UNO APIs. Nevertheless, some things are annoying and so we will fix them. We might not be able to fix all annoyances and we might add new ones. But why should additional 2 years with these remaining or new annoyances (that's roughly the time between a .1 release and the beta of the next .0 release) kill us? I fail to see so much urgency that it let's me accept the potential feeling of unease that giving up compatibility between masters can cause. So I opt for targeting only major releases for all API changes that will force either code changes or recompilations. API changes with only documentary character (like in old-style services) should be possible at every release (even 3.x). Every agreement can be reconsidered later, so this one also. But we don't need to do that before 4.0 has actually shipped. Let's remove the last sentence :) I don't understand why. I would like to see where we are when 4.0 is ready for Beta and if it really will contain so much dark areas that they need immediate fixing. For the time being let's agree to disagree. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Proposal: first convention to discuss API changes in the future
Frank Schönheit - Sun Microsystems Germany wrote: Hi Ariel, is there already a general agreement about when API changes will be allowed? In my understanding, there was no definitive answer to this question in the thread which discussed it. The general consensus seemed to be towards change anything you like (as long as it's reasonable) in a major release. In my opinion, this /perhaps/ is somewhat too generous for a major release, If that's too generous depends on the context. In the context of mandatory discussions about proposed changes it just means that there should be no mental roadblocks for proposing changes. I think that this is a good thing. My personal take on API changes (changes I would like to suggest or to do) is more restrictive anyway, but that's only me. If possible I always would prefer changes that just need recompilations (what usually als means that Basic macros don't need any work at all as the use introspection), maybe very small and easy changes in the client code in some cases. I understand and accept that other developers at least at times would like to ask for more generous changes. and /definitely/ too restrictive for all intermediate releases. If the only interest was to fix APIs: yes. But in the context of the necessity to keep the API stability on a level that is acceptable for most API users it is a good starting point. If it turns out to be too restrictive we also could think about more frequent major releases. :-) Well, I think I'll challenge that rule sooner or later, I have a lot of small changes to start with :). For instance, I'd like to take all those awt/form services which effectively describe *implementations* in OOo, and make all the optional properties added over the years non-optional, to match reality. Service descriptions, especially those of old style services IMHO can be handled much more generously. Old style services are documentation only. If they just describe implementations, changing this documentation will not break any existing code, as this code relied on what now gets documented anyway. I even would opt for allowing to change them *now* and IIRC we already have done such changes in some cases. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Proposal: first convention to discuss API changes in the future
Ariel Constenla-Haile wrote: Hello Frank, On Thursday 14 May 2009, 15:12, Frank Schönheit - Sun Microsystems Germany wrote: Hi Ariel, is there already a general agreement about when API changes will be allowed? In my understanding, there was no definitive answer to this question in the thread which discussed it. The general consensus seemed to be towards change anything you like (as long as it's reasonable) in a major release. In my opinion, this /perhaps/ is somewhat too generous for a major release, and /definitely/ too restrictive for all intermediate releases. well, I couldn't find info about the OOo 2.0 release, but just comparing OOo 2.0.1 = Dec. 2005 http://wiki.services.openoffice.org/wiki/OOoRelease201 OOo 3.0 = Oct 2008 http://wiki.services.openoffice.org/wiki/OOoRelease30 If major releases happen every 3 years, then allowing API changes only on a mayor release does not make much sense to me. That depends from where you look at it. We always must consider that API users expect API stability, so we need to find a good compromise. Changing APIs every 6 months definitely isn't one. I think that for now aiming for 4.0 as the first release that allows for incompatible API changes is reasonable and I see this as a good opportunity to get the most annoying things fixed. So perhaps the pressure to have more fixes only a few months later shouldn't be too high and for now I would like to plan for 5.0 as the next release for more changes. That leaves a lot of time for further discussion whether we should also allow for changes in (some) minors or if 3 years between two majors perhaps is too much anyway. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Proposal: first convention to discuss API changes in the future
Frank Schönheit - Sun Microsystems Germany wrote: Hi Mathias, If major releases happen every 3 years, then allowing API changes only on a mayor release does not make much sense to me. That depends from where you look at it. We always must consider that API users expect API stability, so we need to find a good compromise. Changing APIs every 6 months definitely isn't one. I think that for now aiming for 4.0 as the first release that allows for incompatible API changes is reasonable and I see this as a good opportunity to get the most annoying things fixed. So perhaps the pressure to have more fixes only a few months later shouldn't be too high and for now I would like to plan for 5.0 as the next release for more changes. I'd expect a timing problem then. If you need a precision landing for your API change, then chances are good you will miss it - and then you'll have to wait for another 3 years (which effectively means your CWS will rot over that time). For a very good reason, we have a train model - integrate what's done, not more, not less - for all other code changes. The lesson we learned for features is that precision landings - I want to have that finished for release x.y - are doomed to fail too often. Why should this be different for API changes? I don't buy that. If something is really important, I know that I have to get it ready in time and the available time is sufficient, I can start early enough. You are right, we won't be able to have exact timings for everything we do, but it should be doable to get some of the things (preferably the important ones ;-)) ready in a multi year planning. Most of the changes you have in mind now are related to old existing APIs. So now you have many months to plan which APIs to change in 4.0 and calculate the effort. This should allow you to schedule the changes for the next major release. Planning for 4.0 means that you will have a time frame of at least 6 months for your ready date. So you can plan to have the changes ready half a year before the major release (immediately after branch-off date for the last 3.x version) and calculate the necessary starting dates accordingly. You still have several months leeway. Sounds doable to me. Really, we shouldn't overburden our API customers. We couldn't do any incompatible changes for now many years and last time I checked the project is still alive. So it should be OK for now to restrict incompatible changes to major releases. I think that even the impression that our API wouldn't be reliable for more than 6 months would be bad for our project. Even if you and me know that allowing for API changes basically in every minor release won't lead to complete chaos, the impression can emerge that indeed this will happen. So I opt for targeting only major releases for all API changes that will force either code changes or recompilations. API changes with only documentary character (like in old-style services) should be possible at every release (even 3.x). Every agreement can be reconsidered later, so this one also. But we don't need to do that before 4.0 has actually shipped. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Exploring OpenOffice.org API through MindMaps
RKVS Raman wrote: Hi, Recently I started this small activity of converting the services and interfaces defined in OpenOffice.org API to XMind Mindmaps. Have started hosting it at the following blog. http://ooomindmaps.blogspot.com/ Hope it is useful to OpenOffice.org folks for presentation and discussions. It looks nice. How did you create the diagrams? As XMind has an XML based open file format, perhaps a new backend for the skeletonmaker could generate it from the idl files? Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Unfortunate document event name - how to fix it?
Bernard Marcelly wrote: Message de Matthias B. date 2009-05-12 11:06 : On Mon, May 11, 2009 at 10:56 AM, Mathias Bauer nospamfor...@gmx.de wrote: For the time being we had to keep OnLoad for compatibility reasons (both for registering as well as for sending), but the documentation would be changed to suggest OnOpen instead. This can be changed (and perhaps will be changed) in the first release that allows for incompatible API changes (I assume this will be 4.0). Alternatively, we can stay with OnLoad until the incompatible change and then switch to OnOpen without any intermediate compatibility arrangements. Comments, anyone? That you even consider removing this event is exactly the lack of commitment to compatibility I have critized in the long thread about OOo quality recently. There is ONLY ONE acceptable solution for changing the name. - introduce the new event name - keep the old event name for compatibility FOR ALL ETERNITY. It is NOT acceptable to retire it with OOo 4.0! NOT acceptable to retire it with OOo 5.0. People build their businesses on OOo. Your petty interests in language aesthetics are irrelevant! If you are worried about the overhead of sending the same event twice, well, there's also this option: - Live with the bad name, compensate it with good documentation and then find something more productive to waste your time on than breaking existing code. Matthias I totally agree with the opinion and arguments of Matthias B. There are many cases of unfortunate names in the API, this is not a good reason to change the API. Having a correct description in the documentation is enough. The best documentation is an API that doesn't need one. This deals with the fact that people don't like to read documentation. Having speaking names for events is a good thing per se, not just some language aesthetics. So using OnOpen for the event that is fired when a document is opened in a window and not confusing OnLoad with OnLoadFinished definitely is a good idea. I was concerned if having an OnLoad doing the same as OnOpen can be a problem. My suggestion to remove it later should just be seen in the context that incompatible changes in the API most probably will happen anyway and so this small change wouldn't be such a big problem, but could remove a source of confusion. I'm not determined to do that, that's only the least interesting part of my problem. As you and Matthias mentioned it, a short comment about incompatible API changes. I have mixed feelings wrt. this and I hope that developers will do that only in rare and justified cases, e.g. when an API is not or barely usable ATM. And I hope that most changes will cause nothing more than a recompile of the client code using it. But that's only me and I know that there are other people with other opinions. As we also have agreed on discussing all API changes in the public, I hope that not only API developers but also API users will join these discussions. If people refrain from shouting at others and using insinuations about the motives behind suggested changes I'm confident that these discussions will show us where we can allow for changes and where we better don't do it. It would be more useful to spend time on improving the API documentation (IDL and Developer's Guide) and correcting known API issues. Some examples: API doc : issues 67088, 79943 API : issues 22625, 64800, 93716 Sure. But I think documentation can be done by anybody knowing about the API, developers as well as users. So you are also invited to do that. :-) Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Unfortunate document event name - how to fix it?
Matthias B. wrote: On Mon, May 11, 2009 at 10:56 AM, Mathias Bauer nospamfor...@gmx.de wrote: For the time being we had to keep OnLoad for compatibility reasons (both for registering as well as for sending), but the documentation would be changed to suggest OnOpen instead. This can be changed (and perhaps will be changed) in the first release that allows for incompatible API changes (I assume this will be 4.0). Alternatively, we can stay with OnLoad until the incompatible change and then switch to OnOpen without any intermediate compatibility arrangements. Comments, anyone? That you even consider removing this event is exactly the lack of commitment to compatibility I have critized in the long thread about OOo quality recently. There is ONLY ONE acceptable solution for changing the name. - introduce the new event name - keep the old event name for compatibility FOR ALL ETERNITY. It is NOT acceptable to retire it with OOo 4.0! NOT acceptable to retire it with OOo 5.0. People build their businesses on OOo. Your petty interests in language aesthetics are irrelevant! If you are worried about the overhead of sending the same event twice, well, there's also this option: - Live with the bad name, compensate it with good documentation and then find something more productive to waste your time on than breaking existing code. I don't want to argue here; it already was agreed upon allowing for incompatible API changes somewhere in the future (I think it will be 4.0), something that never has happened until now (so I don't understand where you see a lack of commitment to compatibility in the past). I won't make incompatible changes just for aesthetical purpose only, but the reason why I'm asking for input here is that I already got complaints from API users about the unfortunate change of event names. I'm not against keeping OnLoad for eternity, if that is of any help for whomever. I'm more concerned about the fact that currently we would have two event names for the same event and I wanted to get input if people see *this* as a problem. Whether this persists until eternity or not is not so relevant for me. So if I see serious concerns against removing it (though other APIs surely will be changes somewhere in the future, so it's open for discussion if being picky about this comparably easy problem is justified), so be it. No problem for me. I assume that your reply was meant to be a contribution to this topic. But if you want to be taken seriously you definitely should work on your tone. It is absolutely inacceptable - using All-Caps, too much exclamation marks, bold insinuations (aesthetics) and insults (petty interests) is not appreciated. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] Unfortunate document event name - how to fix it?
Hi, our API defines some document events that users can register macros or event listeneners for. One of these events is called OnLoad. This is a very unfortunate name, as this event is not triggered when a document is loaded, but when the document is shown to the user, not before the document actually became visible. This is the only way to make this event usable in the way as many macro developers, especially those creating macros in templates, want it. They want the document to be visible before they e.g. show the user a dialog to add something to it. Of course it turned out that the point in time where the document finished loading (and before a view was created) also is interesting for developers, so an event name for it was needed. As unfortunately OnLoad was used already, we took OnLoadFinished. While this is a good name for this event, we now have the unfortunate situation that OnLoadFinished is sent before OnLoad. This is at least confusing. So I would like to change OnLoad to OnOpen. This describes the event much better - it names an event that is triggered only if the document is actually opened, means: shown to the user. For the time being we had to keep OnLoad for compatibility reasons (both for registering as well as for sending), but the documentation would be changed to suggest OnOpen instead. This can be changed (and perhaps will be changed) in the first release that allows for incompatible API changes (I assume this will be 4.0). Alternatively, we can stay with OnLoad until the incompatible change and then switch to OnOpen without any intermediate compatibility arrangements. Comments, anyone? BTW: in case of new documents we fortunately don't have this problem, as the old event OnNew (triggered when the document became visible) doesn't conflict with the new event OnCreate (triggered when the document actually was created, but before it got a view assigned). Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Juergen Schmidt wrote: Mathias Bauer wrote: Frank Schönheit - Sun Microsystems Germany wrote: Sorry, I stay with this: API should be as good as reasonably possible *before* put into the MWS, or even a release. And this requires discussion, most of the time. No objection. I just don't want to have any formal process. Announcing a change, taking part in discussions and reacting on reasonable requests should be enough. late but hopefully not too late ;-) I tend to agree to most of the points and let me summarize the points that are important for me - changes of published APIs or changes in language binding are allowed to major releases only - keep it simple, no complicate processes - discussion about API changes are a must - one requirement - migration guides. That means i would like to see a small migration guide for all API changes. A special section in the API area of the wiki where changes are documented and where API users can easy see the old and new way to use the API. Especially external developers, extension developers can look here to adapt there code easy. This special migration section should be separated by releases. It should be still naturally that all new APIs or changed APIs are documented in the DevGuide wiki ;-) The DevGuide with related examples for beginners adn as consistent developer docu, the migration page for experienced developers to help them with changes. I really don't want to let our API users alone with potential changes. And for that reason a migration guide is absolutely necessary. Trivial changes should be only listed, more complex changed should be documented in detail. Nobody will find it later in the mailing list archives. Sounds like a plan. Let's move that forward! There's one thing that I would like to add, just a hint to everybody who wants to change APIs. The time between the branch-off of a code line for a release (formerly known as code freeze) and the next one is roughly 6 months. This is the maximum time span for having the changes in the master before the code gets released, thus giving everybody time to test the change, adapt own code, perhaps asking for changes etc. The shortest time span is having the code integrated short before the branch-off of the beta version for the major release. It won't give much room for others to test the changes and get used to them. For non-trivial API changes I would like to recommend that the CWS containing them and of course all internal code changes (means: inside of OOo's code base) should be ready for integration as early as possible, just like we want it for a really huge feature. IMHO there shouldn't be any non-trivial API change that doesn't give external developers at least a month or so to adapt their code and come up with detected problems that might cause further changes. Let's make this a recommendation for all developers planing API changes and make them aware that API changes with a large influence may have to wait for another major release if they arrive very short before the beta of the upcoming release is branched off. We shouldn't set any fixed dates, but take that into consideration in the discussions of the proposed API changes. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Replace UNO:Paste
Cor Nouws wrote: Hi, From some threads in the mail archive, I reed it is possible to replace a uno function by one you define yourself. But the example(s) I find are about a component written in Java. Is it possible to do replace UNO:Paste also in OOo-Basic? Unfotrunately not, as the dispatch interception requires the implementation of objects with an externally controlled life time. Some time (years?) ago I proposed the implementation of a generic dispatch interception object that can be bound to macros, but we didn't follow up on that. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Thorsten Behrens wrote: I buy that. But as I said elsewhere, in my book there's a fundamental difference between c++ extensions and e.g. Java- or Python-based ones: it is *much* easier to break compatibility for c++ extensions, and handling them suck when dealing with cross-platform extensions. Given all that, I believe their use should be discouraged, and they should have less weight when it comes to deciding for or against a change that would affect c++ extensions alone. I don't know what discouraging means. At the end developers choose the language they prefer, and if we don't forbid to use C++, people will continue to choose it at times. And as I hope you don't ask for forbidding C++, we have the obligation to not break it intentionally. So again: If an OOo release came with an API that is incompatible to a large extent, we could also change the C++ binding incompatibly - as well as any other language binding. But changing the C++ binding with every release just because it's fragile anyway isn't a good idea. Maybe it's harder to deal with C++ than with e.g. Java. But that shouldn't be a reason not to try it. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Frank Schönheit - Sun Microsystems Germany wrote: I'd say we need a set of highly proficient and highly respected architects, whose opinion should, at least, be weighted high. No, please not! Every code change can break something, so why should API changes be treated differently? We should keep it simple. The only difference should be that arbitrary code changes can be done at any time while API changes can only be done at certain points in time. We could say: API changes (including changes of language bindings) can be made in every major release, and you can change everything you want. Of course (as for every code change) you should do that accountably and talk to other developers that will be influenced by your changes and you should try to make your changes in a way that the potential work of others is minimized. But please no processes, not gate keeper etc. Let things evolve and assume that all participants in the development process act reasonably. A bad API change should be treated as any other code change or patch that we have nowadays: if you see a problem with it, raise your concerns and discuss. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Thorsten Behrens wrote: Mathias Bauer wrote: Of course (as for every code change) you should do that accountably and talk to other developers that will be influenced by your changes and you should try to make your changes in a way that the potential work of others is minimized. But please no processes, not gate keeper etc. Let things evolve and assume that all participants in the development process act reasonably. A bad API change should be treated as any other code change or patch that we have nowadays: if you see a problem with it, raise your concerns and discuss. Hm. I'm totally with you regarding the dislike of processes. But in contrast to normal code changes, which usually happen on the sole discretion of a single dev, API changes should *require* discussion. No problem with that. If in the past someone made an internal C++ API change I assume that discussions have happened also in many cases. Of course we can make prior announcements and discussions mandatory for UNO API or language binding changes. Detecting such changes is easy (we already do it for UNO APIs) and so changes without discussion shouldn't come unnoticed. But I don't want to have any kind of voting/judgement and so forth. For me API changes are not different to other code changes in this regard: if we trust developers that have commit rights, we should also trust them to act reasonably when it comes to API changes. If developers repeatedly act against the common sense of the whole group (either when making API changes or otherwise), they risk to lose their commit rights. Until then we should be able to work together without too much procedural overhead. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Replace UNO:Paste
Paolo Mantovani wrote: Hi Cor, Carsten, Carsten Driesner ha scritto: Cor Nouws wrote: Hi, From some threads in the mail archive, I reed it is possible to replace a uno function by one you define yourself. But the example(s) I find are about a component written in Java. Is it possible to do replace UNO:Paste also in OOo-Basic? I think that the devGuide [1] shows the theory, but that is not the same as usable basic code for me ;-) Hi Cor, Theoretically this could be possible but needs huge effort. Andreas Schluens told me that some people tried it Perhaps that people are me :-) but nobody has ever achieved a positive result yet. It depends. My attempt works well but Andreas said: a) Method createUnoListener() was not thought to be used that way. [...] b) On the other side I believe you can run into trouble with lifetime of your basic objects.[...] Yes, exactly this doesn't make that a reliable way and it lets me discourage everybody to do it. Perhaps we should again think about the macro bound dispatch objects? Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Stephan Bergmann wrote: On 04/30/09 12:24, Mathias Bauer wrote: Frank Schönheit - Sun Microsystems Germany wrote: I'd say we need a set of highly proficient and highly respected architects, whose opinion should, at least, be weighted high. No, please not! Every code change can break something, so why should API changes be treated differently? We should keep it simple. The only difference should be that arbitrary code changes can be done at any time while API changes can only be done at certain points in time. We could say: API changes (including changes of language bindings) can be made in every major release, and you can change everything you want. Everything you want sounds a bit too laissez fair for my taste. Everything that is considered worth it, given that each incompatible changes comes at a cost would be the long version. I didn't expect that a reasonable developer would want anything else. :-) But yes, of course, the long version is better. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Frank Schönheit - Sun Microsystems Germany wrote: Sorry, I stay with this: API should be as good as reasonably possible *before* put into the MWS, or even a release. And this requires discussion, most of the time. No objection. I just don't want to have any formal process. Announcing a change, taking part in discussions and reacting on reasonable requests should be enough. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Thorsten Behrens wrote: Mathias Bauer wrote: limit impact considerations to non-ABI-dependent UNO bindings (i.e. the assumption is that c++ components break randomly anyway for every other release, so they shouldn't block API changes) This is not true; in fact on Windows C++ extensions are very stable and at least without a base line change that should be true for other platforms as well (some discipline assumed). Hi Mathias, well, Win32 is only one platform, :-) It's the platform of the overwhelming majority of our users. As far as I'm concerned, I'm making software for users, not for ends in themselves. So for me there is some sense in trying to keep extensions working as long as the pain for the developers is bearable. We decided that it's about time to take some pain from the developers, but that doesn't mean that we should give up compatibility completely. and experience tells that in general, c++ extension *do* break between releases. No, exactly that is not my experience, not with our careful handling of baselines and backwards compatibility. If am using a very sophisticated Windows C++ extension that was made for OOo 1.x and it is still running well with OOo3. C++ extensions break for the same reason as others: because of bugs of changed behavior in OOo. There is no reason to treat C++ extensions differently. But you're right, that's not necessarily caused by ABI changes in the strict meaning of the word, a case in point is the 3 layer OOo rework. Whatever happened there, it's not something that is likely to happen much often and doesn't qualify for a general problem with C++ extensions. And BTW - again no problems with it on Windows. My take on that would be: if we allow for incompatible API changes in e.g. a major release, there's no reason not to allow incomatible changes in the C++ libs also. Maybe that's what you wanted to express. No, but that's surely something I can buy into as well. What I wanted to express is that the c++ API/ABI is fragile enough IMO to not hold back with changes that *deliberately* break compatibility there. People should really be encouraged to use (or at least wrap their stuff with) Java or Python when doing extensions; that would also quite nicely solve the problem of (non-)cross-platformness. ;) The C++ API/ABI is only as fragile as we make it. And I think we should make it only as fragile as we will make the UNO API in general. That means, if an OOo release came with an API that is incompatible to a large extent, we could also change the C++ binding incompatibly - as well as any other language binding. But changing the C++ binding with every release just because it's fragile anyway isn't a good idea. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Thorsten Behrens wrote: Hi *, on the last ESC meeting, we had a little brainstorming about if and how to deprecate OOo API. The 'if' was unanimously agreed upon, for the 'how' we came up with the following thoughts: API deprecation === There's one point in the wiki I don't agree with: limit impact considerations to non-ABI-dependent UNO bindings (i.e. the assumption is that c++ components break randomly anyway for every other release, so they shouldn't block API changes) This is not true; in fact on Windows C++ extensions are very stable and at least without a base line change that should be true for other platforms as well (some discipline assumed). My take on that would be: if we allow for incompatible API changes in e.g. a major release, there's no reason not to allow incomatible changes in the C++ libs also. Maybe that's what you wanted to express. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Multithread question
Kay Ramme - Sun Germany - Hamburg wrote: Hi Oscar, Oscar Picasso wrote: Hi, I have read several threads, without definitive answers, about the current support for multhreading when using openoffice as a server. Basically, I have a web application that, at user request, takes an openoffice template, changes some text, based on the user input, and generates a pdf file. In this context is openoffice thread safe? If not was could be the result of concurrently calling openoffice to populate a same template on behalf of different requests? OOo tries to be thread-safe ... but unfortunately it is not really. If you stress it, it dies ... Crash? Performance? Confusion (mixing or changing the data?). If the openoffice server is not thread safe, I thought about the web requests calling openoffice from the command line. But in that case, do concurrent calls use the same openoffice instance? Is it safe from the data integrity point of view? Running one client at a time gives you good chances that the application does not crash. In short what is the safest way for openoffice to solve this use case. Good question ... the safest way is to use the main-thread for doing operations in OOo, though this one is not directly reachable from another process. Well, in fact it nowadays is. There is a UNO service that can be called with an object receiving a callback. This callback will happen in OOo's main thread and by moving all code into this callback you will have your code executed as if it was called from e.g. OOo's menu bar. You still may have problems when your application is written in a languagge using garbage collection as this can lead to desctructor calls of OOo objects executed in the garbage collection thread. Best regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] How to reload current opened document via API
Benjamin Vollmer wrote: Hello, I work on an extension where in some cases the opened document is updated externally. So I have to reload my document. In a snippet I found this way: PropertyValue[] aLoadProps = new PropertyValue[0]; // reload current document xComponentLoader.loadComponentFromURL(this.xFrame.getController().getModel().getURL(), _self, 0, aLoadProps); But in my context this snippet doesn't work. Under Ubuntu nothing happens when the code is executed, under Windows there occurs an UNO Runtime Error. At the moment I reload the file manually over File - Reload. This works but it is not really a solution. What is the right way to reload a document via API? You can use the Dispatch API to achieve that. The command you have to dispatch at the documents' frame is .uno:Reload. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] How to access the Storage of an opened OOo document?
Giuseppe Castagno wrote: Mathias Bauer wrote: Giuseppe Castagno wrote: Hi Mathias, Mathias Bauer wrote: Giuseppe Castagno wrote: Now my questions, keeping in mind that at a certain time I need to access the META-INF substorage to manipulate a custom file (read and write). Why do you need access to the META-INF? Everything in the manifest should be accessed via properties of the storage elements that the manifest describes. Can you explain what you want to achieve? Sure. I'm writing an extension in Java to sign the ODF document according to an Italian standard. Something that should be implemented specifically. The reason I need to access the META-INF substorage is to add there the specific signature stream, according to the work in progress at OASIS Office on ODF 1.2. ([1] and descendant discussions) It's still in the planning state, e.g. proof of concept, but will lurk here [2]. It's just started, so the svn there is still empty... Adding a stream to the manifest is easy even without direct access to it. If a stream is inserted and the stream object has a MediaType or other supported properties the Storage implementation will write them for you. Can you explain what kind of stream attributes you want to store in the manifest? If some are missing now, maybe we can add them to the list of supported properties of the Storage implementation. The new stream in substorage META-INF will be a new xml file, named for example xadessignature.xml. But I'm not sure I understand you. Ah, I mis-understood your intention. I thought you wanted to add the stream to the manifest.xml, but in fact you want to add a stream to the substorage. Sorry, my bad. Of course you can access the META-INF *folder*. Did you have a look on the xmlsecurity modules' code, e.g. http://svn.services.openoffice.org/opengrok/xref/DEV300_m45/xmlsecurity/source/helper/documentsignaturehelper.cxx Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] How to access the Storage of an opened OOo document?
Giuseppe Castagno wrote: Hi Mathias, Mathias Bauer wrote: Giuseppe Castagno wrote: Now my questions, keeping in mind that at a certain time I need to access the META-INF substorage to manipulate a custom file (read and write). Why do you need access to the META-INF? Everything in the manifest should be accessed via properties of the storage elements that the manifest describes. Can you explain what you want to achieve? Sure. I'm writing an extension in Java to sign the ODF document according to an Italian standard. Something that should be implemented specifically. The reason I need to access the META-INF substorage is to add there the specific signature stream, according to the work in progress at OASIS Office on ODF 1.2. ([1] and descendant discussions) It's still in the planning state, e.g. proof of concept, but will lurk here [2]. It's just started, so the svn there is still empty... Adding a stream to the manifest is easy even without direct access to it. If a stream is inserted and the stream object has a MediaType or other supported properties the Storage implementation will write them for you. Can you explain what kind of stream attributes you want to store in the manifest? If some are missing now, maybe we can add them to the list of supported properties of the Storage implementation. Regards, Mathia -- 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] OO Writer Extension
Cristina Scheau wrote: Hi! I'm Cristina Scheau, a Computer Science student from Romania. I am new to Open Office API and intend to develop a XWiki(http://www.xwiki.orghttp://www.xwiki.org/xwiki/bin/view/Main/WebHome) Extension for OO Writer (this is my Gsoc proposal). My question is, there is a way to handle events from OO, like saving a document, or creating a new document? You don't need to look for events if you want to save an OOo document in a particular format; please read about filter development in the OOo Developer's Guide. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] How to access the Storage of an opened OOo document?
Giuseppe Castagno wrote: Now my questions, keeping in mind that at a certain time I need to access the META-INF substorage to manipulate a custom file (read and write). Why do you need access to the META-INF? Everything in the manifest should be accessed via properties of the storage elements that the manifest describes. Can you explain what you want to achieve? Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] DocumentProperties Enhancment proposal
Hi Fernand, IIRC we store the name of the computer in the lock file also, but I don't remember if it's shown in the message box. Regards, Mathias Fernand Vanrie wrote: Mathias , OK i found that out myself yesterday, but we are still the ComputeName missing. You now: in a compagny, a user can work anywhere and he ha s left the building with a document stil open .. :-) so that can been easly impovend No ? Greetz Fernand Fernand Vanrie wrote: The reason I am a heavy user off the old DocumentInfo is that I uses a macro to start all our Company Documents. This simple macro runs at opening and closing and change user defined property InuseBy where we take note of the User and the Machine who opened the Document. When a other user on our network tries to open the same Document then he not only is informed that this document is read only but also who is using this document and on witch machine the Doc stays open. I suppose this simple behavior can been coded as a option for for all OO-docs who are run on a network In OOo3 you don't need that as the new lock files will tell you that anyway. And this is even better as it works without modifying the document on disk. Regards, Mathias - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org -- 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] DocumentProperties Enhancment proposal
Fernand Vanrie wrote: The reason I am a heavy user off the old DocumentInfo is that I uses a macro to start all our Company Documents. This simple macro runs at opening and closing and change user defined property InuseBy where we take note of the User and the Machine who opened the Document. When a other user on our network tries to open the same Document then he not only is informed that this document is read only but also who is using this document and on witch machine the Doc stays open. I suppose this simple behavior can been coded as a option for for all OO-docs who are run on a network In OOo3 you don't need that as the new lock files will tell you that anyway. And this is even better as it works without modifying the document on disk. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Regresion in User Defined DocumentInfo
Andrew Douglas Pitonyak wrote: Frank Schönheit - Sun Microsystems Germany wrote: Hi Fernand, now i have to use oDocuInfo.GetpropertieValue( PMG_StylesVakjes) Changing this few lines is not the problem, but The code is around in Thousands of documents :-) should i start changing my code or can this be fixed ? I'd say this is an API compatibility issue. Try submitting a issue, and raising it as 3.1 blocker in relea...@openoffice.org (1) I believe that the document information object is deprecated in favor of document properties. You may want to consider finding a solution that works with document properties instead. (2) The fact that the document information object still exists, I would have expected it to continue to function as before (so this feels like a bug to me). Yes, the reason for the bug is a peculiarity in the way Basic inspects property sets that was unknown to the developer that implemented the new DocumentProperties. It's fixed now. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: [allfeatures] changed/CWS fwk95 : Extended UNO AWT menu API
Stephan Bergmann wrote: On 01/27/09 09:13, Mathias Bauer wrote: BTW: a keyword unpublished would come in handy here as it could become the hyperlink itself! It seems we did it the wrong way. Not only because of this but also because (as usual!) not the standard way of doing things (the published API) should be marked by a special attribute, but the one off the road (the unpublished API). The rationale for having a published keyword instead of an unpublished one was that actually publishing an API is a deliberate activity. Also, this way the publishing concept could be added backwards-compatibly into UNO rather late in the game. And its safer this way, in that the default (no extra keyword given) case lets you easily fix your mistake and move to the non-default (published keyword added) case, while that is not true the other way around. Granted, all this might be more relevant from the perspective of the API producer than from the perspective of the API consumer. API consumers indeed need to be trained now to look for explicitly published API and ignore implicitly unpublished one. As we are talking about the HTML version of the API we could perhaps use a commentary addition unpublished with the link I mentioned. No need to change the original IDL files. Regards, 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] How to attach new Model to old Controller
Hi all, sorry for entering this interesting dicussion so late, but perhaps better late than never. Mikhail Voitenko wrote: Hi Daniel, On 02/20/09 02:49, Daniel Brosseau wrote: Hi Mikhail, Frank, Thank you again. since it would allow returning more information (and thus would have saved you the question, since you would have got a message saying not allowed for this implementation). As an extreemly minor point: I got a return of false and not not allowed for this implementation :) I have tried loading at the Frame level. I get the Frame by first loading a _blank component from the Desktop's XComponentLoader and then moving up from the XComponent's XModel to the XController to the XFrame. I then get the XFrame's XComponentLoader to load subsequent URL's into the Frame. The load replaces the previous Model but does not close it This is a bug. I have just written a small basic script to test this, and indeed in case a document is loaded as hidden one, the controller does not close the model. In case of visible documents it works well, the model is closed. Could you please write a bug to me. We must be very careful here. When we invented XCloseable, we discussed days and weeks what calling close() on models should means for the frames it is in and what calling close() on a frame should mean for the model it contains. One result of this long discussion was that closing visible frames also should try to close the model if no other visible frame exists, closing invisible frames never should close the model insiede. The main reason for that was that hidden frame quite often are created on the fly and closing them after usage should not close the model that usually still is needed. Admittedly we did not consider exchanging models in hidden frames, but we should stay inside the architecture to avoid complications or either redesign the complete framework wrt. closing. I think the latter would be exaggeration, so let's define the current state as works as designed. BTW: there is another reason why hidden and visible frames are different. The lifetime of visible frames is (or can be) controlled by the user, so the frame must control the lifetime of the model. Hidden frames never can be closed by users, so the only way to get rid of them is doing it from the script, macro, extension or application code that created it, so making this code also responsible for controlling the lifetime of the model the frame contains is a bearable effort that - on the bright side - avoids all problems we would get otherwise. so I close the previous Model after the Frame is loaded with the new URL. If I do not close the previous Model, the memory usage in soffice.bin increases continuously with each load. Yes, a model has to be closed to end the objects lifetime. This is designed so, because the complex system of objects let cycle dependencies appear. And since the controller erroneously does not try to close it in this case, it stays open. In these circumstances your workaround to close the model after it is replaced in the frame is absolutely correct. After the mentioned above bug is fixed it will not be necessary any more. As I wrote, I consider the workaround to be the correct treatment. From other side if the frame is closed it disposes the controller. And the controller should close the related model if it is the last view of the document. As I explained, that's true only for visible frames. The fact that the call let office crash/hang is a problem. The developers guide mentiones that modified documents might be a problem in this case. Please try to set all remaining documents to nonmodified state before terminating and probably close them. I wouldn't expect that hidden frames are a problem here. At least that would be a strange bug. I rather think that the hidden frames and its models stay open and terminating the Desktop removes the infrastructure they are built upon. So the right approach should be closing all hidden frames and all models before terminating the desktop. 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...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] How to avoid screenupdating without loosing the XViewCursors position
Peter Eberlein wrote: You could create a second, hidden view of the same document. I never tried that by myself so I can't predict if this can create problems, but OTOH - why should it? Thanks, that works. I don't like dispatches, so is there a api-method for .uno:NewView? There's no direct, single API call. First, the property OpenNewView of the MediaDescriptor comes to my mind. But loading is to slow. Also played with creating Frames manually [1]. The example runs, but how to put the ComponentWindow into the frame? That's the easy part - call setComponent(). The problem is creating it, we currently don't have an API for that. You can do the following: a frame implements the XComponentLoader interface and so you can call the loadComponentFromURL() method on it. If you pass the document as Model argument to the call, the document will not be loaded a second time but instead of that the frame should create a second view. You can do it even easier by not creating the frame manually but using the XComponentLoader of the desktop. 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] How to avoid screenupdating without loosing the XViewCursors position
Peter Eberlein wrote: Hi Fernand, Fernand Vanrie schrieb: Peter Eberlein wrote: Hi, I have to scan an XTextDocument for some patterns and to sort the found XTextRanges by their visual representation. So the XViewCursor's point (getPosition()) seem the only way to do this (because the anchor of the textrange may differ). For the user the moving of the cursor is annoying. LockControllers() of the XModel can avoid this, but then the position of the XViewCursor is wrong, if you jump with the ViewCursor to the XTextRange. Is there another way to turn off screenupdating and to circumvent the problem with the XViewCursor? First i was thinking on viewcursor.setvisible(false) but this has no effect at all then i remeber a forum discution an there i found a less-nice-solution thisComponent.CurrentController.Frame.ContainerWindow.SetVisible(false) thisComponent.CurrentController.Frame.ContainerWindow.SetVisible(true) oh, hiding the document is no solution :( other ideas? You could create a second, hidden view of the same document. I never tried that by myself so I can't predict if this can create problems, but OTOH - why should it? 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] embedding Java window in OO.o frame
Marc Santhoff wrote: Hi, the devguide has information about embedding an OO.o window into a Java window as a client. I'd like to know if the opposite is possible: a Java window embedded into a OO.o window/frame. Can this be done? If yes, how to? (or where can I find information on the topic ;) In OOo2.x we had support for Java Applets in OOo and so we already have an example how to embed Java windows. The code doing that can be found in the sj2 module and in sfx2/source/doc/applet.cxx. Perhaps this can give you some hints how to do 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Supress warning dialog for saving sxw files
Hi, even if I'm a month too late: we also could define a new MediaDescriptor parameter (DisplayFormatWarning). Ciao, Mathias Mikhail Voitenko wrote: Hi Tobias, Sorry, there seems to be no reliable way to avoid the warning regarding possible information loss while saving. The problem is that the warning is shown directly by the standard dispatch interceptor for the saving action. You could probably send a new issue to me to let the warning be shown using the InteractionHandler, in this case the warning could be controlled. But the fix would be translation related, so it can be done only for OOo3.1. After the fix is integrated, a new dispatch interceptor for the save action could be registered in the way, that it uses InteractionHandler wrapper over the current InteractionHandler during the saving, and the wrapper just prevents showing of the selected warning. Best regards, Mikhail. Tobias Krais wrote: Hi together, is it possible to supress the warning dialog when saving a sxw file? I would like to supress the dialog via api (Java) for just this one dialog. Any help is appreciated! Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Supress warning dialog for saving sxw files
Tobias Krais wrote: Hi Mathias, even if I'm a month too late: we also could define a new MediaDescriptor parameter (DisplayFormatWarning). my five Cents: godd idea. Should I create an Issue? If Mikhail agrees... 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] embedding Java window in OO.o frame
Joachim Lingner wrote: Mathias Bauer wrote: Marc Santhoff wrote: Hi, the devguide has information about embedding an OO.o window into a Java window as a client. I'd like to know if the opposite is possible: a Java window embedded into a OO.o window/frame. Can this be done? If yes, how to? (or where can I find information on the topic ;) In OOo2.x we had support for Java Applets in OOo and so we already have an example how to embed Java windows. The code doing that can be found in the sj2 module and in sfx2/source/doc/applet.cxx. Perhaps this can give you some hints how to do that. Ciao, Mathias Be aware, however, that support for Java applets was ended. All code related to applets will sooner or later be removed. Of course. But that doesn't mean that we can't keep at least the code to embed Java windows. Or ...? 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Supress warning dialog for saving sxw files
Tobias Krais wrote: Hi Mathias, even if I'm a month too late: we also could define a new MediaDescriptor parameter (DisplayFormatWarning). my five Cents: godd idea. Should I create an Issue? Thinking a bit more: you want to suppress this dialog even if the saving is done from the UI? Then the additional parameter won't help. I don't see a good fix for that. OTOH if you are saving via API and see the dialog it is a bug and we don't need an additional parameter - just fix the bug. But does it happen by saving via API? 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Can I use XDispatchProviderInterceptor in an extension?
Giuseppe Castagno wrote: Hi Andreas, Andreas Schlüns wrote: Hi Giuseppe, ... Seams to be a simple typo ... The sentence should be: If both are available, the synchronous interface is preferred by the job execution environment. On the implementation side it's more easy than you think :-) For you there exists two possibilities to implement a job: a) the synchronous way using XJob or b) the asynchronous way using XAsynchronousJob. It depends from our use cases which interface should be used/implemented and supported by your job implementation. Sometimes it happened that a programmer decided to support BOTH interfaces at the same implementation. Dont ask me why ? :-) So I've decided to implement a mechanism which preferres one interface in such case - and thats the synchronous interface XJob. I used the synchronous way, since I need to stop the thread when doing processing inside the Job. Thanks for the explanations, I updated the DevGuide. Thanks for that. It's great that the DevGuide now is so easily accessible! I love it. :-) Kudos to Jürgen and Clayton, life has become easier for us now. 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] copy/paste with dispatcher
Hi, Atte André Jensen wrote: Hi I'm trying to copy a part of a document while preserving the formatting with python. Here's the code I have: print rangeCursor.String controller = doc.getCurrentController() controller.select(rangeCursor) frame = controller.getFrame() properties = () dispatch_helper.executeDispatch(frame, .uno:Copy, , 0, properties) dispatch_helper.executeDispatch(frame, .uno:Paste, , 0, properties) dispatch_helper.executeDispatch(frame, .uno:Paste, , 0, properties) The print ensures me that rangeCursor is infact containing the desired text, but still no copying is happening. I'm thinking the problem is the dispatch is not using the desired text... Anyone able to help me a bit further? Also, I'm quite confused about the documentation, in this case I'd like to see a list of that properties could be/do. I guess it should be different for Copy and Paste, but where is this documented? Thanks in advance for any input! If having this for Writer or Calc only is enough, there is a simpler way of copying/pasting code. You can get the current selection into a clipboard object by calling obj = ThisComponent.CurrentController.getTransferable() and (after moving the cursor to the desired destination) copy it by calling ThisComponent.CurrentController.insertTransferable(obj) 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 [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Can I use XDispatchProviderInterceptor in an extension?
Giuseppe Castagno wrote: Hi all, I'd like to intercept some dispatch commands (as .uno:Save for example) from inside an extension, using Java. Is it possible to use a XDispatchProviderInterceptor interface for that, intercepting the dispatch command before it is sent to the right executor? Yes. From what I've seen from the tests I carried out so far and from studying the DevGuide code examples, using a XDispatchProviderInterceptor from inside an extension doesn't seem possible. Prompted from the response I got from another message I posted on this ML, I first tried by implementing a job, but I need to do some user interaction while processing the job, and again that wasn't possible from inside it. Besides the job can't interrupt the processing chain: something I need depending on some user action. The trick is how you get the interceptor attached to the frames whose DispatchProviders they want to intercept. This will need an additional Job service implemented in the extension that is registered to the DocumentEvent OnViewCreated. The job then can register the DispatchInterceptor. Best regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] How to develop new style filter?
Hi shenzhuxi, shenzhuxi wrote: I'm trying to develop a filter. But all the examples in the DevelopersGuide are old style. Is anyone working with new style filters? Where can I find new guides? Can you explain what you consider to be a new style filter? Best regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
