Re: [dev] hg.services.openoffice.org broken
Hi, Maybe I am not subscribed to enough lists but... On Thu, 2010-07-01 at 10:35 +0200, Stephan Bergmann wrote: > ls > > hg push ssh://h...@hg.services.openoffice.org/cws/sb127 > remote: Received disconnect from 12.184.192.15: 2: fork failed: Resource > temporarily unavailable > abort: no suitable response from remote hg! is there any info on when this situation might be resolved? thanks, Noel - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: GetWorkingDocument in ScVbaApplication
Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote: I'm finished, thank :) Look at the cws_src680_basmgr03 branch for a review. always glad when someone else does the work ;-) looks fine to me well I will try to remove this dependency anyway, I mean given the XModel you can always find the matching object shell if required ( or so it seems to me ) Only if the document/model is implemented using an SfxObjectShell/SfxBaseModel. well currently I am only interested in calc which fits the bill but I take your point ( /me wonders what documents aren't based off SfxBaseModel ( probably a stupid question but ) ) The whole reason for the thing I'm doing in ... So - no, you shouldn't rely on a document model having an associated SfxObjectShell. If you do, it's *me* to remove and UNOize this later on, so please don't :) do you really promise to unoize all the core api bits ( and the no doubt mammoth associated dependency tree of structures/objects etc. ) that I wish to use? ;-) I call alot of functions in the calc core that require a ScDocShell. I don't know if I can alway avoid this kindof hack o In application basic ThisComponent refers to the last selected document I'm not sure the "selected" isn't still to fuzzy. maybe activated then? at least thats what it means to me There are a few places which call a SetWorkingDocument, amongst them, the deactivation code of an OLE object embedded in an SfxObjectShell document. I'm absolutely unsure whether the app:ThisComponent is always what you'd expect. I am sure you are correct, iirc there are all sort of funny scenarios like when documents are closed which can result in 'ThisComponent' not being set ( and possibly being incorrect/invalid ) Which IMO seriously limits the usefulness of this global variable. it would be great if there were to be a more useful solution which would allow you to determine the current 'Active' document ( or even the current Active document of a distinct type, e.g. calc, writer etc. that way it would be possible to determine simulataneously the 'active' writer & calc document, but maybe this is a result of a certain need that I know I will have in the future ;-) ). Either way of course I think there will always be a certain 'fuzzyness' around the point at which these types of variable(s) get set ( platform and windowing etc. ) o in document basic ThisComponent *always* refers the the document running the macro But the SfxObjectShell::WorkingDocument affects the app:ThisComponent only, right? Just to be sure I don't miss something here ... afaik correct, I think in the case of document basic above the behaviour is influenced by the IDE ( combined with the basic context ( app | document ) ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: GetWorkingDocument in ScVbaApplication
Hi Frank Frank Schönheit - Sun Microsystems Germany wrote: Hi Noel, I continue this in dev@openoffice.org, since I think we meanwhile have some important clarifications on the topic ... sure, good idea ( meanwhile I realise I have 516 unread dev list messages :-/ ) ... Okay. I was about to remove the css define from sfxbasemodel.hxx, and relpace it with a proper "namespace css = ::com::sun::star" directive, yup, well thats what I did in one of my own files which is the correct way IMO. If you already addressed this elsewhere - even better, saves time on my side :) well its not clear when cws-npower7 ( where the fix is ) will be integrated so probably you should just go ahead ( maybe try and keep the change on the same line to avoid future conflicts, cvs is clever enough to recognise the identical change I think ) vbahelper.hxx:1.2.2.1 is the version that contains the namespace defn. > Which means I cannot get rid of the WorkingDocument (while I still think such a global state is flawed by design...). I changed the code so that now the WorkingDocument is an XModel, that seems sensible and I don't see any problems with that not an SfxObjectShell. Still need to set up an env with ENABLE_VBA to also fix the vbaapplication, but this shouldn't be difficult. shouldn't be, I hope to get to look at this later on and maybe even I can help with that (Though I think the proper solution would be to hook this up somewhere in the basic runtime (BasicRuntime::ActiveDocument, or something like this), since all clients are effectively interested in the basic runtime's ThisComponent not quite, its a little bit more complicated :-) ( as usual ) see below. , I don't think I'll embark on *this* detail right now.) :-) I understand In other words: No need for any action on your side anymore, except adjusting your not-yet-upstreamed VBA code to an WorkingDocument which is an XModel. well I will try to remove this dependency anyway, I mean given the XModel you can always find the matching object shell if required ( or so it seems to me ) I am of course interested if you know of any other alternatives to determine the current 'Active' document, do you? This depends on what you need the "active" document for. In the sense it is used in the VBA application, it refers to the document which the currently running macro originates from, *or* (if there is no such document) the document whose macro has last been selected in the Basic IDE, *or* (if there is none) the document whose window has the focus. well here is the area that I hinted was a bit more complicated, first we should distinguish between vba behaviour and ooo-basic behaviour ( what you described is actually the ooo-basic behavior ) ThisComponent and the basic/ide interaction is very very confusing ;-) but you also have to factor in the different basic types e.g. document basic and application basic. ThisComponent behaves differently in both. Briefly it works like this. o In application basic ThisComponent refers to the last selected document o in document basic ThisComponent *always* refers the the document running the macro otoh hand with VBA generally it is a little simpler because there is no application basic just document basic, and also, you don't need to worry about documents of other types ( because they exist in seperate applications ) in vba the 'Active(Document|Workbook)' variable/property is the last selected document or spreadsheet ( roughly analagous to ThisComponent in 'application ooo-basic' ) The variable/property 'This(Workbook|Document)' refers to the spreadsheet or document that is running the current macro and is roughly analagous to 'ThisComponent' in the context of document basic ( are you confused yet ? ) The main item of course is the first one: document which the currently running macro originates from. I'd say this needs to be a property of the running script, but AFAIK, there is no mechanism for this in the scripting framework. nope I don't think there is either, iirc the scripting framework gives back the last selected document Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Incubator for vba macros
Hi All, I've contacted Louis and he's reviewed my proposal for a new incubator project. So now I'm asking you, the community to have a look, voice your opinion and help get this off the ground. For a long time now its been recognised that lack of interoperability with vba macros can be a major stumbling block to OpenOffice adoption. With that in mind at go-oo.org we've been experimenting a bit with vba interoperability, so far we've made some strides in making OOo support Excel macros. We feel it's time now to expose this work to the greater OOo community and get more people involved about this. I believe this is a great opportunity to create some new excitement around OOo and really improve the interoperability of the product. some more info o blog http://noelpower.blogs.ie/2005/12/09/proposed-incubator-project-for-vba-interop/ o wiki page http://wiki.services.openoffice.org/wiki/VBA please give your support :-) ( and votes ) Thnx, Noel Project Title = VBA Interop Mission Statement = Promote adoption of OpenOffice by providing support for users who wish to execute VBA ( Initially Excel ) macros in OpenOffice. Build a community of developers to maintain & improve VBA interoperability Rationale = One of the biggest barriers to OpenOffice adoption is lack of macro interoperability. In the enterprise space generally the most mission critical macros exist in Excel spreadsheets. To eliminate or lower this barrier clearly will ease adoption of OpenOffice. Some initial and promising work has been started in go-oo.org ( http://go-oo.org ), we wish to make this work more freely available. Project Goals === * Setup an Incubator project. * Build on the initial work started at go-oo.org, increase the converage of * the api. * Analyse and prioritise common api usage and patterns to determine what * objects/api to concentrate on. * Help new developers contribute by extending the existing work by providing * support, documentation etc. * Build up a library of test documuments to get 100% imported. * Contribute to existing projects ( calc-core, ms-filters, oo-basic runtime ) * to facilitate common key core objective of better interoperability. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
