[api-dev] This request requires elevation
this is the error I get when I try to open and exel doc or spreadsheet (which used to work for me)... I've tried the Run as Administrator and that doesn't work either... HELP!! Please Thanks Linda
[api-dev] Open Office
when I try to open an excel program (which I used to be able to do) I get an error message saying The requested operation requires elevation.. I have tried to Run as Administrator and that, too, does not work. HELP!
Re: [api-dev] Change pagestyle of all pages
Dear Laurent, Crivello, Laurent wrote (29-4-2009 10:53) I am currently trying to change the page size of every page in my writer document, to a single size. However my code only changes it for the first page. How to apply it to the whole document ? There is nothing wrong with your code. It changes the properties of one page style. Have a look at how Writer works with page styles. See the Help for that. After that you understand you have to change the settings of all page styles used in the document. Here is the code I use: [...] Kindest regards, Cor -- Cor Nouws-nl.OpenOffice.org marketing contact = 2009 - Develop OOo = www.nieuwsteoffice.nl = - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] Change pagestyle of all pages
Dear All, I am currently trying to change the page size of every page in my writer document, to a single size. However my code only changes it for the first page. How to apply it to the whole document ? Here is the code I use: controller=doc.getCurrentController() cursor=controller.getViewCursor() sPageStyleName = cursor.PageStyleName oPageStyles = doc.StyleFamilies.getByName(PageStyles) oStyle = oPageStyles.getByName(sPageStyleName) oStyle.Width = 21000 oStyle.Height = 29700 Thanks for your precious help ! Laurent
Re: [api-dev] Thinking about an API deprecation process
Stephan Bergmann wrote: On 04/28/09 14:27, Thorsten Behrens wrote: well, Win32 is only one platform, and experience tells that in general, c++ extension *do* break between releases. 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. Hu? http://www.openoffice.org/servlets/ReadMsg?listName=devmsgNo=24706 and http://www.openoffice.org/servlets/ReadMsg?listName=devmsgNo=24718 for example. Maybe I am dumb, but I do not find any mention of broken C++ OOo extensions in those two mails. Hi Stephan, oh, I was under the impression the author is referring to c++ - so then, it's Java? Should we add Java to the list of fragile extension implementations as well? ;) And of course with symbol interposing on elf-based platforms, you get all the fun if someone injects names into the OOo process that are normally bound to e.g. another version of a shipped external lib... I do not see how that would relate to the topic of this thread. Sorry for not being clear - symbol interposing makes it even harder to maintain compatibility for c++ extensions, due to the mutual influence the OOo baseline extensions have on symbol resolution (i.e. a dso already in the lookup scope when an extension is loaded can mess with the extension; conversely, with OOo dlopening uno components using RTLD_GLOBAL, the extension's dependencies can mess with OOo). Although I'd think symbol versioning is supposed to solve this problem, there are apparently enough corner cases (or badly-versioned libs) out there that it fails: http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=23388 (I also remember problems with different versions of the freetype lib, but cannot find any reference currently) Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] Save slide OOImpress 3.0 using C++.
Hi,
I use OpenSuSE 10.2, kernel 2.6.18.2. I have OpenOffice3.org and
OpenOffice.org SDK version is 3.0. My OOImpress presentation has 7 slides in
all. I want to save each of the 7 slides as different OOImpress
presentations in different files. For, example, Slide 1 in the original
presentation should be copied and saved as another presentation file as
slide1.odp, Slide2 in original should be saved as slide2.odp and so on. The
final result is, I have 7 different slides with different filenames. I want
to do this in C++.
What I have dont so far:
1. I used the DocumentLoader.cxx program, available with the OpenOffice.org
SDK and added few lines from the code available here
http://codesnippets.services.openoffice.org/Impress/Impress.DealWithImpress.snip.
DocumentLoader.cxx program loads test.odt but I have changed this and
instead it loads my presentation file test.odp
2. What I have taken from the Code Snippet example is this piece:
//Loop through all pages and give Pagenumber+Pagename to each of them
for (int icounter = 0; icounter pagecount-getCount(); icounter++)
{
Any mPage = pagecount-getByIndex(icounter);
Reference XDrawPage drawpage(mPage, UNO_QUERY);
Reference ::com::sun::star::container::XNamed
names(drawpage, UNO_QUERY);
OUString pagename = names-getName();
OString sName = OUStringToOString( pagename ,
RTL_TEXTENCODING_ASCII_US );
printf(\n Page Number %d has the name %s, icounter,
sName.getStr());
}
3. The above code, loops through all the pages present in the file and
prints the Slide Name and Number.
4. Similarly, I want to loop through all the pages and one by one keep
saving them in different presentation files as said above.
Any idea, how this can be done?
Please feel free to ask in you are in doubt. If anybody wants to see the
code, I'll be happy to share it.
Thank you.
Regards,
Shoaib
Re: [api-dev] Thinking about an API deprecation process
... unsure where to start, seems I missed some mails ... Let me briefly sort my thoughts: - We (OOo) do provide APIs (Uno, C/C++, Java, BASIC etc.) more or less for modularizing / unitizing OOo. - We do regard some of these APIs to be for internal use only, while others are available for public use. - The internal ones are (inherently) unstable, while public APIs in general should be stable (though some may still be on their way). - We do regard stability of APIs as important for 3rd parties as well as for our users, so that a user can expect a particular application (e.g. extension) to work in a particular set of OOo versions. - Obviously an API may earliest be used with the first OOo version providing it. - Historically we aimed for only adding APIs to allow any existing application (e.g. extension) to continue working with all future OOo versions. (Note: In practice we did break (accidentally or intentionally) some APIs every once a while.) - We now seem to understand that adding new APIs w/o removing/adapting old APIs creates a measurable burden on both shoulders, ours and that of 3rd parties. On ours, as we have to maintain the stuff and sometimes may not as easily change something as we wanted, on the 3rd parties, because the learning hurdle to master all of these APIs steadily increases. Removing/adapting an API typically means breaking it! If we do want to support such changes, we certainly want to do this in a coordinated fashion, to avoid surprises. We do need some cornerstones for this, though we should also allow to apply common sense, avoiding too much of a process. A cornerstone may be something as to allow changes/removals for major versions only etc. ... and we need to ensure that the basics are in place, such as versioning APIs etc., to be able to deal with an incompatible application (e.g. extension) in a user friendly way. Some years ago I thought and did favorite to never ever change an API, as I wanted to be able to always use all existing applications (e.g. extensions) in any recent enough OOo version, even if the author or origin of these application had not been available anymore. After gathering some years of experience with Firefox extensions etc., I now think that we only need (and may be should) only support any lively (maintained) extension! This means also that we can expect the maintainer to adapt the code to any (reasonably) changing APIs. Regards Kay Mathias Bauer wrote: 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
[api-dev] Problem with my Eventhandler under OOWriter 3.x (Exception)
Hello! I've got a Problem with the registration of my Event-Handler since I installed OpenOffice.org 3. My Basic script to register my simple Eventhandler seems to be obsolete and I dont find the correct fix for this. I only want to capture the Close of my Document to sent a message to my application. Here my old script (from an old OO example), which produces this Exception: Type: com.sun.star.lang.IllegalArgumentException Message: cannot coerce argument type during corereflection call! Sub StartCloseListening() oDoc = ThisComponent oEventListener = CreateUnoListener( DocCloseListener_, com.sun.star.lang.XEventListener ) oDoc.addEventListener( oEventListener ) --- Here comes the exception!! End Sub Sub DocCloseListener_disposing( oEvent ) AutoClose() End Sub Thanks for Help Alex P.
Re: [api-dev] Thinking about an API deprecation process
Mathias Bauer wrote: well, Win32 is only one platform, :-) It's the platform of the overwhelming majority of our users. Hi Mathias, well, the question of *how* overwhelming the majority is, that's indeed interesting (though largely off-topic here, I fear) - what might be the number of desktop Linux users? Estimates range between 15 and 30 millions, and pretty much all of them have OOo installed. What's the current tally of Win32 OOo downloads? 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. Granted. And I'm convinced an overwhelming majority of the people here are not doing software for ends in themselves. 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. 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. Cheers, -- Thorsten - 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
Kay Ramme - Sun Germany - Hamburg wrote (29-4-2009 12:31) ... unsure where to start, seems I missed some mails ... I did not read much of this thread, but .. [...] This means also that we can expect the maintainer to adapt the code to any (reasonably) changing APIs. This sounds completely reasonable for me. I maintain some extensions in the public repository and for customers, and have no problem with changes at certain points, if well communicated etc. Ciao, Cor -- Cor Nouws-nl.OpenOffice.org marketing contact = 2009 - Develop OOo = www.nieuwsteoffice.nl = - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Problem with my Eventhandler under OOWriter 3.x (Exception)
Hi Alex, According to the IDL documentation, XEventListener is deprecated. Use (still unpublished) XDocumentEventListener. http://api.openoffice.org/docs/common/ref/com/sun/star/document/XDocumentEventListener.html Regards Bernard Message de Alex P date 2009-04-29 12:37 : Hello! I've got a Problem with the registration of my Event-Handler since I installed OpenOffice.org 3. My Basic script to register my simple Eventhandler seems to be obsolete and I dont find the correct fix for this. I only want to capture the Close of my Document to sent a message to my application. Here my old script (from an old OO example), which produces this Exception: Type: com.sun.star.lang.IllegalArgumentException Message: cannot coerce argument type during corereflection call! Sub StartCloseListening() oDoc = ThisComponent oEventListener = CreateUnoListener( DocCloseListener_, com.sun.star.lang.XEventListener ) oDoc.addEventListener( oEventListener ) --- Here comes the exception!! End Sub Sub DocCloseListener_disposing( oEvent ) AutoClose() End Sub Thanks for Help Alex P. - 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
Hi Thorsten, as a general preface, let me say that I agree to Jürgen that we should separate UNO API incompatibility from UDK API incompatibility. While I think that some ideas can be applied to both, my gut feeling is that both topics are too different to be discussed together. preface II: Thanks for bringing this up, that's a long-standing issue, which desperately needs to be addressed. Decide on preconditions for change: - API was badly designed (architects/pleads to vote if not concordant) Have a list of 'design smells' here, e.g.: * missing exception specifications - API is unused This is not a precondition, but an indicator for allowance, actually. - API implementation is too expensive ... Decide on constraints: - how many clients does this API have * inside OOo code * (estimated) use outside OOo repo * (estimated) number of implementers not reading interface-announce For the latter two, if (at most) recompile is enough, any number of implementers won't block change. For the latter two, if syntactic changes are required, have architects/pleads majority in favor of change? - how 'bad' is the API really – if bad enough, change anyway? I think that we might need to define certain types of changes, and define the constraints per type. For instance, with an API which actually is intended to be used by clients, but not to be re-implemented by external components (this holds for a lot of services/interfaces which effectively describe the current implementation in OOo version X), I think it should be allowed to, say, add new methods to existing interfaces, or new interfaces to existing services. For a Java/Basic/Phython/Basic/BeanShell/JavaScript client (extension), this would be completely transparent. C++-clients might or might not be affected (chances are they are). For an API which is intended to be implemented by extensions (say, a spell checker), adding new methods will immediately make the extension stop working, so here we probably need other constraints. Coming from the other side, perhaps we should classify the different types of possible changes, and decide (judging from the pain the changes class would bring for API clients and OOo users with non-adjusted extensions) for every class under which circumstances such a change is allowed. Yes, I think we need a fine grained rule set. Im convinced that anything like For every major version, you are allowed to change everything you claim is badly designed currently will lead to big problems, because it will be too easy to misuse it (intentionally or not ...). Different changes which come to my mind: - adding/removing exception specifications - adding/removing interface methods/attributes - adding/removing interfaces to services [1] - adding/removing method parameters - adding/removing base interfaces to existing interfaces (each of those items is probably two different ones, actually) - ... I don't have an opinion on *all* of those, but my *very personal* wish list contains: 1. I want to be able to fix the exception specifications in our interfaces. All those methods not allowed to raise anything except a RuntimeException (thus sometimes wrapping their errors in a WrappedTargetRuntimeException - what a stupid concept, sorry) just make reasonable error handling hard up to impossible. 2. I want to be able to add methods to (some) of our interfaces. For instance, something like XDatabaseMetaData, modeled after a ten-year-old version of Java's DatabaseMetaData, suffers for *years* from its non-extensibility (which is highly different from its archetype: JDBC's DatabaseMetaData is extended with every version). 3. I want to be able to add new interfaces to existing services, if those services actually describe the current OOo implementation, without declaring them as optional (and lying to my API documentation readers this way). 4. I want to be able to use the cool new (huh, not really new) multi-inheritance feature for interfaces, consolidating decade-old interfaces, and using the merged versions where the single versions were used before. For instance, if I have XResultSet and XRow, and a method taking either one of those, with a comment in prose this *must* also support the other one, then please give me an XResultSetRow (or let me derive XResultSet from XRow), and allow me to change all method parameters taking/returning an XResultSet to actually take/return XResultSetRow, greatly relieving all clients this way. 5. I want to be able to fix mis-designed interfaces. XDatabaseMetaData is a good example, again, as it states things like if this parameter is NULL, talking about a string parameter ... too closely copied from Java, I'd say. Another example: Ever tried adding a default-VOID property to an XPropertyContainer? Uhm, you've lost, the type is implicitly defined by the given value. 6. I
Re: [api-dev] Thinking about an API deprecation process
Hi Thorsten, 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, agreed so far. and they should have less weight when it comes to deciding for or against a change that would affect c++ extensions alone. less weight - yes. But not no weight. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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
Hi Thorsten, well, Win32 is only one platform, and experience tells that in general, c++ extension *do* break between releases. 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. Hu? http://www.openoffice.org/servlets/ReadMsg?listName=devmsgNo=24706 and http://www.openoffice.org/servlets/ReadMsg?listName=devmsgNo=24718 for example. Maybe I am dumb, but I do not find any mention of broken C++ OOo extensions in those two mails. oh, I was under the impression the author is referring to c++ - so then, it's Java? Should we add Java to the list of fragile extension implementations as well? ;) Not sure you're doing the topic a good with this The mentioned mails indeed talked about Java extensions broken by the new bootstrap mechanism (a pretty singular event, hopefully, so please let's not hang this too high). So, we cannot use them as arguments why C++ extensions break. All known (to me :) C++ extensions use the UDK API only, which I think we should be even more careful with than with the normal office API. If we are, then there's no reason why C++ should not work in different OOo versions ... (well, introducing a dependency to the compiler version or something like this, might be a good idea, but that's independent from API compatibility, IMO.) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Problem with my Eventhandler under OOWriter 3.x (Exception)
Hi Bernard, Alex, com::sun::star::lang::XEventListener is not deprecated. The problem looks to be that the document implements two addEventListener() methods that differ only by the type of the provided argument. You need the one that gets com::sun::star::lang::XEventListener. If I am not wrong there was a solution for Basic that has allowed to resolve the ambiguity. Unfortunately I can not currently remember how exactly should it look like. Best regards, Mikhail. On 04/29/09 13:29, Bernard Marcelly wrote: Hi Alex, According to the IDL documentation, XEventListener is deprecated. Use (still unpublished) XDocumentEventListener. http://api.openoffice.org/docs/common/ref/com/sun/star/document/XDocumentEventListener.html Regards Bernard Message de Alex P date 2009-04-29 12:37 : Hello! I've got a Problem with the registration of my Event-Handler since I installed OpenOffice.org 3. My Basic script to register my simple Eventhandler seems to be obsolete and I dont find the correct fix for this. I only want to capture the Close of my Document to sent a message to my application. Here my old script (from an old OO example), which produces this Exception: Type: com.sun.star.lang.IllegalArgumentException Message: cannot coerce argument type during corereflection call! Sub StartCloseListening() oDoc = ThisComponent oEventListener = CreateUnoListener( DocCloseListener_, com.sun.star.lang.XEventListener ) oDoc.addEventListener( oEventListener ) --- Here comes the exception!! End Sub Sub DocCloseListener_disposing( oEvent ) AutoClose() End Sub Thanks for Help Alex P. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org -- Sun Microsystems GmbHMikhail Voytenko Nagelsweg 55 Software Engineer 20097 HamburgPhone: (+49 40)23646 500 Germany Fax: (+49 40)23646 550 http://www.sun.demailto:mikhail.voite...@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - 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: [lots of valid points] Hi Frank, no disagreement whatsoever. Who decides? Difficult ... Having a gatekeeper (or multiple fatekeepers) does not really sounds feasible. I would hope that discussing the changes in public until a consensus is reached would work out. Uh, well. While I appreciate striving for consent, this tends to not work so well among hackers - but really no strong feelings here, I'd just suggest to have a tie-breaking rule in case sufficient discussion did not result in a consensus... Cheers, -- Thorsten - 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: oh, I was under the impression the author is referring to c++ - so then, it's Java? Should we add Java to the list of fragile extension implementations as well? ;) Not sure you're doing the topic a good with this The mentioned mails indeed talked about Java extensions broken by the new bootstrap mechanism (a pretty singular event, hopefully, so please let's not hang this too high). Hi Frank, uh, I did use a ;), right? Anyway, sorry for misunderstanding the post. All known (to me :) C++ extensions use the UDK API only, which I think we should be even more careful with than with the normal office API. If we are, then there's no reason why C++ should not work in different OOo versions ... (well, introducing a dependency to the compiler version or something like this, might be a good idea, but that's independent from API compatibility, IMO.) Compiler versions tend to change, as well as the baseline. And as pointed out, there's other things that can go wrong (especially on non-windows platforms). At any rate, I'd be fine agreeing on the c++ compatibility should have less weight rule you suggested elsewhere - after all, if you need to recompile your c++ extension anyway because a new method or exception has been added to an interface, you're doing that with an updated udk, don't you? Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Problem with my Eventhandler under OOWriter 3.x (Exception)
Hi Alex, com::sun::star::lang::XEventListener is not deprecated. The problem looks to be that the document implements two addEventListener() methods that differ only by the type of the provided argument. You need the one that gets com::sun::star::lang::XEventListener. If I am not wrong there was a solution for Basic that has allowed to resolve the ambiguity. Unfortunately I can not currently remember how exactly should it look like. instead of oDoc.addEventListener(...) you can also write: oDoc.com_sun_star_lang_XEventListener_addEventListener(...) to force the usage of the correct interface. Regards Andreas Best regards, Mikhail. On 04/29/09 13:29, Bernard Marcelly wrote: Hi Alex, According to the IDL documentation, XEventListener is deprecated. Use (still unpublished) XDocumentEventListener. http://api.openoffice.org/docs/common/ref/com/sun/star/document/XDocumentEventListener.html Regards Bernard Message de Alex P date 2009-04-29 12:37 : Hello! I've got a Problem with the registration of my Event-Handler since I installed OpenOffice.org 3. My Basic script to register my simple Eventhandler seems to be obsolete and I dont find the correct fix for this. I only want to capture the Close of my Document to sent a message to my application. Here my old script (from an old OO example), which produces this Exception: Type: com.sun.star.lang.IllegalArgumentException Message: cannot coerce argument type during corereflection call! Sub StartCloseListening() oDoc = ThisComponent oEventListener = CreateUnoListener( DocCloseListener_, com.sun.star.lang.XEventListener ) oDoc.addEventListener( oEventListener ) --- Here comes the exception!! End Sub Sub DocCloseListener_disposing( oEvent ) AutoClose() End Sub Thanks for Help Alex P. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Problem with my Eventhandler under OOWriter 3.x (Exception)
Message de Mikhail Voytenko date 2009-04-29 15:00 : Hi Bernard, Alex, com::sun::star::lang::XEventListener is not deprecated. The problem looks to be that the document implements two addEventListener() methods that differ only by the type of the provided argument. You need the one that gets com::sun::star::lang::XEventListener. OOps ! I confused with c.s.s.document.XEventListener Here is the solution in Basic : you have to indicate the correct interface to use. The underline character replaces the dot or :: separator. oDoc.com_sun_star_lang_XComponent_addEventListener( oEventListener ) Regards Bernard - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] Problem saving RTF file from OpenOffice 3
Hi to all, i found a problem if i try to save a file (open with OpenOffice 3.0) as .rtf, the numeric or dot list are not preserved (In OpenOffice 2.0 i don't have any problems about this). Any suggest for me?? Thanks to all Regards ~~ Dott. Cristian Fonti mailto: crfo...@scmgroup.com c/o Centro Elaborazione Dati (CED) SCM Group S.p.a. http://www.scmgroup.com via Emilia, 77 - 47900 Rimini (RN), Italy Tel.: +39 0541 700163 Interno: 2163 ~~ - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] This request requires elevation
That is the error. You didn't include it in the email. On Tue, Apr 28, 2009 at 5:55 PM, Linda Gehan jlb.1...@yahoo.com wrote: this is the error I get when I try to open and exel doc or spreadsheet (which used to work for me)... I've tried the Run as Administrator and that doesn't work either... HELP!! Please Thanks Linda
Re: [api-dev] Thinking about an API deprecation process
Hi Thorsten, Who decides? Difficult ... Having a gatekeeper (or multiple fatekeepers) does not really sounds feasible. I would hope that discussing the changes in public until a consensus is reached would work out. Uh, well. While I appreciate striving for consent, this tends to not work so well among hackers Indeed. (By the way: This holds for developers, too :-P ) but really no strong feelings here, I'd just suggest to have a tie-breaking rule in case sufficient discussion did not result in a consensus... I'd say we need a set of highly proficient and highly respected architects, whose opinion should, at least, be weighted high. Hmm. There's more to say about this, but for the moment, I'd like to hear more opinions on the topic in general, on a possible rule set, on possible constraints, and so on. Before we don't clarify those, it's useless to discuss the approval process. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] Replace UNO:Paste
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 ;-) Thanks for any pointers, Cor 1] http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Dispatch_Interception -- Cor Nouws-nl.OpenOffice.org marketing contact = 2009 - Develop OOo = www.nieuwsteoffice.nl = - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
