RE: EXTERNAL: Re: Extension Manager Add Crashes

2014-04-11 Thread Steele, Raymond
Carl, no message. Just a crash of the AOO suite.

-Original Message-
From: Carl Marcum [mailto:cmar...@apache.org] 
Sent: Thursday, April 10, 2014 5:51 PM
To: api@openoffice.apache.org; d...@openoffice.apache.org
Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes

On 04/10/2014 07:15 PM, Steele, Raymond wrote:
 Carl,

 I have the new Netbeans plugin. I created a new Add-on project (just an empty 
 one that does nothing), compiled and generated the .OXT. The Extension 
 manager still rejects it and OpenOffice crashes. I was able to install the 
 extension mentioned here with success.

 https://issues.apache.org/ooo/show_bug.cgi?id=121577

 -Original Message-
 From: Carl Marcum [mailto:cmar...@apache.org]
 Sent: Thursday, April 10, 2014 2:55 PM
 To: d...@openoffice.apache.org
 Cc: api@openoffice.apache.org
 Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes

 On 04/10/2014 03:31 PM, Steele, Raymond wrote:
 I am cross posting here since I am not getting  much traction on the 
 dev list and it appears it may be API related. I have an add-on that 
 I developed using the Netbeans Openiffice module. This .oxt file 
 works fine on AOO 3.3, but since I switched to AOO 4.0.1 and after a 
 recompile, the Extension Manager will not take my add-on (see below 
 please). However, the extension manager will take the module located 
 http://extensions.openoffice.org/en/project/english-dictionaries-apac
 h
 e-openoffice

 Is there anything that the new AOO needs configured within the .oxt that was 
 not needed in 3.3? Any help would be great!

 -Original Message-
 From: Steele, Raymond
 Sent: Wednesday, April 09, 2014 8:08 AM
 To: d...@openoffice.apache.org
 Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes

 Thanks. I am using Java. The extension I have works on my Solaris 10 
 OpenOffice 3.3 instance, but not on my Solaris 11 4.0.1 instance. I used the 
 OpenOffice Netbeans module to create the Add-on.

 -Original Message-
 From: J├╝rgen Schmidt [mailto:jogischm...@gmail.com]
 Sent: Tuesday, April 08, 2014 11:16 PM
 To: d...@openoffice.apache.org
 Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes

 On 4/8/14 11:49 PM, Steele, Raymond wrote:
 I installed the extension located at the following link with success, so 
 what is wrong with my extension

 http://extensions.openoffice.org/en/project/english-dictionaries-apa
 c
 h
 e-openoffice

 it's difficult to say without having the code, you can easy make mistakes 
 with extensions.

 I haven't followed the thread in detail but maybe you can describe in 
 a few sentences what exactly you try

 - which programming language do you use
 - which kind of extension, an add-on, a calc add-in, ...
 - ...

 Juergen




 -Original Message-
 From: Steele, Raymond
 Sent: Tuesday, April 08, 2014 10:31 AM
 To: 'd...@openoffice.apache.org'
 Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes

 Is there any one that is familiar with this code and able to lend a hand. I 
 do not understand what is going on here.  I suspect that the crash is 
 cpp_vtable_call is due to a RuntimeException thrown in Reference.hxx 
 because pQueried is equal to (nil). Here is the  stack trace leading up to 
 the RunTimeException during the registration of my .oxt file.

 =[1] com::sun::star::uno::BaseReference::iquery_throw(pInterface = 
 0x9e348ac, rType = CLASS), line 81 in Reference.hxx
[2] 
 dp_registry::backend::component::_unamed_AjaA7n_a0TEvD::BackendImpl::ComponentPackageImpl::processPackage_(this
  = 0xea4f9a88,   _ARG2 = CLASS, doRegisterPackge = true, startup = false, 
 abortChannel = CLASS, xCmdEnv = CLASS), line 1554 in dp_component.cxx
[3] dp_registry::backend::Package::processPackage_Impl(this = 
 0xea4f9a88, doRegisterPackage = true, startup = false, xAbortChannel = 
 CLASS, xCmdEnv = CLASS), line 675 in dp_backend.cxx
[4] dp_registy::backend::Package::registerPackage(this = 0xe9b94c58, 
 startup = '\0', xAbortChannel = CLASS, xCmdEnv = CALSS), line 725 in 
 dp_backend.cxx

 I really need to get over this hurdle.

 -Original Message-
 From: Steele, Raymond
 Sent: Friday, April 04, 2014 5:52 PM
 To: d...@openoffice.apache.org
 Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes

 I am still plugging away at this issue. This is what I have determined.  
 addExtension is called in dp_extensionmanager.cxx. However,  a 
 RuntimeException is thrown somewhere and caught on line 819.  Then on line 
 830,  the code then tries to recover the original status  then call 
 activateExtension, which then leads up to the crash, which happens after an 
 attempt to register and process the package in dp_component.cxx. I am not 
 sure if the initial RuntimeException is causing the problem, but something 
 is not correct.  Here is high level stack trace (typed out).

 [1] cpp_vtable_call(nFunctionIndex = 3, nVtableOffset = 0, pCallStack = 
 0xe90acea8, nRegReturn = -1649035904490436800LL) in cpp2uno.cxx

RE: EXTERNAL: Re: DisposedException

2014-03-06 Thread Steele, Raymond
 = 
UnoRuntime.queryInterface(XCompnent.class, model);
 disposeable.dispose();
  }
   }

   public void ExportDocumentAs(XComponent doc, String save_file, 
DocumentHandler.DocumentSaveFormat format, boolean overwrite, String 
page_range) {
  if((save_file == null) || (save_file.trim().length()) == 0) {
 return;
  }

  if(!overwrite) {
 File sfile = new File(save_file);
 if(sfile.exists()) {
   throw new Exception(File exists);
 }
  }

  DocumentHandler = new DocumentHandler();

  String file_url = handler.convertFIlePAthToUrl(save_file);
  XStoreable store = UnoRuntime.queryInterface(XStoreable.class, 
doc);

  PropertyValue filter_data= new PropertyValue[1];
  loadProps[0] = new PropertyValue();
  loadProps[0].Name = PageRange;
  loadProps[0].Value = page_range;

  PropertyValue loadProps= new PropertyValue[2];
  loadProps[0] = new PropertyValue();
  loadProps[0].Name = FilterName;
  loadProps[0].Value = format.getFormatCode;
  loadProps[1] = new PropertyValue();
  loadProps[1].Name = FilterData;
  loadProps[1].Value = filter_data;

  store.storeToUrl(file_url, loadProps);


   }
}


From: Andre Fischer [mailto:awf@gmail.com]
Sent: Thursday, March 06, 2014 1:24 AM
To: Steele, Raymond; Andre Fischer; api@openoffice.apache.org
Subject: Re: EXTERNAL: Re: DisposedException

On 28.02.2014 20:35, Steele, Raymond wrote:
I am still having issues. I've typed (there may be typos) out most of the code. 
The following code will fail during runtime on the line bolded below. Can 
anyone identify why? Any help would be great!!!

Sorry for the late reply, I am still not scanning api@ every day and my 
thunderbird did not update the count of new mails automatically.

I don't see any obvious error in your Java code.  I also looked into the C++ 
implementation of ScTableSheetObj and did not find anything obvious either.  
The only thing that I can do is to debug the C++ side of the problem, but only 
if you can send me a running version of your extension, stripped down to the 
minimum to reproduce this bug.

The only alternative to that (if you can not provide the extension) then we 
have to rely on collecting more data:

- add an XEventListener to sheets and possibly to doc right after the
 XSpreadsheets sheets = doc.getSheets();
line and see if the disposing() method of the listener is called.

- when the DisposedException is thrown, then look at its Source member (should 
be sheetObj).  I don't expect any surprises there but the check doesn't take 
long.

I am sorry that I can not be of more help.

-Andre



Basically, I am just trying to populate an .ods file's worksheets with data.


   public class Load {
  String master_track_dir = System.getenv(PLN_MASTER_TRK);
  String restore_track = master_track_dir + 
/RAYMOND/restore_track.xml;
  String master_track = master_track_dir + /RAYMOND/track.xml;

   public Load() {

   }

   public static main(String[] args) {
  try {
 Load block = new Load();
 XComponentContext context = Bootstarp.bootstrap();
 if(context == null) {
   System.err.println(ERROR: Could not bootstrap 
default Office);
   System.exit(1);
 }

 XMultiComponentFactory component_factory = 
context.getServiceManager();
 try {
   Object desktop = 
component_factory.createInstanceWithContext(com.sun.star.frame.Desktop, 
context);
   XComponentLoader xComponentLoader = 
UnoRuntime.queryInterface(XComponentLoader.class, desktop);

   PropertyValue loadProps= new PropertyValue[1];
   loadProps[0] = new PropertyValue();
   loadProps[0].Name = Hidden;
   loadProps[0].Value = Boolean.FALSE;

   String odsFile = System.getenv(PLN_DAT_GCFILES) + 
/Track.ods;
   new File(odsFile).delete();
   DocumentHandler otsHandler = new DocumentHandler();
   String otsFile = /tmp/Track.ots;
   String otsUrl = 
otsHandler.convertFilePathToURL(otsFile);
   String odsUrl = 
otsHandler.convertFilePathToURL(odsFile);

   //Load .ots file, opens Untitled 1.ods
   XComponent otsComponent = 
XComponentLoader.loadComponent.loadComponentFromURL(otsUrl, _blank, 0, 
loadProps);
   //export Untitled 1

RE: EXTERNAL: Re: DisposedException

2014-02-28 Thread Steele, Raymond
   sheetObj = sheets.getByName(Oper Data);
   // 
com.sun.star.lang.DisposedException occurs here.//
 sheet = UnoRuntime.queryInterface(XSpreadsheet.class, 
sheetObj);
   cells = UnoRuntime.queryInterface(XCellRange.class, 
sheet);
   range = cells.getCellRangeByName(A2:E11);
   data = 
UnoRuntime.queryInterface(XCellRangeData.class, range);
   data_obj = data.getDataArray();
   //Populate data_obj here. This part omitted for 
clarity an need to manually type.
   data.setDataArray(data_obj);

//Populate worksheet
   sheetObj = sheets.getByName(Param Data);
   sheet = 
UnoRuntime.queryInterface(XSpreadsheet.class, sheetObj);
   cells = UnoRuntime.queryInterface(XCellRange.class, 
sheet);
   range = cells.getCellRangeByName(A2:AW2);
   data = 
UnoRuntime.queryInterface(XCellRangeData.class, range);
   data_obj = data.getDataArray();
   //Populate data_obj here. This part omitted for 
clarity an need to manually type.
   data.setDataArray(data_obj);

//Populate worksheet
   sheetObj = sheets.getByName(Point Data);
   sheet = 
UnoRuntime.queryInterface(XSpreadsheet.class, sheetObj);
   cells = UnoRuntime.queryInterface(XCellRange.class, 
sheet);
   range = cells.getCellRangeByName(A2:AJ151);
   data = 
UnoRuntime.queryInterface(XCellRangeData.class, range);
   data_obj = data.getDataArray();
   //Populate data_obj here. This part omitted for 
clarity an need to manually type.
   data.setDataArray(data_obj);

 } catch(com.sun.star.uno.Exception ex) {
   System.err.println(ex.getMessage());
 } finally {
   System.exit(1);
 }


  }
   }

   public void closeDocument(XComponent document) {
  XModel model = UnoRuntime.queryInterface(XModel.class, document);
  if(model != null) {
 XCloseable closeable = 
UnoRuntime.queryInterface(XCloseable.class, model);
 if(closeable != null) {
   try {
  closeable.close(false);
   } catch (CloseVetoException ex) {
  System.out.println(ex.getMessage());
   }
 }
  } else {
 XComponent disposeable = 
UnoRuntime.queryInterface(XCompnent.class, model);
 disposeable.dispose();
  }
   }

   public void ExportDocumentAs(XComponent doc, String save_file, 
DocumentHandler.DocumentSaveFormat format, boolean overwrite, String 
page_range) {
  if((save_file == null) || (save_file.trim().length()) == 0) {
 return;
  }

  if(!overwrite) {
 File sfile = new File(save_file);
 if(sfile.exists()) {
   throw new Exception(File exists);
 }
  }

  DocumentHandler = new DocumentHandler();

  String file_url = handler.convertFIlePAthToUrl(save_file);
  XStoreable store = UnoRuntime.queryInterface(XStoreable.class, 
doc);

  PropertyValue filter_data= new PropertyValue[1];
  loadProps[0] = new PropertyValue();
  loadProps[0].Name = PageRange;
  loadProps[0].Value = page_range;

  PropertyValue loadProps= new PropertyValue[2];
  loadProps[0] = new PropertyValue();
  loadProps[0].Name = FilterName;
  loadProps[0].Value = format.getFormatCode;
  loadProps[1] = new PropertyValue();
  loadProps[1].Name = FilterData;
  loadProps[1].Value = filter_data;

  store.storeToUrl(file_url, loadProps);


   }
}

From: Andre Fischer [mailto:awf@gmail.com]
Sent: Wednesday, February 26, 2014 3:15 AM
To: Steele, Raymond; Andre Fischer; api@openoffice.apache.org
Subject: Re: EXTERNAL: Re: DisposedException

On 26.02.2014 00:25, Steele, Raymond wrote:

Thanks,



I am not explicitly calling the dispose method .

I would expect that dispose is called by a closing frame or something like that.



Here is an overview of what I am doing.



1.   opening a XSpreadsheetDocument (called temp_doc)  by calling after 
creating an object using  XMultiComponentFactory

OO 4.01 Compiled for Solaris 11 x86 Save As Stuck in a Loop

2014-02-14 Thread Steele, Raymond
We are attempting to use the newly build OpenOffice 4.0.1 for Solaris 11 x86, 
but  the 'Save As' to disk of any document type (i.e. .ods) continuous to 
prompt for a file name.  Each time we hit okay to save the document after 
supplying a unique name, the FilePicker closes, but instantly reappears again.

I have narrowed  it down to the following code located in 
sfx2/source/doc/guisaveas.cxx lines 1497-1520

The program gets stuck in the while loop below.  The variable 'bExit' is never 
set to sal_True, so the loop continuous. I provide a name to the FilePicker 
interface, click Save and the loop continuous, redisplaying the dialog. To 
resolve the issue, I added bExit = sal_True after line 1513 so that the loop 
discontinuous. I am not sure if this will have effects in other situations, 
maybe someone can provide some feedback, but for now. I am able to save.


sal_Bool bExit = sal_False;
1497   while ( !bExit )
1498   {
1499   bUseFilterOptions = aModelData.OutputFileDialog( nStoreMode, 
aFilterProps, bSetStandardName, aSuggestedName, bPreselectPassword, 
aSuggestedDir, nDialog, sStandardDir, aBlackList );
1500
1501   // in case the dialog is opend a second time the folder should be 
the same as before, not what was handed over by parameters
1502   aSuggestedDir = ::rtl::OUString();
1503   if ( nStoreMode == SAVEAS_REQUESTED )
1504   {
1505   // in case of saving check filter for possible alien warning
1506   ::rtl::OUString aSelFilterName = 
aModelData.GetMediaDescr().getUnpackedValueOrDefault(
1507   aFilterNameString,
1508   ::rtl::OUString() );
1509   sal_Int8 nStatusFilterSave = aModelData.CheckFilter( aSelFilterName 
);
1510   if ( nStatusFilterSave == STATUS_SAVEAS_STANDARDNAME ) These are 
equal during runtime
1511   {
1512   // switch to best filter
1513   bSetStandardName = sal_True; bSetStandardName is set to sal_True 
here, but bExit is not, so the loop continuous. Setting bExit following this 
line allows the program to save.
++bExit = salTrue;
1514   }
1515   else if ( nStatusFilterSave == STATUS_SAVE )
1516   {
1517   // user confirmed alien filter or good filter is used
1518   bExit = sal_True;
1519   }
1520   }
1521   else
1522   bExit = sal_True;
1523   }



Raymond Steele
U-2 Mission Planning
Software Engineer Sr
Lockheed Martin - ISGS Defense
1300 S. Litchfield Rd.
Goodyear, AZ 85338
Email: raymond.ste...@lmco.com
Business phone:  623-925-6402



RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault

2014-02-05 Thread Steele, Raymond
Hi Andre,

Thanks for the response. We are looking at that now.

In the constructor of SidebarController at line 168 WeakReference..., on your 
system, does the code step to  Reference.h: Line 359 - XInterface operator, as 
it does during our run?

It appears  that at runtime Reference.hxx: Line 136 - _pInterface-acquire()  
that occurs after WeakReference..  does not  execute as it does after 
addContextChangeEventListener a few lines above WeakReference. Do you see a 
similar behavior?  Can you provide the first 5-10 steps your code takes after 
WeakReference (line 168)?

Thanks!

Raymond

From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.org; Herbert Duerr (h...@apache.org); 
d...@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory 
Fault


Herbert,



Raymond and I have been using the dbx debugger feature of Solaris Studio 12.3 
with an equivalent throw/catch feature (intercept/whocatches) and have found 
that the cases where we tried to intercept exceptions, they were unhandled. 
This includes inside the SidebarController where we have tracked the problem 
origination. We have stepped through the code multiple times and while we have 
found that the problem originates in the SidebarController, we cannot explain 
how it happens.



Using the debug tool we see that the SidebarController constructor doesn't 
complete because the segmentation fault occurs when the 
notifyContextChangeEvent is called a second time. The first time it is called 
it is located in the addContextChangeEventListener where it appears to work as 
expected, even the acquire function appears to call the 
ContextChangeEventMultiplexer without any errors.



The following lines are what we see as we step-by-step through the execution of 
the SidebarController.cxx constructor when we select the Spreadsheet or the 
Text Document.



The first time the notifyContextChangeEvent is called:



SidebarController: Line 147 - addContextChangeEventListener is called

Reference.h: Line 359 - XInterface operator - is called

Reference.h: Line 217 - castFromXInterface is called

Reference.hxx: Line 134 - castToXInterface is called

Reference.h: Line 232 - function castToXInterface

Reference.hxx: Line 135 - if(_pInterface)

Reference.hxx: Line 136 - _pInterface-acquire();

compbase4.hxx: Line 70- WeakComponentHelperBase::acquire prototype

implbase.hxx: Line 236 - WeakObject::acquire definition

-  ContextChangeEventMultiplexer receives and processes event.

-  In ContextChangeEventMultiplexer addContextChangeEventListener 
adds and calls the notifyContextChangeEvent

-  SidebarController::notifyContextChangeEvent: Line 257 is called. 
The rEvent associated with the notifyContextChangeEvent is a valid address

-  The rEvent STRUCT contains the application name and context name 
references

Context.cxx: Line 51 - msContext(rsContext)

ustring.hxx: Line103 - pData = str.pData

-  Processing continues as normal from this point till line 168 of 
SidebarController.cxx



The second time the notifyContextChangeEvent is called:



SidebarController: Line 168 - the xWeakController(this) is called

Reference.hxx: Line 134 - castToXInterface is called

Reference.h: Line 232 - function castToXInterface

Reference.hxx: Line 135 - if(_pInterface)

Reference.hxx: Line 136 - _pInterface-acquire(); (Why does this not behave 
like the first call above? Should there be a call to 
WeakComponentHelperBase::acuire? The next step appears to skip all these 
procedures.)

SidebarController::notifyContextChangeEvent: Line 257 is called, the rEvent is 
pointing to a reference that cannot be accessed.

-  The dbx dump has an rEvent = STRUCT

-  The dbx print of the rEvent says that it is referenced through a 
nil pointer

Context.cxx: Line 51 - msContext(rsContext)

ustring.hxx: Line103 - pData = str.pData

-  Accessing the pData in the string has been corrupted and causes 
the following Segmentation Fault:

-  Signal SEGV(no mapping at the fault address) in 
rtl::OUString::OUString at line 103 in file ustring.hxx



We are trying to do our due diligence on this problem and we have been 
investigating it as best we can, but we are lacking in knowledge that the 
community can provide, which is why we are seeking help. Also the errors don't 
seem to make sense, so we believe we are dealing with a bug. We hope we are not 
being an inconvenience, and we definitely appreciate the help. We are 
investigating alternatives, but would really like to get this to work. Our 
current applications use OpenOffice extensively.  Since we had to move to 
Solaris 11, we are forced to get this working or find another solution, which 
we'd rather not pursue.



Hopefully you or a member of the community can help us make some headway. We'd 
appreciate it. Thanks.



David Meffe

RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault

2014-02-05 Thread Steele, Raymond
Andre,

We are not seeing any exception before the actual crash. Maybe I am not looking 
in the right place, but we've been using dbx intercept command to track any. 
Any other suggestions?

  Also, I've attached the stack trace of the first and second 
notifyContextChangeEvent.  They are different.

Raymond

From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'api@openoffice.apache.org'; Herbert Duerr (h...@apache.org); 
d...@openoffice.apache.org
Cc: Meffe, David K; 'awf@gmail.com'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory 
Fault

Hi Andre,

Thanks for the response. We are looking at that now.

In the constructor of SidebarController at line 168 WeakReference..., on your 
system, does the code step to  Reference.h: Line 359 - XInterface operator, as 
it does during our run?

It appears  that at runtime Reference.hxx: Line 136 - _pInterface-acquire()  
that occurs after WeakReference..  does not  execute as it does after 
addContextChangeEventListener a few lines above WeakReference. Do you see a 
similar behavior?  Can you provide the first 5-10 steps your code takes after 
WeakReference (line 168)?

Thanks!

Raymond

From: Steele, Raymond
Sent: Tuesday, February 04, 2014 3:59 PM
To: api@openoffice.apache.orgmailto:api@openoffice.apache.org; Herbert Duerr 
(h...@apache.orgmailto:h...@apache.org); 
d...@openoffice.apache.orgmailto:d...@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory 
Fault


Herbert,



Raymond and I have been using the dbx debugger feature of Solaris Studio 12.3 
with an equivalent throw/catch feature (intercept/whocatches) and have found 
that the cases where we tried to intercept exceptions, they were unhandled. 
This includes inside the SidebarController where we have tracked the problem 
origination. We have stepped through the code multiple times and while we have 
found that the problem originates in the SidebarController, we cannot explain 
how it happens.



Using the debug tool we see that the SidebarController constructor doesn't 
complete because the segmentation fault occurs when the 
notifyContextChangeEvent is called a second time. The first time it is called 
it is located in the addContextChangeEventListener where it appears to work as 
expected, even the acquire function appears to call the 
ContextChangeEventMultiplexer without any errors.



The following lines are what we see as we step-by-step through the execution of 
the SidebarController.cxx constructor when we select the Spreadsheet or the 
Text Document.



The first time the notifyContextChangeEvent is called:



SidebarController: Line 147 - addContextChangeEventListener is called

Reference.h: Line 359 - XInterface operator - is called

Reference.h: Line 217 - castFromXInterface is called

Reference.hxx: Line 134 - castToXInterface is called

Reference.h: Line 232 - function castToXInterface

Reference.hxx: Line 135 - if(_pInterface)

Reference.hxx: Line 136 - _pInterface-acquire();

compbase4.hxx: Line 70- WeakComponentHelperBase::acquire prototype

implbase.hxx: Line 236 - WeakObject::acquire definition

-  ContextChangeEventMultiplexer receives and processes event.

-  In ContextChangeEventMultiplexer addContextChangeEventListener 
adds and calls the notifyContextChangeEvent

-  SidebarController::notifyContextChangeEvent: Line 257 is called. 
The rEvent associated with the notifyContextChangeEvent is a valid address

-  The rEvent STRUCT contains the application name and context name 
references

Context.cxx: Line 51 - msContext(rsContext)

ustring.hxx: Line103 - pData = str.pData

-  Processing continues as normal from this point till line 168 of 
SidebarController.cxx



The second time the notifyContextChangeEvent is called:



SidebarController: Line 168 - the xWeakController(this) is called

Reference.hxx: Line 134 - castToXInterface is called

Reference.h: Line 232 - function castToXInterface

Reference.hxx: Line 135 - if(_pInterface)

Reference.hxx: Line 136 - _pInterface-acquire(); (Why does this not behave 
like the first call above? Should there be a call to 
WeakComponentHelperBase::acuire? The next step appears to skip all these 
procedures.)

SidebarController::notifyContextChangeEvent: Line 257 is called, the rEvent is 
pointing to a reference that cannot be accessed.

-  The dbx dump has an rEvent = STRUCT

-  The dbx print of the rEvent says that it is referenced through a 
nil pointer

Context.cxx: Line 51 - msContext(rsContext)

ustring.hxx: Line103 - pData = str.pData

-  Accessing the pData in the string has been corrupted and causes 
the following Segmentation Fault:

-  Signal SEGV(no mapping at the fault address) in 
rtl::OUString::OUString at line 103 in file ustring.hxx



We are trying to do our due diligence on this problem and we have been

Solaris Build

2013-08-08 Thread Steele, Raymond
I am trying to build  OpenOffice 4.0 for Solaris x86. I finally go through 
installing all the pre-requisites, configure and bootstrap, but now I am having 
trouble with the build --all.  I am receiving the following error on execution:

Entering ../main/solenv
dmake: ../solenv/inc/startup.mk: line 43: Error: -- Expecting macro or rule 
defn, found neither

1 module(s):
solenv
need(s) to be rebuilt

Reason(s):

Error: error 65280 occurred while making ../main/solenv


I have seen that people recommended changing make='make' in the Config.pm file 
for perl to make='dmake'. I've tried, but that does not make a difference. Any 
help would be appreciated.


Raymond



RE: Solaris Build

2013-08-08 Thread Steele, Raymond
dmake is failing on the line 43 of startup.mk. Anyone know why dmake would fail 
on the following:

.IMPORT .IGNORE : .EVERYTHING

From: Steele, Raymond
Sent: Thursday, August 08, 2013 9:42 AM
To: d...@openoffice.apache.org; api@openoffice.apache.org
Subject: Solaris Build

I am trying to build  OpenOffice 4.0 for Solaris x86. I finally go through 
installing all the pre-requisites, configure and bootstrap, but now I am having 
trouble with the build --all.  I am receiving the following error on execution:

Entering ../main/solenv
dmake: ../solenv/inc/startup.mk: line 43: Error: -- Expecting macro or rule 
defn, found neither

1 module(s):
solenv
need(s) to be rebuilt

Reason(s):

Error: error 65280 occurred while making ../main/solenv


I have seen that people recommended changing make='make' in the Config.pm file 
for perl to make='dmake'. I've tried, but that does not make a difference. Any 
help would be appreciated.


Raymond



RE: EXTERNAL: Re: soffice process still running

2013-05-06 Thread Steele, Raymond
Ariel, 

 I am having a case were the process continues to run. I appears the the 
EnumerationAccess does have elements, causing the desktop not to terminate. Is 
there a way to terminate a specific desktop that was not last open, and not 
close other desktops?

Raymond

-Original Message-
From: Steele, Raymond 
Sent: Monday, February 04, 2013 1:45 PM
To: 'api@openoffice.apache.org'
Subject: RE: EXTERNAL: Re: soffice process still running

Ariel, 

I am not sure I understand why the following causes only the last opened 
document to close, but it seems to be the solution.

if (!xEnumerationAccess.hasElements()) {
xDesktop.terminate();

Thanks!

Raymond

-Original Message-
From: Ariel Constenla-Haile [mailto:arie...@apache.org]
Sent: Friday, February 01, 2013 5:24 AM
To: api@openoffice.apache.org
Subject: Re: EXTERNAL: Re: soffice process still running

On Thu, Jan 31, 2013 at 05:48:11PM +, Steele, Raymond wrote:
 Thanks for the feedback. 
 
 I implemented the following, but the method kills off any other 
 instance of soffice that is running.
 
 Desktop_obj
 =
 component_factory.createInstanceWithContext(com.sun.star.frame.Deskto
 p, context); XDesktop desktop =
 UnoRuntime.queryInterface(XDesktop.class,
 desktop_obj); desktop.terminate();
 
 Any way that I can close the instance without killing off other 
 soffice instances?

What do you mean by instance? There is only one instance of soffice.bin per 
application using the same user installation directory.

If you mean that it closes all other documents, then you can check if this 
document is the last opened document, and if true, terminate the
desktop:
http://www.openoffice.org/api/docs/common/ref/com/sun/star/frame/XDesktop.html#getComponents

XComponentLoader xComponentLoader = UnoRuntime.queryInterface(
XComponentLoader.class,
xContext.getServiceManager().createInstanceWithContext(
com.sun.star.frame.Desktop, xContext)); XTextDocument xTextDocument = 
UnoRuntime.queryInterface(
 XTextDocument.class,
 xComponentLoader.loadComponentFromURL(
private:factory/swriter,
_default,
FrameSearchFlag.ALL,
new PropertyValue[]{}));
xTextDocument.getText().setString(Dummy text.);

XCloseable xCloseable = UnoRuntime.queryInterface(
XCloseable.class, xTextDocument);
xCloseable.close(true);

XDesktop xDesktop = UnoRuntime.queryInterface(
XDesktop.class, xComponentLoader);
XEnumerationAccess xEnumerationAccess = xDesktop.getComponents();

if (!xEnumerationAccess.hasElements()) {
xDesktop.terminate();
}


Regards
--
Ariel Constenla-Haile
La Plata, Argentina

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



RE: EXTERNAL: Re: soffice process still running

2013-02-04 Thread Steele, Raymond
Ariel, 

I am not sure I understand why the following causes only the last opened 
document to close, but it seems to be the solution.

if (!xEnumerationAccess.hasElements()) {
xDesktop.terminate();

Thanks!

Raymond

-Original Message-
From: Ariel Constenla-Haile [mailto:arie...@apache.org] 
Sent: Friday, February 01, 2013 5:24 AM
To: api@openoffice.apache.org
Subject: Re: EXTERNAL: Re: soffice process still running

On Thu, Jan 31, 2013 at 05:48:11PM +, Steele, Raymond wrote:
 Thanks for the feedback. 
 
 I implemented the following, but the method kills off any other 
 instance of soffice that is running.
 
 Desktop_obj
 = 
 component_factory.createInstanceWithContext(com.sun.star.frame.Deskto
 p, context); XDesktop desktop = 
 UnoRuntime.queryInterface(XDesktop.class,
 desktop_obj); desktop.terminate();
 
 Any way that I can close the instance without killing off other 
 soffice instances?

What do you mean by instance? There is only one instance of soffice.bin per 
application using the same user installation directory.

If you mean that it closes all other documents, then you can check if this 
document is the last opened document, and if true, terminate the
desktop:
http://www.openoffice.org/api/docs/common/ref/com/sun/star/frame/XDesktop.html#getComponents

XComponentLoader xComponentLoader = UnoRuntime.queryInterface(
XComponentLoader.class,
xContext.getServiceManager().createInstanceWithContext(
com.sun.star.frame.Desktop, xContext)); XTextDocument xTextDocument = 
UnoRuntime.queryInterface(
 XTextDocument.class,
 xComponentLoader.loadComponentFromURL(
private:factory/swriter,
_default,
FrameSearchFlag.ALL,
new PropertyValue[]{}));
xTextDocument.getText().setString(Dummy text.);

XCloseable xCloseable = UnoRuntime.queryInterface(
XCloseable.class, xTextDocument);
xCloseable.close(true);

XDesktop xDesktop = UnoRuntime.queryInterface(
XDesktop.class, xComponentLoader);
XEnumerationAccess xEnumerationAccess = xDesktop.getComponents();

if (!xEnumerationAccess.hasElements()) {
xDesktop.terminate();
}


Regards
--
Ariel Constenla-Haile
La Plata, Argentina


RE: EXTERNAL: Re: soffice process still running

2013-01-31 Thread Steele, Raymond
Yes, I seen this article. I guess, I don't understand why we would have to use 
XAsyncJob to close the document, if this is the solution.

-Original Message-
From: Marcin Gutman [mailto:mgut...@op.pl] 
Sent: Wednesday, January 30, 2013 3:51 PM
To: api@openoffice.apache.org; Steele, Raymond
Subject: EXTERNAL: Re: soffice process still running

Hi,

  Any help here would be appreciated.
  xCloseable.close(true) does not kill the soffice process off.
 

I found this:
http://openoffice.2283327.n4.nabble.com/Instance-of-soffice-bin-remains-running-after-closing-OOo-td3032232.html

Quotation:

I solved the problem (or would that be a workaround) by adding an XAsyncJob 
that is called OnPrepareUnload which does an
XCloseable-close() on background.odt This is called earlier than the
destructor and everything closes cleanly as expected.

Best Regards,
Marcin