RE: Simple code practice to get started
Dear Dennis Thank you for looking at this problem. Please forgive the length of the following e-mail; I suspect that when I have mastered the environmental set-up of OpenOffice, then likely any subsequewnt questions I can answer myself and will be far shorter. From what you are saying, I think that although I may have re-built the relevant modules where I changed the code, this of course did not carry over to the already-installed software on Windows which I installed immediately following the first complete build. I have located using 'find' three 'soffice.bin' files in the following directories of the code source: ./main/desktop/wntmsci12.pro/bin/soffice.bin ./main/instsetoo_native/wntmsci12.pro/Apache_OpenOffice/msi/patchsoname_file/en-US/00/soffice.bin ./main/solver/411/wntmsci12.pro/bin/soffice.bin Only the 'soffice.bin' in the second path above shows a file date of today, which would indicate that it has been changed by the re-build of changed modules today. Would it therefore be reasonable of me to infer that this is the correct version of the file out of the three that now presumably encapsulates the code changes following the re-build? Accordingly, I copied this version of 'soffice.bin' into the Windows installation location of OpenOffice and replaced the original version of this file. While OpenOffice runs as usual, again, I do not see any of the obvious changes that the hacks were intended to achieve. Accordingly, I would infer from this that the re-builds of the two modules 'cui' and 'vcl' have not worked. In your view, would this be the likely scenario? Also, both builds appeared to run until completion with no obvious errors, so if this was the case, then I am unclear as to why the changes are not now apparent when OpenOffice is run. When tinkering with code, I am imagining that it is not necessary to re-install OpenOffice every time a module is re-built and note that you advised me to simply copy the changed 'soffice.bin' into the install directory and run that within the original Windows installation. Could you confirm if this is the typical way that one does test code changes, or is there another way to quickly run OpenOffice in order to see changes that have been made. In terms of any full re-installation, I now note that since the 'cui' and 'vcl' module re-build today that the following directory appears to have disappeared: $SourceMain/instsetoo_native/wntmsci12.pro/OpenOffice/msi/install/en-US/ However, the following directly has since appeared, which is empty and seems to have replaced it: $SourceMain/instsetoo_native/wntmsci12.pro/OpenOffice/msi/install/en-US_inprogress/ This appears to indicate that the installation files have now gone following re-build today. Would I need to rebuild everything in order to get the install files back? Thank you again for your help. Best regards Jason From: dennis.hamil...@acm.org To: dev@openoffice.apache.org Subject: RE: Simple code practice to get started Date: Sun, 9 Aug 2015 09:54:30 -0700 Building AOO does not put its results where an operating version of AOO has been installed on Windows. It sounds like you have not built the entire package. Or you built it but did not run the installer that you built. Running the installer will replace an existing version. It would be good to not do that on a PC that you are using for production purposes [;). - Dennis PS: If you have a new soffice.bin, you could rename the one in Program Files (x86)\OpenOffice 4\program\ and then copy your new one there. Previous warnings apply. Good luck. -Original Message- From: Jason Marshall [mailto:j_k_marshall_2...@live.com] Sent: Sunday, August 9, 2015 09:03 To: dev@openoffice.apache.org Subject: Simple code practice to get started Hi everyone I have successfully built OpenOffice 4.1.1 on a 32 bit Windows 7 platform. I have installed this with windows integration and it runs with no problem. I have then tried to make a couple of changes to the code as defined by the following hacks on the OpenOffice wiki (addition of extra 'OK' button in about dialog box and reversal of menus): https://wiki.openoffice.org/wiki/Hacking https://wiki.openoffice.org/wiki/Tutorial_About Within the directory of the relevant module changed (e. g. /cygdrive/c/aoo44/main/vcl), I then call build and the build appears to complete with no issue. However, when I start OpenOffice from the icon on the Windows taskbar, the changes do not appear to have carried through, such that none of the coded changes are visible. I have taken care to ensure that OpenOffice is closed and then re-opened following the build, but to no avail. I am guessing that for some reason I am not starting OpenOffice correctly, such that it is still running on code which does not contain the changes that I have made. Alternatively, perhaps the build
RE: Simple code practice to get started
Jason, use the more-comprehensive advice from Regina. - Dennis -Original Message- From: Jason Marshall [mailto:j_k_marshall_2...@live.com] Sent: Sunday, August 9, 2015 11:20 To: dev@openoffice.apache.org Subject: RE: Simple code practice to get started Dear Dennis Thank you for looking at this problem. [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Simple code practice to get started
Hi Regina Thank you for your response. I have done as you advised and copied just the 'vcl.dll' file into the existing location and having re-started OpenOffice, the menus are backwards, which would indicate that the installed software can now see the changes made in the vcl module following re-build and deliver. I note that you indicate that simply replacing the relevant DLL file may not be sufficient when a header file has also been changed, as is the case with the other example involving the 'cui' module. In this case, following a re-build and deliver, what in addition to copying the DLL files must also be done so that the installed code is aware of this change? I am keen not to take too much of the time of you and your colleagues and wonder if I have perhaps missed a section of the OpenOffice website or documentation which would enable me to read about this type of thing and so solve these problems for myself. If there is some information like this, would you be able to direct me to it? My industry experience as a software engineer was primarily confined to data warehousing and ETL and due to working for a large software house, environment and infrastructure efforts were taken care of, which may explain why the learning curve here for me is initially a little steep. Thanks Jason Date: Sun, 9 Aug 2015 19:47:17 +0200 From: rb.hensc...@t-online.de To: dev@openoffice.apache.org Subject: Re: Simple code practice to get started Hi Jason, Jason Marshall schrieb: Hi everyone I have successfully built OpenOffice 4.1.1 on a 32 bit Windows 7 platform. I have installed this with windows integration and it runs with no problem. I have then tried to make a couple of changes to the code as defined by the following hacks on the OpenOffice wiki (addition of extra 'OK' button in about dialog box and reversal of menus): https://wiki.openoffice.org/wiki/Hacking https://wiki.openoffice.org/wiki/Tutorial_About Within the directory of the relevant module changed (e. g. /cygdrive/c/aoo44/main/vcl), I then call build and the build appears to complete with no issue. After you build a module, call deliver in that module. Some modules do that automatically but others not. So to be sure I run deliver each time. However, when I start OpenOffice from the icon on the Windows taskbar, the changes do not appear to have carried through, such that none of the coded changes are visible. The installations is not directly connected to the source, therefore the installation knows nothing about your changes. The files, which will be packed to an installation set are located in the folder main/solver/version-number/wntmsci12.pro/bin. Sort the folder by date, so that you can easily find, which are altered. Copy the altered *.dll files into the program folder of your installation. If your change alters UI strings too, you might need to copy a *.res file too. They go to program/resource. This method only works for small changes inside one module, without changing the headers. I have taken care to ensure that OpenOffice is closed and then re-opened following the build, but to no avail. I am guessing that for some reason I am not starting OpenOffice correctly, such that it is still running on code which does not contain the changes that I have made. Alternatively, perhaps the build has not actually worked correctly without me being aware of this. I am aware that the hacking guide stipulates that OpenOffice should be started from the Cygwin command line. I have tried this, but the bash states the following: Jason and Emma@JasonandEmma-PC /cygdrive/c/aoo411/main/solver/411/wntmsci12.pro/bin $ . soffice.bin -bash: .: soffice.bin: cannot execute binary file I suspect that my mistake is really rather elementary and perhaps indicates my own lack of knowledge about how things work. Accordingly, any advice would be much appreciated. When you start working on the code, you should make an administrative installation fore-to keep your normal OpenOffice installation untouched. Another effect is, that an administrative installation is even quick, when you need to reinstall the whole OpenOffice, in case you have made changes, which require a clean build or affect a lot of modules. A normal installation is only needed, when you work on the system integration itself. Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Simple code practice to get started
Hi Jason, Jason Marshall schrieb: Dear Dennis Thank you for looking at this problem. Please forgive the length of the following e-mail; I suspect that when I have mastered the environmental set-up of OpenOffice, then likely any subsequewnt questions I can answer myself and will be far shorter. From what you are saying, I think that although I may have re-built the relevant modules where I changed the code, this of course did not carry over to the already-installed software on Windows which I installed immediately following the first complete build. I have located using 'find' three 'soffice.bin' files in the following directories of the code source: The functionality is most times not in 'soffice.bin' but in the *.dll files. For example, if you make a change in module svgio, then the corresponding dll svgio.dll will change. ./main/desktop/wntmsci12.pro/bin/soffice.bin That belongs to the outmost part of OpenOffice, which handles the applications. LibreOffice has put a README into each folder, which describes shortly the purpose of the module. There are differences between LibreOffice and Apache OpenOffice, nevertheless these READMEs are useful. ./main/instsetoo_native/wntmsci12.pro/Apache_OpenOffice/msi/patchsoname_file/en-US/00/soffice.bin From instsetoo_native you can take wntmsci12.pro\Apache_OpenOffice\msi\install\en-US to administrative install the application. That folder is the same as you get, when a downloaded, released version is unpacked in the first step of installation. ./main/solver/411/wntmsci12.pro/bin/soffice.bin In the solver, you find all the separate files, which were used to pack the versions in instsetoo_native. Read my other mail, how to use them. Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Simple code practice to get started
Hi Jason, Jason Marshall schrieb: Hi everyone I have successfully built OpenOffice 4.1.1 on a 32 bit Windows 7 platform. I have installed this with windows integration and it runs with no problem. I have then tried to make a couple of changes to the code as defined by the following hacks on the OpenOffice wiki (addition of extra 'OK' button in about dialog box and reversal of menus): https://wiki.openoffice.org/wiki/Hacking https://wiki.openoffice.org/wiki/Tutorial_About Within the directory of the relevant module changed (e. g. /cygdrive/c/aoo44/main/vcl), I then call build and the build appears to complete with no issue. After you build a module, call deliver in that module. Some modules do that automatically but others not. So to be sure I run deliver each time. However, when I start OpenOffice from the icon on the Windows taskbar, the changes do not appear to have carried through, such that none of the coded changes are visible. The installations is not directly connected to the source, therefore the installation knows nothing about your changes. The files, which will be packed to an installation set are located in the folder main/solver/version-number/wntmsci12.pro/bin. Sort the folder by date, so that you can easily find, which are altered. Copy the altered *.dll files into the program folder of your installation. If your change alters UI strings too, you might need to copy a *.res file too. They go to program/resource. This method only works for small changes inside one module, without changing the headers. I have taken care to ensure that OpenOffice is closed and then re-opened following the build, but to no avail. I am guessing that for some reason I am not starting OpenOffice correctly, such that it is still running on code which does not contain the changes that I have made. Alternatively, perhaps the build has not actually worked correctly without me being aware of this. I am aware that the hacking guide stipulates that OpenOffice should be started from the Cygwin command line. I have tried this, but the bash states the following: Jason and Emma@JasonandEmma-PC /cygdrive/c/aoo411/main/solver/411/wntmsci12.pro/bin $ . soffice.bin -bash: .: soffice.bin: cannot execute binary file I suspect that my mistake is really rather elementary and perhaps indicates my own lack of knowledge about how things work. Accordingly, any advice would be much appreciated. When you start working on the code, you should make an administrative installation fore-to keep your normal OpenOffice installation untouched. Another effect is, that an administrative installation is even quick, when you need to reinstall the whole OpenOffice, in case you have made changes, which require a clean build or affect a lot of modules. A normal installation is only needed, when you work on the system integration itself. Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
