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
>
