[dev] funny
Read This: http://www.msnbc.msn.com/id/20227400/site/newsweek/ -- From: Travis Athougies 2 + 2 = 4
[dev] Restrictions for parameters and return-values in the service AddIn
Hi, first of all I'm new to this group. I hope I'm not complete OT and I beg you to tell me if I do anything wrong in this group. Now to my question: I managed to develop a new component implementing the Service AddIn and the first AddIn-Function I wrote took a string as argument and returns a double. That was my first test and it works well. Now - beginning the real quest - I want to write an Add-In-Function taking a cell as Argument and returning another cell as result. Such a function would be very needful for me as an auxilliaryfunction. My problem is $subject - You could not have an argument of type cell (o.k. it could be a cellRange but this is not really what I want) and you can have in no way a returnvalue of type cell. Can one explain why Add-In-Functions do have this restzrictions? Can one tell me if there is a workaround which lets me solve e.g. the following task: I have an Add-In-Function - lets call it evalResult - which takes a string as argument and returns a double. Now I want do the following: In a sheet - call it round5 - of my document there are the results of the matches of the teams and the players of the teams in round 5 of the tournament. In another sheet - lets say parameters - there is a cell containing the name of my team. Now I want to have a formula in the first cell of column G such that I get the value I would get when evalResult would be used on the text one line under and one column right of the cell where I found the name of my team. In the second cell of column G the referenced cell should be that two lines under and one column right of the "teamNameCell". So I want to write Add-In-Functions - e.g. called getText and searchRelative - so that I can use the formula =evalResult(getText(searchRelative( parameters!$B$1, "searchRange", "row(thisCell)", 1 ) but then searchrelative must be able to return a cell as result!! You can argument I just could write a function evalResultRelative which can take all the arguments and returns a double directly. This is true - but(!) I do need the function evalResult as described and I do need the searchRelative-technic in several places and circumstances in the whole document. So: again - 1) why do Add-In-Functions have this restrictions and 2) is there a workaround solving the problem in such a way that I can write the modular functions I want. I hope my questions are clear enough and I hope I'm in the right newsgroup for this questions Thanks in advance for any help and greetings from Holger Walliser P.S.: I tried to post this questions yesterday but there did not appear a posting of me - so I try it again now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] How++ (Re: [dev] How about .. . (Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabl ed Record macro menu in Impress and Draw
Hi Matthias, Mathias Bauer wrote: >> But then, wouldn't this also mean that this Dispatch API is excercised >> by all OOo modules then, including Draw/Impress, or is it the case that >> for using that API some of the module-dependent (C++ implemented) UI >> elements still need to be programmed accordingly? >> > > The Dispatch API is the same in all modules - but this is a generic API > and the "real" action lies in the command names and paramters. All > objects have the same interface to receive commands but they differ in > the commands they support and - in case of Draw/Impress - also in the > degree of how good their implementation actually is. In Draw/Impress > parameters are mostly not supported at all and they are essential for > playing recorded macros. That's enough for calling the Dispatch API from > the GUI (where usually no parameters are sent) but is a killer for > playing macros using the API. > > Besides that: this is only the "playing" side, in Draw/Impress the > recording side even looks worse (remember the rule set for recorder > support I posted earlier). > Given all of your information, I very much tend to believe that. ;-) A reverse mapping should be establishable then as well in this case, even if that is a 1:N mapping (i.e. a C++ function/method gets invoked from different UNO types), it would at least allow for narrowing down the UNO types, and it could be possible that from the context one could even narrow them down further. >>> The reverse mapping that we can do is what the current macro recorder does: >>> all received "dispatch()" calls are recorded. >>> >> Hmm, would it be conceivable then to come up with a static table of >> dispatchable user-actions with a sequence of UNO API invocations that >> would be needed to be excercised such that for recording purposes this >> list could be used in addition, recording the values of arguments and >> results and so on. Or with other words, for every dispatch have an >> independent, alternitve thread of creating UNO pseudo-code necessary to >> arrive at the same functionality, stating pre- (which UNO objects, >> methods, argument values) and post-conditions. Maybe even including >> branch statements, or with other words, small (commented) pseudo-code >> segments that could be used to map to a concrete language later on. >> Either being editable to correct or supply addtional code/information. >> > > You have described "reimplement the glue code" with other words. Yes, of > course you can reimplement each and every dispatch call by using UNO API > calls. You can do this in the glue code itself (thus replacing it) and > record these calls or you can have a parallel implementation somewhere > else as you described or Paolo Mantovani already did for some Calc > dispatches. But it's a reimplementation in all cases! The difference > only is that in your case the original code is not replaced but its > effect on the document is achieved differently. This has an advantage > (no regression risk as the original code is preserved) as well as a > disadvantage (OOo's size will grow considerably). And it's time > consuming in every case. > Yes, but one would have to start out *documenting* what should happen in the UNO world to match a particular dispatch call in any case! Even if you started out without the existing dispatch calls you'd still be forced to document/define what should be done in UNO to map what is sought for in the C++ implementation. Or with other words: you can't get a new macro recording in place without efforts! The question would be how to achieve this as quickly and resource-saving as possible, if you are serious in creating and supplying a full featured macro recording eventually (hopefully within one, two years). >> Even if it is not perfect and may contain omissions or incomplete >> information it may generate UNO based code that needs a little bit of >> "massaging", it would be so much more and a starting point that really >> may drive up productivity. (Obviously looking for a Pareto solution, >> i.e. 20% effort for covering 80% of the needed functionality, leaving >> the missing 20% to the UNO/OOo savvy programmers.) Power end-users would >> be able to create that skeleton then rather easily, needing UNO/OOo >> acquainted programmers to turn it to a running macro. >> > > Now we are at the point where we started: writing down the correct set > of UNO API calls for each dispatch call will first force us to deliver > the missing APIs and types and then will take years to implement the > calls. We have thousands(!) of dispatch calls to implement. Some of them > also depend on internal states. The command ".uno:Delete" e.g. must be > implemented completely different depending on what is selected. > Not sure (again not knowing anything about the inner workings, hence pure speculation) about this conclusion. How many dispatches are generated via th
[dev] Development at a Glance - Weekly Update CW35
Hi, here is the weekly update for calendar week (CW) 35: http://blogs.sun.com/GullFOSS/entry/development_at_a_glance_weekly29 Regards, Dieter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] ODT file created through XSL transformation is corrupt
Hello Thanks for your responses. Concerning the mimetype entry: > ... it doesn't look like it is the first stream ... What does this mean? Do I have to write the JarEntry for the mimetype as first entry written to the output file? I've tried that but that doesn't help. Additionally, that doesn't explain the phenomenon that unzipping and zipping the file fixes the corrupt document by magic. Here's the content of mimetype entry of the corrupt document: == application/vnd.oasis.opendocument.text == And here the content of the manifest.xml: == == Regards, Benno > -Original Message- > From: Eike Rathke [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 29. August 2007 12:20 > To: dev@openoffice.org > Subject: Re: [dev] ODT file created through XSL transformation is corrupt > > * PGP Signed by an unknown key > > Hi Mathias, > > On Tuesday, 2007-08-28 18:45:59 +0200, Mathias Bauer wrote: > > > First I miss the "mimetype" stream. > > It's there, but it doesn't look like it is the first stream in the > package that it ought to be following the ODF spec: > > > > Nametypesizeratio path > > > content.xml XML 9'69075% > > > meta.xml XML915 61% > > > mimetype File 39 0% > > [proportional fonts for tables in mails are ugly] > > Eike > > -- > OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. > SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 > OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS > Please don't send personal mail to this [EMAIL PROTECTED] account, which I use for > mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks. > > * Unknown Key > * 0x87F8D412 > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: the issue about the programme freezed when switch to another input method
Hi Stephan, > Nah, the top of the stack is the OfficeIPCThread, which waits for a > second instance of soffice to connect against it. It is normal that > this thread is there and that it is blocked in osl_acceptPipe. (Just > the tail of the stack trace appears to be garbage, probably an artifact > of the tooling used to generate those traces.) The tail definitely looks like garbage, and maybe this implies the rest is garbage, too? I just said "it looks suspicious" :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: the issue about the programme freezed when switch to another input method
Frank Schönheit - Sun Microsystems Germany wrote:
[3888]desktop::GetURL_Impl
ntdll.dll!7c92eb94()
ntdll.dll!7c92e9c0()
kernel32.dll!7c8025cb()
ntdll.dll!7c92fb6c()
ntdll.dll!7c92da69()
kernel32.dll!7c802532()
kernel32.dll!7c831608()
sal3.dll!osl_acceptPipe(oslPipeImpl * pPipe=0x02dec57c) Line 418 + 0x17 C
vos3MSC.dll!vos::OPipe::accept(vos::OStreamPipe & Connection={...}) Line
232 + 0xf C++
soffice.exe!desktop::OfficeIPCThread::run() Line 575 + 0x13 C++
vos3MSC.dll!vos::threadWorkerFunction_impl(void * pthis=0x02e0a804) Line
50 + 0xc C++
sal3.dll!oslWorkerWrapperFunction(void * pData=0x0330e778) Line 81 + 0xd C
msvcr71.dll!63fb9565()
kernel32.dll!7c80b683()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String & rName={...}) Line 2786 +
0xd C++
c0c4()
soffice.exe!desktop::GetURL_Impl(const String & rName=) Line 2786 + 0xd C++
This thread's stack looks suspicious - too many GetURL_Impl instances
here, I somehow think this stack is corrupted. Besides this, I think
this thread might also be a part of the freeze.
Nah, the top of the stack is the OfficeIPCThread, which waits for a
second instance of soffice to connect against it. It is normal that
this thread is there and that it is blocked in osl_acceptPipe. (Just
the tail of the stack trace appears to be garbage, probably an artifact
of the tooling used to generate those traces.)
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] ODT file created through XSL transformation is corrupt
Hi Mathias, On Tuesday, 2007-08-28 18:45:59 +0200, Mathias Bauer wrote: > First I miss the "mimetype" stream. It's there, but it doesn't look like it is the first stream in the package that it ought to be following the ODF spec: > > Nametypesizeratio path > > content.xml XML 9'69075% > > meta.xml XML915 61% > > mimetype File39 0% [proportional fonts for tables in mails are ugly] Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to this [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks. pgpS6oCw5RhJt.pgp Description: PGP signature
[dev] Re: the issue about the programme freezed when switch to another input method
Hello Du Yunfen,
one thing beforehand: Great to see you think I'm the right person for
this kind of problem :), but actually this touches code areas which I
barely know. Thus, I think this discussion is best continued at
[EMAIL PROTECTED] I send this mail to the list, and would like to ask
you to reply to the list, too.
Further comments inline (and full quote for the new readers).
> Hi, Mr Schönheit
>
> It's still on the issue mentioned last time.
> the operation steps as follows:
>
> .create a new writer(or base ,calc ,draw ...).
> .click view->datasource.
> .choose a local datasource of nodes ,connect.
> .activate the context.
> .switch to another input method .
>
> then the application will freeze.We had Tracked the threads and I found
> when it is freezed, the application is still
> activated in the thread *[3640]rtl_cache_wsupdate_all* and always in a
> cycle which is in ../sal/source/rtl/alloc_cache.c :
> rtl_cache_wsupdate_all (void * arg)
> {..
> while (!g_cache_list.m_update_done)
> { ..
> }
> },
> and
This doesn't tell me anything, sorry.
> in the thread *[3888]desktop::GetURL_Impl*, the programme run to
> ERROR_MORE_DATA in osl_acceptPipe(oslPipeImpl * pPipe=0x02dec57c) which
> in ../sal/osl/w32/pipe.c.
>
> So I want to know what are modules( *sal* and *vos* ) used to achieve
> and the possible contact between switch the input method and connected
> a local datasource ?
I don't know ... sal is the "system abstraction layer", vos is some
older code for low-level system independent stuff, where nearly
everything in vos has a modern replacement in sal or osl.
> Thanks.
> Best Wishes.
>
> duyunfen
>
>
> ps: the threads:
>
> [3100]WinMain
> ntdll.dll!7c92eb94()
> user32.dll!77d194be()
> user32.dll!77d1b42d()
> user32.dll!77d184fc()
> user32.dll!77d185a4()
> user32.dll!77d1b3f9()
> user32.dll!77d1b393()
>> vcl680mi.dll!SalFrameWndProcW(HWND__ * hWnd=0x001008e4, unsigned int
> nMsg=80, unsigned int wParam=1, long lParam=-534640636) Line 6060 + 0x16 C++
> user32.dll!77d18734()
> user32.dll!77d18816()
> imm32.dll!7630e489()
> user32.dll!77d1f805()
> user32.dll!77d189cd()
> user32.dll!77d18a10()
> vcl680mi.dll!ImplDispatchMessage(const tagMSG * lpMsg=0x0101f698) Line
> 200 + 0xa C++
> vcl680mi.dll!ImplSalDispatchMessage(tagMSG * pMsg=0x0101f698) Line 716 +
> 0x9 C++
> vcl680mi.dll!ImplSalYield(unsigned char bWait='', unsigned char
> bHandleAllCurrentEvents=0) Line 746 + 0x9 C++
> vcl680mi.dll!WinSalInstance::Yield(bool bWait=true, bool
> bHandleAllCurrentEvents=false) Line 791 + 0xd C++
> vcl680mi.dll!Application::Yield(bool bAllEvents=false) Line 554 C++
> vcl680mi.dll!Application::Execute() Line 516 + 0x7 C++
> soffice.exe!desktop::Desktop::Main() Line 1803 C++
> vcl680mi.dll!ImplSVMain() Line 255 C++
> vcl680mi.dll!SVMain() Line 296 C++
> soffice.exe!sal_main(int __formal=1, int __formal=1) Line 82 C++
> soffice.exe!WinMain(void * _hinst=0x0040, void * _dummy=0x,
> char * _cmdline=0x00051f0a, int _nshow=1) Line 74 + 0x39 C++
> soffice.exe!WinMainCRTStartup() Line 390 + 0x1b C
> kernel32.dll!7c816fd7()
> ntdll.dll!7c935b4f()
This thread *might* be part of the problem, since it seems that
dispatching a message blocks for whatever reasons. However, I don't know
enough about that kind of stuff.
>
> [3640]rtl_cache_wsupdate_all
> ntdll.dll!7c92eb94()
> ntdll.dll!7c92e9c0()
> kernel32.dll!7c8025cb()
> kernel32.dll!7c802532()
>> sal3.dll!rtl_cache_wsupdate_wait(unsigned int seconds=10) Line 1450 C
> sal3.dll!rtl_cache_wsupdate_all(void * arg=0x000a) Line 1547 + 0x9 C
> kernel32.dll!7c80b683()
>
> [3956]oslWorkerWrapperFunction
> ntdll.dll!7c92eb94()
> ntdll.dll!7c92e9c0()
> kernel32.dll!7c8025cb()
> ntdll.dll!7c946abe()
> kernel32.dll!7c802532()
>> sal3.dll!osl_waitCondition(void * Condition=0x0f48, const
> TimeValue * pTimeout=0x03d7ff54) Line 112 + 0xe C
> vos3MSC.dll!vos::OCondition::wait(const TimeValue * pTimeout=0x03d7ff54)
> Line 75 + 0x10 C++
> vos3MSC.dll!vos::OTimerManager::run() Line 492 + 0x14 C++
> vos3MSC.dll!vos::threadWorkerFunction_impl(void * pthis=0x02de6eb4) Line
> 50 + 0xc C++
> sal3.dll!oslWorkerWrapperFunction(void * pData=0x03313eb0) Line 81 + 0xd C
> msvcr71.dll!63fb9565()
> ntdll.dll!7c946abe()
> kernel32.dll!7c80b683()
> ntdll.dll!7c946abe()
>
> [3888]desktop::GetURL_Impl
> ntdll.dll!7c92eb94()
> ntdll.dll!7c92e9c0()
> kernel32.dll!7c8025cb()
> ntdll.dll!7c92fb6c()
> ntdll.dll!7c92da69()
> kernel32.dll!7c802532()
> kernel32.dll!7c831608()
>> sal3.dll!osl_acceptPipe(oslPipeImpl * pPipe=0x02dec57c) Line 418 + 0x17 C
> vos3MSC.dll!vos::OPipe::accept(vos::OStreamPipe & Connection={...}) Line
> 232 + 0xf C++
> soffice.exe!desktop::OfficeIPCThread::run() Line 575 + 0x13 C++
> vos3MSC.dll!vos::threadWorkerFunction_impl(void * pthis=0x02e0a804) Line
> 50 + 0xc C++
> sal3.dll!oslWorkerWrapperFunction(void * pData=0x0330e778) Line 81 + 0xd C
> msvcr71.dll!63fb9565()
> kernel32.dll!7c80b683()
> soffice.exe!desktop::
