Re: Ad Apple''s setup for the (Java) scripting framework

[Rony G. Flatscher (Apache)]

While also testing on LO (and getting the ooRexx macro support there up and 
running again with the
help of - kudos! - Stephan Bergmann) the problem should be restated (issues
, 
):

  * if launching AOO from a Terminal (the command
"/Application/OpenOffice.org/Contents/MacOS/soffice") the environment got 
already set by the
login script, such that soffice works in that environment and therefore has 
access to all
programs in the directory "/usr/local/bin" (which has become of paramount 
inmportance on MacOSX
because Apple since a few releases forces third parties to install their 
binaries and commands 
there),

  * when launching AOO (and LO for that matter) from the Finder ("Application") 
no user login
scripts get executed and the environment therefore is - unfortunately - not 
set up the same as
in a Terminal! This is the reason why the environment variable PATH is not 
set correctly (the
Apple launch service does not honor "/etc/paths", it seems, but rather has 
the PATH hardcoded)
and other environment variables may not be defined for the application that 
gets launched by it).

On MacOS there is a file named "/etc/paths" which lists the system paths 
line by line and
includes the directory "/usr/local/bin", however the Finder launched 
application (AOO, LO) does
not include that mandatory directory in the PATH environment variable! 
Although there is a key
LSEnvironment which would allow to set the environment and therefore would 
allow to define PATH
to contain also the directory "/usr/local/bin" (e.g. by honoring 
"/etc/paths" on MacOS), I have
not been able to define it in the Info.plist that it gets honored for 
swriter, scalc, etc.!

(In my case, allowing the scripting language ooRexx to be used and deployed 
as an AOO/LO macro,
I could eventually solve the problem with a - stable, nevertheless - MacOS 
hack by analyzing
PATH prior to invoke the Rexx interpreter and if "/usr/local/bin" is 
missing it gets prepended
to the environment, which is possible via the JNI bridge to BSF4ooRexx. To 
make a long story
short: this allows ooRexx to search "/usr/local/bin" for ooRexx packages 
like BSF.CLS, UNO.CLS
and the like. It would be *much* better, of course, if AOO would be able to 
add the
"/usr/local/bin" directory to the PATH environment variable if it is 
missing from there, as then
other third party programs on MacOS could be invoked, used via AOO/LO 
components and/or macros.)

The issue with Java programs on MacOS that interact with the GUI that all of a 
sudden cause crashes
on MacOS () is still present 
on AOO (LO does not
have that problem).

What may be interesting to locate the cause is the information, that AOO/LO 
macros including ooRexx
get dispatched via Java and they work. (MacOS seems to have a quite "special" 
setup for processing
GUI events compared to other platforms, causing this crash.)

Will add these remarks/findings to the respective issues.

---rony


On 31.12.2018 14:25, Rony G. Flatscher wrote:
> On 26.12.2018 15:37, Jim Jagielski wrote:
>> I am looking into the 1st 2 and cannot find, at present, where these vars 
>> are being set... will continue to look.
>>
>>> On Dec 20, 2018, at 10:17 AM, Rony G. Flatscher  
>>> wrote:
>>>
>>> Peter,
>>>
>>> as these are different problems to issue 117961 I opened three separate new 
>>> issues for them to allow
>>> to evaluate and trace them individually:
>>>
>>>  * MacOS: PATH wrongly set for scripts: 
>>> 
>>>  * MacOS: Current directory wrongly set to root directory "/" for scripts:
>>>
>>>  * MacOS: Running via Java causes exception on MacOSX Mojave:
>>>
>>>
>>> Once the critical PATH issue (127965 above) gets resolved, I will become 
>>> able to test issue 117961
>>> again and in case it still is a problem then, I would re-open it.
>>>
>>> ---rony
> ... cut ...
>
> On further testing both, PATH (issue 127965) and current home directory 
> (issue 127966), may have the
> same cause.
>
> When starting AOO from the Apple terminal (command line), the environment is 
> untouched and therefore
> everything can work.
>
> However, if starting the AOO instance from the Apple menu (Application folder 
> and clicking on
> OpenOffice.org to start it), then the environment gets crippled 
> unfortunately, causing
> incomplete/wrong/wiped out environment values.
>
> So speculating that the installation setups scripts that cripple the 
> environment AOO gets started in.
>
> Will update the above two issues to point to each other and supply a 
> Beanshell macro that reads the
> environment settings and writes them into its swriter document. Supplying 
>

Re: Ad Apple''s setup for the (Java) scripting framework

[Rony G. Flatscher]

On 26.12.2018 15:37, Jim Jagielski wrote:
> I am looking into the 1st 2 and cannot find, at present, where these vars are 
> being set... will continue to look.
>
>> On Dec 20, 2018, at 10:17 AM, Rony G. Flatscher  
>> wrote:
>>
>> Peter,
>>
>> as these are different problems to issue 117961 I opened three separate new 
>> issues for them to allow
>> to evaluate and trace them individually:
>>
>>  * MacOS: PATH wrongly set for scripts: 
>> 
>>  * MacOS: Current directory wrongly set to root directory "/" for scripts:
>>
>>  * MacOS: Running via Java causes exception on MacOSX Mojave:
>>
>>
>> Once the critical PATH issue (127965 above) gets resolved, I will become 
>> able to test issue 117961
>> again and in case it still is a problem then, I would re-open it.
>>
>> ---rony

... cut ...

On further testing both, PATH (issue 127965) and current home directory (issue 
127966), may have the
same cause.

When starting AOO from the Apple terminal (command line), the environment is 
untouched and therefore
everything can work.

However, if starting the AOO instance from the Apple menu (Application folder 
and clicking on
OpenOffice.org to start it), then the environment gets crippled unfortunately, 
causing
incomplete/wrong/wiped out environment values.

So speculating that the installation setups scripts that cripple the 
environment AOO gets started in.

Will update the above two issues to point to each other and supply a Beanshell 
macro that reads the
environment settings and writes them into its swriter document. Supplying also 
the two AOO swriter
documents, one being off the "command line AOO", one being off the "menu AOO".

---rony

P.S.: On Windows (this is still with AOO 4.1.5) the environment remains intact 
when starting AOO
from the Windows menu. This should be also the case for the Unix based AOO 
installations.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Ad Apple''s setup for the (Java) scripting framework

[Jim Jagielski]

I am looking into the 1st 2 and cannot find, at present, where these vars are 
being set... will continue to look.

> On Dec 20, 2018, at 10:17 AM, Rony G. Flatscher  
> wrote:
> 
> Peter,
> 
> as these are different problems to issue 117961 I opened three separate new 
> issues for them to allow
> to evaluate and trace them individually:
> 
>  * MacOS: PATH wrongly set for scripts: 
> 
>  * MacOS: Current directory wrongly set to root directory "/" for scripts:
>
>  * MacOS: Running via Java causes exception on MacOSX Mojave:
>
> 
> Once the critical PATH issue (127965 above) gets resolved, I will become able 
> to test issue 117961
> again and in case it still is a problem then, I would re-open it.
> 
> ---rony
> 
> 
> On 19.12.2018 18:22, Peter Kovacs wrote:
>> Since it has been closed because of lack of response, just reopen it and
>> continue.
>> 
>> 
>> On 19.12.18 18:06, Rony G. Flatscher (Apache) wrote:
>>> While re-assessing the (Java based) scripting framework on Apple (checking 
>>> on
>>> ) for AOO 4.1.6 the 
>>> following problems could be
>>> isolated:
>>> 
>>>  * the PATH environment variable on MacOS gets tampered with, such that 
>>> executables in
>>>"/usr/local/bin" cannot be resolved, breaking the long standing 
>>> scripting support for ooRexx
>>>  o AOO 4.1.6 on Darwin sets the PATH environment variable to
>>>.:/usr/bin:/bin:/usr/sbin:/sbin
>>>rather, it should just leave the PATH environment variable intact as 
>>> is the case on AOO
>>>4.1.6 for Linux
>>> 
>>>As Apple has forced third party software to install to "/usr/local" a 
>>> few years ago, at least
>>>"/usr/local/bin" needs to be available at all times as well! (Better 
>>> would be the user's PATH
>>>value like on Linux.)
>>> 
>>>  * the current directory is set to the root directory "/" rather than to 
>>> the user's home directory
>>>like on Linux
>>> 
>>> ---
>>> 
>>> Another observation that pertains to Apple only: interacting with AOO using 
>>> the Java archives
>>> (juh.jar, unoil.jar, ridl.jar, jurt.jar) from Java now causes a runtime 
>>> exception on Apple with Java
>>> 9. Not sure whether this is the Apple AOO or the Java responsibility (it 
>>> used to work in the past
>>> years).
>>> 
>>> Here the trace of the exception (RexxDispatcher.java is the Java program 
>>> that will invoke the ooRexx
>>> scripting engine which itself uses a Java bridge that interacts with AOO 
>>> via Java):
>>> 
>>>wu114215:test rony$ rexxj.sh OpenOfficeTest.rex 
>>>*CE> 2018-12-18 16:06:25.356 soffice[6648:119551] WARNING: NSWindow drag 
>>> regions should only be
>>>invalidated on the Main Thread! This will throw an exception in the 
>>> future. Called from (***CE>  0   AppKit  
>>> 0x7fff381bdccc -[NSWindow(NSWindow_Theme) 
>>> _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
>>>CE>  1   AppKit  0x7fff381bb07c 
>>> -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
>>>CE>  2   AppKit  0x7fff381baaa6 
>>> -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
>>>CE>  3   libvcl.dylib0x0001118d5286 
>>> -[SalFrameWindow initWithSalFrame:] + 262
>>>CE>  4   libvcl.dylib0x00011160e273 
>>> _ZN12AquaSalFrame17initWindowAndViewEv + 643
>>>CE>  5   libvcl.dylib0x00011160deb7 
>>> _ZN12AquaSalFrameC2EP8SalFramem + 519
>>>CE>  6   libvcl.dylib0x0001115e93f0 
>>> _ZN15AquaSalInstance11CreateFrameEP8SalFramem + 48
>>>CE>  7   libvcl.dylib0x00011189f567 
>>> _ZN6Window8ImplInitEPS_lP16SystemParentData + 1159
>>>CE>  8   libvcl.dylib0x000111823184 
>>> _ZN16ImplBorderWindow8ImplInitEP6WindowltP16SystemParentData + 404
>>>CE>  9   libvcl.dylib0x0001118234c5 
>>> _ZN16ImplBorderWindowC1EP6WindowP16SystemParentDatalt + 69
>>>CE>  10  libvcl.dylib0x0001118bef78 
>>> _ZN10WorkWindow8ImplInitEP6WindowlP16SystemParentData + 88
>>>CE>  11  libvcl.dylib0x0001118bf320 
>>> _ZN10WorkWindowC1EP6Windowl + 80
>>>CE>  12  libootk.dylib   0x0001109420c0 
>>> _ZN11VCLXToolkit16ImplCreateWindowEPP10VCLXWindowRKN3com3sun4star3awt16WindowDescriptorEP6Windowl
>>>  + 5712
>>>CE>  13  libootk.dylib   0x000110940454 
>>> _ZN11VCLXToolkit16ImplCreateWindowERKN3com3sun4star3awt16WindowDescriptorEl 
>>> + 452
>>>CE>  14  libootk.dylib   0x000110940

Re: Ad Apple''s setup for the (Java) scripting framework

[Rony G. Flatscher]

Peter,

as these are different problems to issue 117961 I opened three separate new 
issues for them to allow
to evaluate and trace them individually:

  * MacOS: PATH wrongly set for scripts: 

  * MacOS: Current directory wrongly set to root directory "/" for scripts:

  * MacOS: Running via Java causes exception on MacOSX Mojave:


Once the critical PATH issue (127965 above) gets resolved, I will become able 
to test issue 117961
again and in case it still is a problem then, I would re-open it.

---rony


On 19.12.2018 18:22, Peter Kovacs wrote:
> Since it has been closed because of lack of response, just reopen it and
> continue.
>
>
> On 19.12.18 18:06, Rony G. Flatscher (Apache) wrote:
>> While re-assessing the (Java based) scripting framework on Apple (checking on
>> ) for AOO 4.1.6 the 
>> following problems could be
>> isolated:
>>
>>   * the PATH environment variable on MacOS gets tampered with, such that 
>> executables in
>> "/usr/local/bin" cannot be resolved, breaking the long standing 
>> scripting support for ooRexx
>>   o AOO 4.1.6 on Darwin sets the PATH environment variable to
>> .:/usr/bin:/bin:/usr/sbin:/sbin
>> rather, it should just leave the PATH environment variable intact as 
>> is the case on AOO
>> 4.1.6 for Linux
>>
>> As Apple has forced third party software to install to "/usr/local" a 
>> few years ago, at least
>> "/usr/local/bin" needs to be available at all times as well! (Better 
>> would be the user's PATH
>> value like on Linux.)
>>
>>   * the current directory is set to the root directory "/" rather than to 
>> the user's home directory
>> like on Linux
>>
>> ---
>>
>> Another observation that pertains to Apple only: interacting with AOO using 
>> the Java archives
>> (juh.jar, unoil.jar, ridl.jar, jurt.jar) from Java now causes a runtime 
>> exception on Apple with Java
>> 9. Not sure whether this is the Apple AOO or the Java responsibility (it 
>> used to work in the past
>> years).
>>
>> Here the trace of the exception (RexxDispatcher.java is the Java program 
>> that will invoke the ooRexx
>> scripting engine which itself uses a Java bridge that interacts with AOO via 
>> Java):
>>
>> wu114215:test rony$ rexxj.sh OpenOfficeTest.rex 
>> *CE> 2018-12-18 16:06:25.356 soffice[6648:119551] WARNING: NSWindow drag 
>> regions should only be
>> invalidated on the Main Thread! This will throw an exception in the 
>> future. Called from (***CE>  0   AppKit  
>> 0x7fff381bdccc -[NSWindow(NSWindow_Theme) 
>> _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
>> CE>  1   AppKit  0x7fff381bb07c 
>> -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
>> CE>  2   AppKit  0x7fff381baaa6 
>> -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
>> CE>  3   libvcl.dylib0x0001118d5286 
>> -[SalFrameWindow initWithSalFrame:] + 262
>> CE>  4   libvcl.dylib0x00011160e273 
>> _ZN12AquaSalFrame17initWindowAndViewEv + 643
>> CE>  5   libvcl.dylib0x00011160deb7 
>> _ZN12AquaSalFrameC2EP8SalFramem + 519
>> CE>  6   libvcl.dylib0x0001115e93f0 
>> _ZN15AquaSalInstance11CreateFrameEP8SalFramem + 48
>> CE>  7   libvcl.dylib0x00011189f567 
>> _ZN6Window8ImplInitEPS_lP16SystemParentData + 1159
>> CE>  8   libvcl.dylib0x000111823184 
>> _ZN16ImplBorderWindow8ImplInitEP6WindowltP16SystemParentData + 404
>> CE>  9   libvcl.dylib0x0001118234c5 
>> _ZN16ImplBorderWindowC1EP6WindowP16SystemParentDatalt + 69
>> CE>  10  libvcl.dylib0x0001118bef78 
>> _ZN10WorkWindow8ImplInitEP6WindowlP16SystemParentData + 88
>> CE>  11  libvcl.dylib0x0001118bf320 
>> _ZN10WorkWindowC1EP6Windowl + 80
>> CE>  12  libootk.dylib   0x0001109420c0 
>> _ZN11VCLXToolkit16ImplCreateWindowEPP10VCLXWindowRKN3com3sun4star3awt16WindowDescriptorEP6Windowl
>>  + 5712
>> CE>  13  libootk.dylib   0x000110940454 
>> _ZN11VCLXToolkit16ImplCreateWindowERKN3com3sun4star3awt16WindowDescriptorEl 
>> + 452
>> CE>  14  libootk.dylib   0x0001109407b4 
>> _ZThn80_N11VCLXToolkit12createWindowERKN3com3sun4star3awt16WindowDescriptorE 
>> + 20
>> CE>  15  libfwk.dylib0x000113f2d84e 
>> _ZN9framework18TaskCreatorService28implts_createContainerWindowERKN3com3sun4star3uno9ReferenceINS3_3awt7XWindow

Re: Ad Apple''s setup for the (Java) scripting framework

[Peter Kovacs]

Since it has been closed because of lack of response, just reopen it and
continue.


On 19.12.18 18:06, Rony G. Flatscher (Apache) wrote:
> While re-assessing the (Java based) scripting framework on Apple (checking on
> ) for AOO 4.1.6 the 
> following problems could be
> isolated:
>
>   * the PATH environment variable on MacOS gets tampered with, such that 
> executables in
> "/usr/local/bin" cannot be resolved, breaking the long standing scripting 
> support for ooRexx
>   o AOO 4.1.6 on Darwin sets the PATH environment variable to
> .:/usr/bin:/bin:/usr/sbin:/sbin
> rather, it should just leave the PATH environment variable intact as 
> is the case on AOO
> 4.1.6 for Linux
>
> As Apple has forced third party software to install to "/usr/local" a few 
> years ago, at least
> "/usr/local/bin" needs to be available at all times as well! (Better 
> would be the user's PATH
> value like on Linux.)
>
>   * the current directory is set to the root directory "/" rather than to the 
> user's home directory
> like on Linux
>
> ---
>
> Another observation that pertains to Apple only: interacting with AOO using 
> the Java archives
> (juh.jar, unoil.jar, ridl.jar, jurt.jar) from Java now causes a runtime 
> exception on Apple with Java
> 9. Not sure whether this is the Apple AOO or the Java responsibility (it used 
> to work in the past
> years).
>
> Here the trace of the exception (RexxDispatcher.java is the Java program that 
> will invoke the ooRexx
> scripting engine which itself uses a Java bridge that interacts with AOO via 
> Java):
>
> wu114215:test rony$ rexxj.sh OpenOfficeTest.rex 
> *CE> 2018-12-18 16:06:25.356 soffice[6648:119551] WARNING: NSWindow drag 
> regions should only be
> invalidated on the Main Thread! This will throw an exception in the 
> future. Called from (***CE>   0   AppKit  
> 0x7fff381bdccc -[NSWindow(NSWindow_Theme) 
> _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
> CE>   1   AppKit  0x7fff381bb07c 
> -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
> CE>   2   AppKit  0x7fff381baaa6 
> -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
> CE>   3   libvcl.dylib0x0001118d5286 
> -[SalFrameWindow initWithSalFrame:] + 262
> CE>   4   libvcl.dylib0x00011160e273 
> _ZN12AquaSalFrame17initWindowAndViewEv + 643
> CE>   5   libvcl.dylib0x00011160deb7 
> _ZN12AquaSalFrameC2EP8SalFramem + 519
> CE>   6   libvcl.dylib0x0001115e93f0 
> _ZN15AquaSalInstance11CreateFrameEP8SalFramem + 48
> CE>   7   libvcl.dylib0x00011189f567 
> _ZN6Window8ImplInitEPS_lP16SystemParentData + 1159
> CE>   8   libvcl.dylib0x000111823184 
> _ZN16ImplBorderWindow8ImplInitEP6WindowltP16SystemParentData + 404
> CE>   9   libvcl.dylib0x0001118234c5 
> _ZN16ImplBorderWindowC1EP6WindowP16SystemParentDatalt + 69
> CE>   10  libvcl.dylib0x0001118bef78 
> _ZN10WorkWindow8ImplInitEP6WindowlP16SystemParentData + 88
> CE>   11  libvcl.dylib0x0001118bf320 
> _ZN10WorkWindowC1EP6Windowl + 80
> CE>   12  libootk.dylib   0x0001109420c0 
> _ZN11VCLXToolkit16ImplCreateWindowEPP10VCLXWindowRKN3com3sun4star3awt16WindowDescriptorEP6Windowl
>  + 5712
> CE>   13  libootk.dylib   0x000110940454 
> _ZN11VCLXToolkit16ImplCreateWindowERKN3com3sun4star3awt16WindowDescriptorEl + 
> 452
> CE>   14  libootk.dylib   0x0001109407b4 
> _ZThn80_N11VCLXToolkit12createWindowERKN3com3sun4star3awt16WindowDescriptorE 
> + 20
> CE>   15  libfwk.dylib0x000113f2d84e 
> _ZN9framework18TaskCreatorService28implts_createContainerWindowERKN3com3sun4star3uno9ReferenceINS3_3awt7XWindowEEERKNS6_9RectangleEh
>  + 1022
> CE>   16  libfwk.dylib0x000113f2cecc 
> _ZN9framework18TaskCreatorService27createInstanceWithArgumentsERKN3com3sun4star3uno8SequenceINS4_3AnyEEE
>  + 924
> CE>   17  libfwk.dylib0x000113f2ecd2 
> _ZThn16_N9framework18TaskCreatorService27createInstanceWithArgumentsERKN3com3sun4star3uno8SequenceINS4_3AnyEEE
>  + 18
> CE>   18  libfwk.dylib0x000113e34591 
> _ZN9framework11TaskCreator10createTaskERKN3rtl8OUStringEh + 3089
> CE>   19  libfwk.dylib0x000113efbd9a 
> _ZN9framework7Desktop9findFrameERKN3rtl8OUStringEi + 778
> CE>   20  libfwk.dylib0x000113efc3b2 
> _ZThn56_

Ad Apple''s setup for the (Java) scripting framework

[Rony G. Flatscher (Apache)]

While re-assessing the (Java based) scripting framework on Apple (checking on
) for AOO 4.1.6 the following 
problems could be
isolated:

  * the PATH environment variable on MacOS gets tampered with, such that 
executables in
"/usr/local/bin" cannot be resolved, breaking the long standing scripting 
support for ooRexx
  o AOO 4.1.6 on Darwin sets the PATH environment variable to
.:/usr/bin:/bin:/usr/sbin:/sbin
rather, it should just leave the PATH environment variable intact as is 
the case on AOO
4.1.6 for Linux

As Apple has forced third party software to install to "/usr/local" a few 
years ago, at least
"/usr/local/bin" needs to be available at all times as well! (Better would 
be the user's PATH
value like on Linux.)

  * the current directory is set to the root directory "/" rather than to the 
user's home directory
like on Linux

---

Another observation that pertains to Apple only: interacting with AOO using the 
Java archives
(juh.jar, unoil.jar, ridl.jar, jurt.jar) from Java now causes a runtime 
exception on Apple with Java
9. Not sure whether this is the Apple AOO or the Java responsibility (it used 
to work in the past
years).

Here the trace of the exception (RexxDispatcher.java is the Java program that 
will invoke the ooRexx
scripting engine which itself uses a Java bridge that interacts with AOO via 
Java):

wu114215:test rony$ rexxj.sh OpenOfficeTest.rex 
*CE> 2018-12-18 16:06:25.356 soffice[6648:119551] WARNING: NSWindow drag 
regions should only be
invalidated on the Main Thread! This will throw an exception in the future. 
Called from (***CE> 0   AppKit  
0x7fff381bdccc -[NSWindow(NSWindow_Theme) 
_postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
CE> 1   AppKit  0x7fff381bb07c 
-[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
CE> 2   AppKit  0x7fff381baaa6 
-[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
CE> 3   libvcl.dylib0x0001118d5286 
-[SalFrameWindow initWithSalFrame:] + 262
CE> 4   libvcl.dylib0x00011160e273 
_ZN12AquaSalFrame17initWindowAndViewEv + 643
CE> 5   libvcl.dylib0x00011160deb7 
_ZN12AquaSalFrameC2EP8SalFramem + 519
CE> 6   libvcl.dylib0x0001115e93f0 
_ZN15AquaSalInstance11CreateFrameEP8SalFramem + 48
CE> 7   libvcl.dylib0x00011189f567 
_ZN6Window8ImplInitEPS_lP16SystemParentData + 1159
CE> 8   libvcl.dylib0x000111823184 
_ZN16ImplBorderWindow8ImplInitEP6WindowltP16SystemParentData + 404
CE> 9   libvcl.dylib0x0001118234c5 
_ZN16ImplBorderWindowC1EP6WindowP16SystemParentDatalt + 69
CE> 10  libvcl.dylib0x0001118bef78 
_ZN10WorkWindow8ImplInitEP6WindowlP16SystemParentData + 88
CE> 11  libvcl.dylib0x0001118bf320 
_ZN10WorkWindowC1EP6Windowl + 80
CE> 12  libootk.dylib   0x0001109420c0 
_ZN11VCLXToolkit16ImplCreateWindowEPP10VCLXWindowRKN3com3sun4star3awt16WindowDescriptorEP6Windowl
 + 5712
CE> 13  libootk.dylib   0x000110940454 
_ZN11VCLXToolkit16ImplCreateWindowERKN3com3sun4star3awt16WindowDescriptorEl + 
452
CE> 14  libootk.dylib   0x0001109407b4 
_ZThn80_N11VCLXToolkit12createWindowERKN3com3sun4star3awt16WindowDescriptorE + 
20
CE> 15  libfwk.dylib0x000113f2d84e 
_ZN9framework18TaskCreatorService28implts_createContainerWindowERKN3com3sun4star3uno9ReferenceINS3_3awt7XWindowEEERKNS6_9RectangleEh
 + 1022
CE> 16  libfwk.dylib0x000113f2cecc 
_ZN9framework18TaskCreatorService27createInstanceWithArgumentsERKN3com3sun4star3uno8SequenceINS4_3AnyEEE
 + 924
CE> 17  libfwk.dylib0x000113f2ecd2 
_ZThn16_N9framework18TaskCreatorService27createInstanceWithArgumentsERKN3com3sun4star3uno8SequenceINS4_3AnyEEE
 + 18
CE> 18  libfwk.dylib0x000113e34591 
_ZN9framework11TaskCreator10createTaskERKN3rtl8OUStringEh + 3089
CE> 19  libfwk.dylib0x000113efbd9a 
_ZN9framework7Desktop9findFrameERKN3rtl8OUStringEi + 778
CE> 20  libfwk.dylib0x000113efc3b2 
_ZThn56_N9framework7Desktop9findFrameERKN3rtl8OUStringEi + 18
CE> 21  libfwk.dylib0x000113eb53ce 
_ZN9framework7LoadEnv16impl_loadContentEv + 766
CE> 22  libfwk.dylib0x000113eb0e56 
_ZN9framework7LoadEnv