Re: [dev] new build requirement on !Windows - mingw32
Rene Engelhard wrote: Hi, with integration of cws unowinregcross (and therefore in m181) we have a new build requirement: mingw32. See issue 49178. That should read See issue 49718, I assume. It is used for building unowinreg.dll (because using random binaries out of CVS is bad(tm)). Sorry for stepping into this so late. As far as I understand, the situation is as follows: - We have some OOo source files in odk/source/unowinreg/win/ from which a Windows DLL is built, and that Windows DLL is needed on all platforms, not just Windows. - On SRC680m180 and earlier, the DLL resulting from the sources is checked into CVS as odk/bin/win/unowinreg.dll. On Windows, the DLL is built from sources, on all other platforms, the checked-in version is used. If anybody changes the sources in odk/source/unowinreg/win/, that person is required to also check in a new odk/bin/win/unowinreg.dll (i.e., do a build on Windows to obtain the new DLL and then check it in). The rationale for the checked-in DLL is that it is difficult or impossible to build the DLL on platforms other than Windows. - Since SRC680m181, the DLL resulting from the sources is no longer checked into CVS. Rather, as a new prerequisite you either need to have the necessary tools available to build it from the sources (i.e., a cross compiler, which might not be available for every platform), or you need to copy the DLL from somewhere. If anybody changes the sources in odk/source/unowinreg/win/, that person is required to make the new version of the DLL globally available somewhere (but not replacing the globally available old version of the DLL, as that might still be needed by people building an older version of OOo) and inform everybody that the prerequisite of copying the DLL from somewhere A has changed to copying it from somewhere B. This step is further complicated by our child workspace mechanism: The changes to odk/source/unowinreg/win/ will happen on some CWS first. So that anybody can build that CWS, a CWS-specific version of the DLL needs to be made available globally, and everybody needs to be informed that when building the CWS, the prerequisite of copying the DLL has changed. Then, the CWS will be integrated into some MWS, and before the MWS is announced as available, an MWS-built version of the DLL (which might differ from the CWS-specific version, e.g., if multiple CWS that made changes to odk/source/unowinreg/win/ are integrated simultaneously) needs to be made available globally, and everybody needs to be informed about the changed prerequisite (and who does do that, the person that did the changes to odk/source/unowinreg/win/ or the person that announces the availability of the new MWS?). Honestly, the old way looks much less error prone, as it leverages established mechanisms (CVS) to avoid some of the pitfalls. It is of course a laudable approach to build as much as possible from sources. However, that approach apparently has its limits, and you have to be careful not to stretch it too far. Given these reasons, I strongly vote for undoing the changes introduced in SRC680m181. (The changes on SRC680m181 might also allow to---optionally---build the DLL from sources on more platforms than was possible before. If that is the case, I think that is a good move which should of course not be undone. It is just the moving of the precompiled DLL from CVS to somewhere else that I find highly problematic.) -Stephan [...] Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo developers guide
Daniel Beck wrote: Hello, I would like to have the openoffice developers guide (i.e., the one found at http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html ) as a textbook. I googled for it, and also looked at amazone, but apparently it is only possible to have it in electronical form. I write this email to ask if someone know if it is possible to buy it somewhere as textbook. Because the Developer's Guide is a Sun product and it is part of the StarOffice SDK as well it is available online and you can buy a printed version http://docs.sun.com/app/docs/coll/1263.1?q=StarOffice+8s=t For selling a printed version of the Developer's Guide you need the permission of Sun yet, it is only allowed for private usage. But we are thinking about open sourcing the guide completely and not only to provide a free version. Juergen Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
On 17/08/2006, at 7:06 PM, Jürgen Schmidt wrote: The whole issue came from some extreme views and i like the comment from Volker the extreme view can be correct. Sun takes an extreme position on JCA, and it is also correct that any open source project should be built from sources. jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Am Donnerstag, 17. August 2006 11:27 schrieb Stephan Bergmann: - We have some OOo source files in odk/source/unowinreg/win/ from which a Windows DLL is built, and that Windows DLL is needed on all platforms, not just Windows. Right. - On SRC680m180 and earlier, the DLL resulting from the sources is checked into CVS as odk/bin/win/unowinreg.dll. On Windows, the DLL is built from sources, on all other platforms, the checked-in version is used. If anybody changes the sources in odk/source/unowinreg/win/, that No, exactly that wasn't true either. On Windows *ALSO* the prebuilt one was taken. (cws unowinregh also fixed that, but before that even on Windows it was not built. See the Issue) person is required to also check in a new odk/bin/win/unowinreg.dll (i.e., do a build on Windows to obtain the new DLL and then check it in). The rationale for the checked-in DLL is that it is difficult or impossible to build the DLL on platforms other than Windows. Not true. One mingw32 compiler call :) Of course, there might be no mingw compiler available for whatever reason. That's why the use-the-dll approach is working still... - Since SRC680m181, the DLL resulting from the sources is no longer checked into CVS. Rather, as a new prerequisite you either need to have the necessary tools available to build it from the sources (i.e., a cross compiler, which might not be available for every platform), or you need to copy the DLL from somewhere. If anybody changes the sources in odk/source/unowinreg/win/, that person is required to make the new version of the DLL globally available somewhere (but not replacing the globally available old version of the DLL, as that might still be needed by people building an older version of OOo) and inform everybody that the prerequisite of copying the DLL from somewhere A has changed to copying it from somewhere B. This step is further complicated by our [...] Develöoerps who want to deploy stuff using that dll should not use cwses but released versions. For those, this argument is moot since you then *can* provide a new unowinreg.dll. And if you rebuild it everything works, it just gives problem if you insist of using the binary,,, The .dll isn't used except for packging up in a zip, so the build won't fail either. Honestly, the old way looks much less error prone, as it leverages established mechanisms (CVS) to avoid some of the pitfalls. It is of course a laudable approach to build as much as possible from sources. However, that approach apparently has its limits, and you have to be careful not to stretch it too far. Given these reasons, I strongly vote for undoing the changes introduced in SRC680m181. (The changes on SRC680m181 might also allow to---optionally---build the DLL from sources on more platforms than was possible before. If that is the case, I think that is a good move which should of course not be undone. It is just the moving of the precompiled DLL from CVS to somewhere else that I find highly problematic.) The problem is that IMHO the rebuilding should be default. It is easily possible to use the internal one, though. Having it in the cws would make the configure check more error-prone because it doesn't have a opportunity to check for that dll anymore. Currently, if the dll is in the tree, it will be used by the build, if not, you'll get an error if you don't have mingw32. You easily can do that by either using mingw32 and specifiying --with-mingwin32=... or by coying the dll (or --disable-odk / --without-java, but that's an other story, and people who want Java and the ODK obviusly won't use them :) ) Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. The rule of thumb we used in art pipelines was that if the target file required special software or hardware for generation it should be checked into the repos. Especially if it changed seldom, like the case seems to be here. We need to make our build process easier and adding another application to install or file to download does not further that goal. Kai -- Kai Backman, Software Engineer, [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Compling just doesnt proceed stays stuck at boost..
Hi Maulik, To start out with you need to provide the following details: - What -exact- URL did you use to download the source file? - Is there CVS directories in the subdirectories (like solenv/CVS)? Kai On 8/16/06, Maulik Gordhandas [EMAIL PROTECTED] wrote: Hi, Kai i am on a low net connection so i cannot use cvs to download the entire 2.something GB of source. but using the tarball i tried doing wat u gave but i got an error telling bash is not supported only tcsh or 4nt is upported.. please help me with this.. thanks Date: Mon, 14 Aug 2006 14:20:22 +0200 From: Kai Backman [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Subject: [dev] Re: Compling just doesnt proceed stays stuck at boost.. Hi Maulik, I would recomend checking out a milestone instead of building from a tarball. You should also use bash/Cygwin (instead of tcsh) as it contains some critical bug fixes. Here is a sample set of shell invocations: mkdir SRC680 cd SRC680 export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs cvs login cvs co -r SRC680_m181 OpenOffice2 On 8/12/06, Maulik Gordhandas [EMAIL PROTECTED] wrote: $ ./configure --with-cl-home=/cygdrive/c/program files/Microsoft Visual Studio .NET 2003/Vc7 --with-jdk-home=/cygdrive/c/jdk1.5.0_07 --with-use-shell=tcsh --with-ant-home=/cygdrive/c/ant Use --with-use-shell=bash instead and do the rest of the build commands in bash. The only difference from tcsh is that you need to source winenv.set.sh. Just for reference, here is my standard ./configure invocation: ./configure --with-cl-home=C:/Program Files/Microsoft Visual Studio .NET 2003 --with-mspdb-path=C:/Program Files/Microsoft Visual Studio .NET 2003/Common7/IDE --with-frame-home=C:/Program Files/Microsoft Visual Studio .NET 2003/SDK/v1.1 --with-jdk-home=C:/Program Files/Java/jdk1.5.0_07 --with-directx-home=/Program Files/Microsoft DirectX SDK (June 2006) --with-nsis-path=C:/Program Files/NSIS --with-ant-home=C:/work/apache-ant-1.6.5 --with-use-shell=bash If you are on IRC (freenode, #OpenOffice.org) you can also ping a Win32 builder like vq, tml or me (kaib). We will be happy to help you out. Take care, Kai -- Kai Backman, Software Engineer, [EMAIL PROTECTED] -- Kai Backman, Software Engineer, [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Rene Engelhard wrote: Am Donnerstag, 17. August 2006 11:27 schrieb Stephan Bergmann: - We have some OOo source files in odk/source/unowinreg/win/ from which a Windows DLL is built, and that Windows DLL is needed on all platforms, not just Windows. Right. - On SRC680m180 and earlier, the DLL resulting from the sources is checked into CVS as odk/bin/win/unowinreg.dll. On Windows, the DLL is built from sources, on all other platforms, the checked-in version is used. If anybody changes the sources in odk/source/unowinreg/win/, that No, exactly that wasn't true either. On Windows *ALSO* the prebuilt one was taken. (cws unowinregh also fixed that, but before that even on Windows it was not built. See the Issue) Ok, *that* change is fine with me. person is required to also check in a new odk/bin/win/unowinreg.dll (i.e., do a build on Windows to obtain the new DLL and then check it in). The rationale for the checked-in DLL is that it is difficult or impossible to build the DLL on platforms other than Windows. Not true. One mingw32 compiler call :) Of course, there might be no mingw compiler available for whatever reason. That's why the use-the-dll approach is working still... So you agree that difficult or impossible *is* true, right? And the use-the-dll approach is now working slightly different (in that the DLL is no longer checked into CVS, but has to be obtained from somewhere else), right? - Since SRC680m181, the DLL resulting from the sources is no longer checked into CVS. Rather, as a new prerequisite you either need to have the necessary tools available to build it from the sources (i.e., a cross compiler, which might not be available for every platform), or you need to copy the DLL from somewhere. If anybody changes the sources in odk/source/unowinreg/win/, that person is required to make the new version of the DLL globally available somewhere (but not replacing the globally available old version of the DLL, as that might still be needed by people building an older version of OOo) and inform everybody that the prerequisite of copying the DLL from somewhere A has changed to copying it from somewhere B. This step is further complicated by our [...] Develöoerps who want to deploy stuff using that dll should not use cwses but released versions. For those, this argument is moot since you then *can* provide a new unowinreg.dll. It is not developers who want to deploy stuff I am talking about, but for example developers who want to verify that some CWS will work fine on a given platform (i.e., want to verify in advance that building on a given platform will not break once some CWS is integrated). And if you rebuild it everything works, it just gives problem if you insist of using the binary,,, As I explained above, I assume that there are platforms where rebuilding is simply not posible. The .dll isn't used except for packging up in a zip, so the build won't fail either. This is IMO a bad argument. Each build should result in fully functional deliverables. You do not know for which reason somebody is building OOo, so you do not know whether or not it is ok if that build includes a wrong DLL. Honestly, the old way looks much less error prone, as it leverages established mechanisms (CVS) to avoid some of the pitfalls. It is of course a laudable approach to build as much as possible from sources. However, that approach apparently has its limits, and you have to be careful not to stretch it too far. Given these reasons, I strongly vote for undoing the changes introduced in SRC680m181. (The changes on SRC680m181 might also allow to---optionally---build the DLL from sources on more platforms than was possible before. If that is the case, I think that is a good move which should of course not be undone. It is just the moving of the precompiled DLL from CVS to somewhere else that I find highly problematic.) The problem is that IMHO the rebuilding should be default. It is easily possible to use the internal one, though. Having it in the cws would make the configure check more error-prone because it doesn't have a opportunity to check for that dll anymore. Sorry, I do not understand what you want to say in this paragraph. Currently, if the dll is in the tree, it will be used by the build, if not, you'll get an error if you don't have mingw32. You easily can do that by either using mingw32 and specifiying --with-mingwin32=... or by coying the dll (or --disable-odk / --without-java, but that's an other story, and people who want Java and the ODK obviusly won't use them :) ) What do you mean with if the dll is in the tree? The problem that I see, as I stated before, is the copying the dll thing. -Stephan Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Kai Backman wrote: The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. This suggestion looks fine with me, I would even agree to a setup where recompilation is on by default on those platforms where it is known to work without additional prerequisites (e.g., wntmsci10). (I too think that cross-compilation where possible is a good thing and I too think it is good that Rene integrated the mechanisms that allow to actually do the cross-compilation, in case that was not clear from my previous mails.) -Stephan The rule of thumb we used in art pipelines was that if the target file required special software or hardware for generation it should be checked into the repos. Especially if it changed seldom, like the case seems to be here. We need to make our build process easier and adding another application to install or file to download does not further that goal. Kai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Kai Backman wrote: The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. The rule of thumb we used in art pipelines was that if the target file required special software or hardware for generation it should be checked into the repos. Especially if it changed seldom, like the case seems to be here. We need to make our build process easier and adding another application to install or file to download does not further that goal. +1 that is exactly the solution i have in mind and i have initially assumed that it would be solved in this way and that the cross compilation is only an option for people who can't live with the precompiled dll. Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Am Donnerstag, 17. August 2006 15:51 schrieb Stephan Bergmann: person is required to also check in a new odk/bin/win/unowinreg.dll (i.e., do a build on Windows to obtain the new DLL and then check it in). The rationale for the checked-in DLL is that it is difficult or impossible to build the DLL on platforms other than Windows. Not true. One mingw32 compiler call :) Of course, there might be no mingw compiler available for whatever reason. That's why the use-the-dll approach is working still... So you agree that difficult or impossible *is* true, right? No, at least not generally. It might be true for some platform, though. Develöoerps who want to deploy stuff using that dll should not use cwses but released versions. For those, this argument is moot since you then *can* provide a new unowinreg.dll. It is not developers who want to deploy stuff I am talking about, but for example developers who want to verify that some CWS will work fine on a given platform (i.e., want to verify in advance that building on a given platform will not break once some CWS is integrated). And why should they need to care about unowinreg.dll when they didn't change it? Of course, if they did change it in the cws they need to rebuild and test it, but that's normal QA... The problem is that IMHO the rebuilding should be default. It is easily possible to use the internal one, though. Having it in the cws would make the configure check more error-prone because it doesn't have a opportunity to check for that dll anymore. Sorry, I do not understand what you want to say in this paragraph. What currently is done is: - check whether the dll is there - if *not* rebuild it - fail when mingw32 isn't there. If the dll is in the tree again the check whether the dll is there always would be true (and it needs to be adapted anyway..). The configure check would need to be rewritten to *always* take the dll (because it's there) and only optionally cross-compile it. (See Kaibs mail. I don't really like that, though, but if the majority wants this But as oyou wrote in your other post, you do agree with cross-compiling it...) Currently, if the dll is in the tree, it will be used by the build, if not, you'll get an error if you don't have mingw32. You easily can do that by either using mingw32 and specifiying --with-mingwin32=... or by coying the dll (or --disable-odk / --without-java, but that's an other story, and people who want Java and the ODK obviusly won't use them :) ) What do you mean with if the dll is in the tree? The problem that I see, as I stated before, is the copying the dll thing. Yes, but you *could* send announce mails for big changes in that dll. YOu already have that feature mail mechanism. There already is the prodecure to announce new build reqs on this list (as I did with my initial post) Regards, Rene -- René Engelhard -- Debian GNU/Linux Developer -- Debian OOo Maintainer-Team http://www.debian.org | http://people.debian.org/~rene/ | [EMAIL PROTECTED] http://openoffice.debian.net | debian-openoffice@lists.debian.org GPG: 248AEB73 | Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Hi, Am Donnerstag, 17. August 2006 16:15 schrieb Jürgen Schmidt: Kai Backman wrote: The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. [...] +1 that is exactly the solution i have in mind and i have initially assumed that it would be solved in this way and that the cross compilation is only an option for people who can't live with the precompiled dll. No, in the issue you opposed cross-compiling in general and questioned the sense to build it at all. That's not exactly the solution Kai proposed and neither is that how you reacted in the issue. Of course, if you now changed your mind and think that cross-compiling does make sense, good... Regards, Rene -- René Engelhard -- Debian GNU/Linux Developer -- Debian OOo Maintainer-Team http://www.debian.org | http://people.debian.org/~rene/ | [EMAIL PROTECTED] http://openoffice.debian.net | debian-openoffice@lists.debian.org GPG: 248AEB73 | Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new build requirement on !Windows - mingw32
Rene Engelhard wrote: Hi, Am Donnerstag, 17. August 2006 16:15 schrieb Jürgen Schmidt: Kai Backman wrote: The work Rene has done with the cross compilation is great, but I think we need to minimize the number of -required- external dependencies. Here is my suggestion for a solution: - Check unowinreg.dll back into the repository and use it by default without recompilation on all platforms. - Include a configure switch that forces recompilation of the DLL. On win32 this uses the standard compiler, on !win32 mingw32. [...] +1 that is exactly the solution i have in mind and i have initially assumed that it would be solved in this way and that the cross compilation is only an option for people who can't live with the precompiled dll. No, in the issue you opposed cross-compiling in general and questioned the sense to build it at all. i meant cross compilation in this special case for this library because i am still thinking that it is not necessary but i can understand your opinion. That's not exactly the solution Kai proposed and neither is that how you reacted in the issue. If my comments sound to unfriendly in the issue and even in this thread please forgive me ;-) Of course, if you now changed your mind and think that cross-compiling does make sense, good... i can live with a new configure option to cross compile the library or compile it where possible (wntmsci10) but it shouldn't be the default. I think that the suggested solution by Kai is a good compromise. Do we now all agree to the suggested solution and if yes who will take care of the issue? Juergen Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Is override via dominance useful (was: [dev] Warning free code: some more warnings that might be disabled)
Frank Schönheit - Sun Microsystems Germany [EMAIL PROTECTED] writes:
(What I intended to say was: what I've learned during reading zillions
of line of code inherited from others is that patterns which are
obscured from plain sight are hard to maintain, and thus prone to
introducing errors. While using cool language features is, well, cool,
its usefulness sometimes decreases over time, when it comes to
maintaining the code. KISS. But hey, I'm digressing.)
Generally, true. But aren't we c++ programmers accustomed to an
unprecedented level of obscureness, anyway (at least compared to, say,
a Java coder)? ;-)
So, in this case, about the only change that will break things with
this idiom (and doesn't trigger a compiler error) is that someone
implements method a() or b() in Interface:
struct Interface
{
- virtual void a() = 0;
+ virtual void a() {}
- virtual void b() = 0;
+ virtual void b() {}
};
struct DerivedInterface : public Interface
{
virtual void c() = 0;
};
struct InterfaceHelper : public virtual Interface
{
virtual void a();
virtual void b();
};
struct DerivedInterfaceImplementation :
public virtual DerivedInterface,
protected InterfaceHelper
{
virtual c();
};
and expects that those are called in DerivedInterfaceImplementation,
instead of the overrides from InterfaceHelper.
Admittedly, this language feature _is_ dangerous when using multiple,
virtual inheritance with concrete classes (instead of interfaces, as
in my idiom), because then, figuring out by hand which method wins can
get quite involved. But I don't think we do that now, and we certainly
shouldn't do that for new code (since there are far more pitfalls with
that than this one).
Cheers,
--
Thorsten
If you're not failing some of the time, you're not trying hard enough.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Two cursors!
Hello I have two cursors in my application, both flashing simultaneously. One in a swing gadget and one in an OfficeBean LocalOfficeWindow. Keyboard focus is messed up. Any ideas anyone? B.T.W. I know this might not be the right mailing list, but I am clutching at straws... Regards Malte - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] [Fwd: [users] How to open new OOo Labels Document from command line]
How do I open OOo (no instances open beforehand) as if I'd selected File-New-Labels ? What I am trying to do is create a new shortcut for the QuickStarter to directly open the Labels wizard. TIA, Matt ---BeginMessage--- How do I open OOo (no instances open beforehand) as if I'd selected File-New-Labels ? What I am trying to do is create a new shortcut for the QuickStarter to directly open the Labels wizard. TIA, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: OOo-Lehrbuch im Netz
Als Tipp dazu: Mit der Firefox-Erweiterung Scrapbook ist das ganze binnen 5 Minuten auf der Platte und mit FreePDF XP in 2 Minuten zu einem E-book verbunden... alle 172 Seiten... Jacqueline Rahemipour schrieb: Hallo zusammen, unter www.weigeloffice.de gibt es ein 172-seitiges Lehrbuch zu den Modulen Writer, Calc, Base und Impress. Elmar Weigel hat es geschrieben und stellt es freundlicherweise zur Verfügung. Schaut einfach mal rein! @Andreas: Er bat darum, dass dieser Link bei uns aufgenommen wird. Wo soll der genau hin? Gruß, Jacqueline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
