Re: [dev] Simplify Reference Casts by template constructors
Thank you Frank,
you are right, get() is enough.
I haven't seen it before;)
On Wed, Mar 11, 2009 at 4:05 PM, Frank Schönheit - Sun Microsystems
Germany frank.schoenh...@sun.com wrote:
Hi Rainman,
After a period of time of developing with URE, I find the C++ UNO
class Reference is not very comfortable for use sometime.
The problem is, when I have a reference of base interface XA and a
reference of derived interface XB, I can't make xA = xB directly.
Instead I have to query XA from xB like this xA = ReferenceXA::query(xB).
¨xA = xB.get()¨ would do, too, and be less expensive.
I wonder that whether we can use template constructors to simply this
situation.These constructors may something like this:
template typename interface_type
class Reference
{
template _interface_type
Reference(const Reference_interface_type rRef)
{
interface_type* p = NULL;
_interface_type* _p = NULL;
p = _p; // compiling time cast check.
_pInterface = iquery( rRef.get() );
The last two lines could be to just assigning (and aquiring) rRef.get()
to _pInterface.
}
...
Now we can simplify the cast code above to
xA = xB;
I am not sure we should do this, implicit constructors usually add
ambiguity ...
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Simplify Reference Casts by template constructors
Hey Frank,
I have another ideal, it is better and safer than the last one I mentioned.
I add a conversion operator to Reference, instead of a constructor, here is it:
template class base_interface_type
inline SAL_CALL operator const Reference base_interface_type ()
const SAL_THROW( () )
{ return Reference base_interface_type ( get() ); }
I tested some cases, and it works well.
How do you think it? I am not very sure it will work for all situation.
On Wed, Mar 11, 2009 at 4:05 PM, Frank Schönheit - Sun Microsystems
Germany frank.schoenh...@sun.com wrote:
Hi Rainman,
After a period of time of developing with URE, I find the C++ UNO
class Reference is not very comfortable for use sometime.
The problem is, when I have a reference of base interface XA and a
reference of derived interface XB, I can't make xA = xB directly.
Instead I have to query XA from xB like this xA = ReferenceXA::query(xB).
¨xA = xB.get()¨ would do, too, and be less expensive.
I wonder that whether we can use template constructors to simply this
situation.These constructors may something like this:
template typename interface_type
class Reference
{
template _interface_type
Reference(const Reference_interface_type rRef)
{
interface_type* p = NULL;
_interface_type* _p = NULL;
p = _p; // compiling time cast check.
_pInterface = iquery( rRef.get() );
The last two lines could be to just assigning (and aquiring) rRef.get()
to _pInterface.
}
...
Now we can simplify the cast code above to
xA = xB;
I am not sure we should do this, implicit constructors usually add
ambiguity ...
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Simplify Reference Casts by template constructors
Hi Frank,
No, I did not compile the OOo yet.
I have only recompile our product which was developed completely upon URE.
It seems that is compatible with existing code well.
On Wed, Mar 11, 2009 at 7:19 PM, Frank Schönheit - Sun Microsystems
Germany frank.schoenh...@sun.com wrote:
Hi Rainman,
I have another ideal, it is better and safer than the last one I mentioned.
I add a conversion operator to Reference, instead of a constructor, here is
it:
template class base_interface_type
inline SAL_CALL operator const Reference base_interface_type ()
const SAL_THROW( () )
{ return Reference base_interface_type ( get() ); }
I tested some cases, and it works well.
How do you think it? I am not very sure it will work for all situation.
Uhm - implicit conversion operators are Evil (TM) :)
This is a place where my gut feeling says we should sacrifice the little
convenience we could gain (xA = xB instead of xA = xB.get()) for
clarity. At least clarity in reading code, but also clarity in reading
the error messages which the compiler would raise for incompatible xA
and xB :)
Admittedly, this feeling is not backed up by strong arguments, but I am
sure others could come up with some. Stephan?
Btw, did you compile the complete OOo from scratch with this change?
Would be interesting to know whether the existing code already survives it.
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Simplify Reference Casts by template constructors
Hi Andrew
I know that implicit conversions usually bring more side effects than
convenience. But it is not the reason that we should give all them up
I think ;)
There is no implicit conversion from std::string to const char*,
because if a string is destroyed, the pointer to its content will be
invalid.
Fortunately, we don't have to consider during reference conversions.
The only thing I am not very sure is whether there are some
ambiguities that may be introduced by this implicit reference
conversion.
Would be grateful to know all problems about it ;)
Thank you!
On Thu, Mar 12, 2009 at 6:55 AM, Andrew Douglas Pitonyak
and...@pitonyak.org wrote:
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Rainman,
I have another ideal, it is better and safer than the last one I
mentioned.
I add a conversion operator to Reference, instead of a constructor, here
is it:
template class base_interface_type
inline SAL_CALL operator const Reference base_interface_type ()
const SAL_THROW( () )
{ return Reference base_interface_type ( get() ); }
I tested some cases, and it works well.
How do you think it? I am not very sure it will work for all situation.
Uhm - implicit conversion operators are Evil (TM) :)
This is a place where my gut feeling says we should sacrifice the little
convenience we could gain (xA = xB instead of xA = xB.get()) for
clarity. At least clarity in reading code, but also clarity in reading
the error messages which the compiler would raise for incompatible xA
and xB :)
Admittedly, this feeling is not backed up by strong arguments, but I am
sure others could come up with some. Stephan
You must be very careful before introducing an implicit conversion. By
careful, I mean, you should understand the consequences.
Although conversion operators are nice for your intended purpose, they
compromise type safety and disable the compiler's type-safety checks. For
this reason, library designers usually do not include conversion operators,
even though is it inconvenient for the user; for example, there is not a
conversion operator from (const char *) to std::string (and that feels like
an obvious one to include if you ignore the side effects).
This is a reason that it is recommended that you use the explicit keyword
before constructors that accept only one argument (because it is used as an
implicit conversion operator).
Do you need or desire examples of where this can go awry?
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
My Book: http://www.hentzenwerke.com/catalog/oome.htm
Info: http://www.pitonyak.org/oo.php
See Also: http://documentation.openoffice.org/HOW_TO/index.html
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
[dev] Simplify Reference Casts by template constructors
Hi everyone,
After a period of time of developing with URE, I find the C++ UNO
class Reference is not very comfortable for use sometime.
The problem is, when I have a reference of base interface XA and a
reference of derived interface XB, I can't make xA = xB directly.
Instead I have to query XA from xB like this xA = ReferenceXA::query(xB).
I wonder that whether we can use template constructors to simply this
situation.These constructors may something like this:
template typename interface_type
class Reference
{
template _interface_type
Reference(const Reference_interface_type rRef)
{
interface_type* p = NULL;
_interface_type* _p = NULL;
p = _p; // compiling time cast check.
_pInterface = iquery( rRef.get() );
}
// copy constructor
Reference(const Reference_T another)
{
...
}
}
Now we can simplify the cast code above to
xA = xB;
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: the NEW STYLE service may import great complexity to implementation.
the problem here is the circle inheritance of the interfaces.when this situation occurs, the derived class must reimplements all repeatedly inherited interfaces even if you use the helper class. On Fri, Aug 1, 2008 at 10:49 PM, Michael Stahl [EMAIL PROTECTED] wrote: Frank Schönheit - Sun Microsystems Germany wrote: Hello Rainman, We are developing our products upon UNO component model. One of the big problem we have met is how to implement a service which declared by the NEW STYLE statement. ... Now the problem comes, this is a terrible multiple inheritance relationship in C++, and maks hardly reuse of ImplA. because of ImplA and XB both derived from XA, leading that we must implement all methods declared in XA within ImplB again.The same problem occurs in ImplC. If there are many methods in XA, the development and the maintenance complexity of the ImplB and ImplC would be unacceptable. This in fact is a big problem, IMO. Upon continued begging the skeletonmaker tool (which is part of the SDK) is meanwhile able to generate code for you which does the forwarding (the concrete syntax evades me at the moment), which somewhat relaxes the problem. However, very high on my personal wishlist would be a define, auto-generated into XFoo.hpp, which allows me to write something like FORWARD_XFOO( base_class_name ) , which effectively implements all methods of XFoo, just forwarding them to base_class_name. This would reduce the maintenance efforts to mere re-compilation. (And while we are at it, an DECLARE_XFOO() would be great, too, also coming from the .hpp file. Yes, I know that skeletonmaker can also generate all the member declarations, but that's again a maintenance problem if the interface changes, which happens often enough during development of new API.) hmm... isn't that pretty much why ImplInheritanceHelper exists? http://api.openoffice.org/docs/cpp/ref/names/cppu/c-ImplInheritanceHelper1.html or am i missing something here? (well, i guess you still have to override XServiceInfo by hand...) michael -- The last good thing written in C was Franz Schubert's Symphony number 9. -- Erwin Dieterich - 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] How can I reuse the implementation of a service?
certainly I could, but this solution is much complex and hardly to
maintain.It would be a terrible dream if XWindow interface have
dozens of methods.
Best Wishes, Rainman.
On Mon, Aug 4, 2008 at 3:17 PM, Mathias Bauer [EMAIL PROTECTED] wrote:
Rainman Lee wrote:
oh, I see...
Separating XButton from XWindow and reusing the window implementation
can be done in a old-style service.
But in a new-style service, only one interface a service can inherit.
so if I try to separate XButton, there must be a XSomeInterface that
inherits XButton and XWindow.
The result is my Button that inherits XSomeInterface cant reuse Window
implementation.
No, you can reuse it, but you must reimplement all methods from XWindow
and let them call the methods of your window class. If you have a
MyButtonClass that derives from MyWindowClass (implementing XWindow)
and implements XButton (derived from XWindow), and if your XWindow
interface has a method setvisible, the code would look like e.g.
MyButtonClass::setVisible( sal_Bool bSet )
{
MyWindowClass::setVisible( bSet );
}
I assume that with XButton and XWindow you are not referring to the
interfaces in the namespace com::sun::star::awt, as here XButton is not
derived from XWindow anyway.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to [EMAIL PROTECTED].
I use it for the OOo lists and only rarely read other mails sent to it.
-
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] the NEW STYLE service may import great complexity to implementation.
Hi Frank, Thank you for your replay. Hoping to see your marcos soon~ hehe. Best Wishes, Rainman. On Fri, Aug 1, 2008 at 5:15 AM, Frank Schönheit - Sun Microsystems Germany [EMAIL PROTECTED] wrote: Hello Rainman, We are developing our products upon UNO component model. One of the big problem we have met is how to implement a service which declared by the NEW STYLE statement. ... Now the problem comes, this is a terrible multiple inheritance relationship in C++, and maks hardly reuse of ImplA. because of ImplA and XB both derived from XA, leading that we must implement all methods declared in XA within ImplB again.The same problem occurs in ImplC. If there are many methods in XA, the development and the maintenance complexity of the ImplB and ImplC would be unacceptable. This in fact is a big problem, IMO. Upon continued begging the skeletonmaker tool (which is part of the SDK) is meanwhile able to generate code for you which does the forwarding (the concrete syntax evades me at the moment), which somewhat relaxes the problem. However, very high on my personal wishlist would be a define, auto-generated into XFoo.hpp, which allows me to write something like FORWARD_XFOO( base_class_name ) , which effectively implements all methods of XFoo, just forwarding them to base_class_name. This would reduce the maintenance efforts to mere re-compilation. (And while we are at it, an DECLARE_XFOO() would be great, too, also coming from the .hpp file. Yes, I know that skeletonmaker can also generate all the member declarations, but that's again a maintenance problem if the interface changes, which happens often enough during development of new API.) So I just wonder whether we really need the single interface service. Well, as much as I dislike the additional effort during implementation: The question is whether it's worth the added convenience for the *client* of your API. Remember that new-style API is usually much more convenient to use, and that usually, you implement only once, or a few times, but your clients use your API much more often. Your decision, finally. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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]
[dev] the NEW STYLE service may import great complexity to implementation.
Hey everyone! We are developing our products upon UNO component model. One of the big problem we have met is how to implement a service which declared by the NEW STYLE statement. For example: XA- | || |XB XC | || AB C This illustration shows our service inheritance relationship where XA, XB, XC represent interfaces and A, B, C represent services. When we try to implement these services, we got a problem: XA- | || |XB XC | || ImplA-ImplB| | | -ImplC This illustration above describe our implemention inheritance relationship where ImplA, ImplB, ImplC correspondingly represents the implementation of service A, B, C. We make ImplB derived from XB to inherit the intereface, and derived from ImplA to inherit the implementation of the interface XA. Now the problem comes, this is a terrible multiple inheritance relationship in C++, and maks hardly reuse of ImplA. because of ImplA and XB both derived from XA, leading that we must implement all methods declared in XA within ImplB again.The same problem occurs in ImplC. If there are many methods in XA, the development and the maintenance complexity of the ImplB and ImplC would be unacceptable. I think it is big problem caused by single interface service(the NEW STYLE service). where only one interface can be inherited by serivce. If we use the OLD STYLE service declaration, the service relationship would be like this: XAXB XC || | || || -B | ||---C | A And the imlementation illustration would be: XA XB XC | | | ImplA| | | | | --ImplB | |-ImplC There is no circle in this graph, so the reuse could be easily done. So I just wonder whether we really need the single interface service. Best Wishes, Rainman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How can I reuse the implementation of a service?
oh, I see... Separating XButton from XWindow and reusing the window implementation can be done in a old-style service. But in a new-style service, only one interface a service can inherit. so if I try to separate XButton, there must be a XSomeInterface that inherits XButton and XWindow. The result is my Button that inherits XSomeInterface cant reuse Window implementation. On Wed, Jul 16, 2008 at 1:11 AM, Mathias Bauer [EMAIL PROTECTED] wrote: Rainman Lee wrote: hello everyone, I defined a interfaces tree like this: XWindow | | XButton | | XImageButton and I have implemented XWindow in my Window service. now I want to implement XButton, XImageButton respectively in Button, ImageButton services. Is there a convenient method with which I can reuse the Window's implementation, instead of reimplementing all XWindow's interfaces in Button? Thank you very much! If XButton wasn't derived from XWindow it would be easy - just have your button class inherit from the window class, add the additional interface and implement only the methods from this interface. As XButton includes XWindow, you must reimplement the methods in your button class, but you can just forward it to your inherited window implementation. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - 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]
[dev] How can I reuse the implementation of a service?
hello everyone, I defined a interfaces tree like this: XWindow | | XButton | | XImageButton and I have implemented XWindow in my Window service. now I want to implement XButton, XImageButton respectively in Button, ImageButton services. Is there a convenient method with which I can reuse the Window's implementation, instead of reimplementing all XWindow's interfaces in Button? Thank you very much! Best Wishes, Rainman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] How can I add a interface upon a published service?
hello everyone,
I have a question about extending a published service.
supposing that there is a published service S, which derives from a
Multi-Inheritance Interface C, which inherits from A and B, like that:
interface A
{
...
};
interface B
{
...
};
interface C
{
interface A;
interface B;
};
service S : C;
and the service S is published.
now I want to make the service S suppot a new interface D, how can I
archieve this while guaranteeing that old programs using service S
still works?
I know that the easiest way maybe implementing a service S1, and let
this service supporting both the interface C and D.
then new programs using interface D query S1, and the existing
programs still query the service S.
is there any other method to accomplish this? I want to new programs
can access the interface D still through S instead of S1, S1 is not a
friendly name I think ;@)
thank you very much!
best wishes, Rainman.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] is there a THREAD-MODEL in URE?
hi, everyone I noticed that there was some articles about Threading Model, and Threading Architecture In URE. but I cannot find any technical detail about how to use them, so I just wondered whether they have been implemented in URE or they are just about to be implemented. thank you. best wishes, Rainman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] ERROR: can't rename temporary file... when building BEA300_m2
hi, everyone when building BEA300_m2 on Windows platform with VC9, during the job external_deliver in modual external, I got the following error: deliver: /cygdrive/f/CoreProjects/BEA300_m2/external/prj/d.lst: ERROR: can't rename temporary file to f:/CoreProjects/BEA300_m2/solver/300/wntmsci12.pro/bin: Is a directory deliver -- version: 1.126 COPY: ../msvcp90/Microsoft.VC90.CRT.manifest - f:/CoreProjects/BEA300_m2/solver/300/wntmsci12.pro/bin LOG: writing f:/CoreProjects/BEA300_m2/solver/300/wntmsci12.pro/inc/external/deliver.log Statistics: Files copied: 0 Files unchanged/not matching: 40 so what does it mean and what can I do? THANK YOU! best wishes, Rainman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Please help for creating com.sun.star.awt.Toolkit service
hi Carsten, it's ok. but I still think that there might be something not initialized though it's not VCL. thank you very much, I will keep trying to find the murderer. ;) best wishes, Rainman. On Fri, Jun 20, 2008 at 8:59 PM, Carsten Driesner [EMAIL PROTECTED] wrote: Rainman Lee wrote: thank you very much Carsten! I will try it. but, I guess i was missing something by far. I notice that there is a InitVCL call, in the file you mentioned. but it seems that it need something like a static or dynamic lib to get it work. where can I get such a lib, should I compile the vcl project on my computer or I can just download it somewhere. thank you, and hope your reply. Hi Rainman, Sorry for the wrong information. I missed a special part inside the toolkit project which takes over the VCL initialization in case the Application object is not in execute mode, which is true in your case. Currently I am without a clue why you can see a crash creating com.sun.star.awt.Toolkit. May be you can write an issue via Issue Tracker and attach some sample code to reproduce your problem. Regards, Carsten - 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] Please help for creating com.sun.star.awt.Toolkit service
thank you very much Carsten!
I will try it.
but, I guess i was missing something by far.
I notice that there is a InitVCL call, in the file you mentioned. but it
seems that it need something like a static or dynamic lib to get it work.
where can I get such a lib, should I compile the vcl project on my computer
or I can just download it somewhere.
thank you, and hope your reply.
best wishes, Rainman.
On Thu, Jun 19, 2008 at 11:14 PM, Carsten Driesner [EMAIL PROTECTED]
wrote:
Rainman Lee wrote:
hello everyone,
I'm trying to use uno controls independently without OO runing.
but when I try to create the com.sun.star.awt.Toolkit service in my
program,
it crashes.
I have tried to create other services (e.g. UnoButtonModel), and it seeems
ok.
I use OOo 2.4 on windows platform with Visual C++ for this testing, and
here
is how I do:
first, I implement a uno component with XMain interface.
in its run method, I just try to get the service manager through the
component context that I have restored during the component instantiation.
virtual ::sal_Int32 SAL_CALL run(const Sequence ::rtl::OUString
aArguments) SAL_THROW((RuntimeException))
{
if (m_xContext.is())
MessageBox(NULL, TEXT(1 OK!), TEXT(Msg), MB_OK);
Referencelang::XMultiComponentFactory xMultiFactory =
m_xContext.get()-getServiceManager();
if (xMultiFactory.is())
MessageBox(NULL, TEXT(2 OK!), TEXT(Msg), MB_OK);
ReferenceXInterface xInterface =
xMultiFactory.get()-createInstanceWithContext(Lcom.sun.star.awt.Toolkit,
m_xContext);
if (xInterface.is())
MessageBox(NULL, TEXT(3 OK!), TEXT(Msg), MB_OK);
return 0;
}
then I register all uno dll components in [OFFICE_PROGRAM_PATH] with my
component into a new rdb file.(myservices.rdb)
finally I run uno -s MY_SERVICENAME -ro myservices.rdb to startup my uno
component.
when the component is runing, it shows the first two message boxes as
expected, and crashes without showing the last one.
but if I replace com.sun.star.awt.Toolkit with
com.sun.star.awt.UnoButtonModel or
com.sun.star.awt.ContainerWindowProvider instead, it runs correctly with
all message boxes displayed.
so why cant I create the Toolkit service in my component? does this
serivce
depend on other services or things which I haven't prepared ready?
hope for your reply, and thanks very much!
Hi Rainman,
You have to make sure that VCL is properly initialized before you can use
UNO awt! UNO awt is a wrapper around VCL and cannot work correctly if VCL
has not been initialized. To initialize VCL you have to call InitVCL(...).
You can find how to call InitVCL in the desktop project, e.g. look within
desktop/source/pkgchk/unopkg/unopkg_misc.cxx at the function getUNO(...).
There is also a function called DeInitVCL().
Regards,
Carsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] error: cannot run /bin/sh when runing OOo 2.4.x build configure
hi everyone, I was trying to build OOo 2.4.x on my Windows platform using Cygwin. after I ran bash configure --with-win32, in config_office directory, it reported: configure: error: cannot not run /bin/sh ../solenv/bin/config.sub what's wrong with it? does that mean there was lack of sh in my bin directory? if so, where can I get it? thanks best wishes, Rainman.
[dev] Please help for creating com.sun.star.awt.Toolkit service
hello everyone,
I'm trying to use uno controls independently without OO runing.
but when I try to create the com.sun.star.awt.Toolkit service in my program,
it crashes.
I have tried to create other services (e.g. UnoButtonModel), and it seeems
ok.
I use OOo 2.4 on windows platform with Visual C++ for this testing, and here
is how I do:
first, I implement a uno component with XMain interface.
in its run method, I just try to get the service manager through the
component context that I have restored during the component instantiation.
virtual ::sal_Int32 SAL_CALL run(const Sequence ::rtl::OUString
aArguments) SAL_THROW((RuntimeException))
{
if (m_xContext.is())
MessageBox(NULL, TEXT(1 OK!), TEXT(Msg), MB_OK);
Referencelang::XMultiComponentFactory xMultiFactory =
m_xContext.get()-getServiceManager();
if (xMultiFactory.is())
MessageBox(NULL, TEXT(2 OK!), TEXT(Msg), MB_OK);
ReferenceXInterface xInterface =
xMultiFactory.get()-createInstanceWithContext(Lcom.sun.star.awt.Toolkit,
m_xContext);
if (xInterface.is())
MessageBox(NULL, TEXT(3 OK!), TEXT(Msg), MB_OK);
return 0;
}
then I register all uno dll components in [OFFICE_PROGRAM_PATH] with my
component into a new rdb file.(myservices.rdb)
finally I run uno -s MY_SERVICENAME -ro myservices.rdb to startup my uno
component.
when the component is runing, it shows the first two message boxes as
expected, and crashes without showing the last one.
but if I replace com.sun.star.awt.Toolkit with
com.sun.star.awt.UnoButtonModel or
com.sun.star.awt.ContainerWindowProvider instead, it runs correctly with
all message boxes displayed.
so why cant I create the Toolkit service in my component? does this serivce
depend on other services or things which I haven't prepared ready?
hope for your reply, and thanks very much!
best wishes!
Rainman.
Re: [dev] Please help for creating com.sun.star.awt.Toolkit service
I just googled my problem, and there was a same problem 3 years ago.( http://osdir.com/ml/openoffice.devel.udk/2005-09/msg00076.html) but unfortunately, no solution at that time. Is there someone kind can fix it today? thanks again. best wishes, Rainman On Thu, Jun 19, 2008 at 8:30 PM, Stephan Bergmann [EMAIL PROTECTED] wrote: Eike Rathke wrote: Hi Rainman, On Thursday, 2008-06-19 16:13:01 +0800, Rainman Lee wrote: [...] ReferenceXInterface xInterface = xMultiFactory.get()-createInstanceWithContext(Lcom.sun.star.awt.Toolkit, m_xContext); [...] when the component is runing, it shows the first two message boxes as expected, and crashes without showing the last one. I'm almost certain that Lsome string is the culprit, because the method expects a rtl::OUString there. Use rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(com.sun.star.awt.Toolkit)) instead. On Windows, the L... version should also work, by accident. (sal_Unicode is a typedef for wchar_t there, and there is a non-explicit rtl::OUString(sal_Unicode const *) ctor). -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
