dbus errors
Jeff Mitchell
kde-dev at emailgoeshere.com
Sun Apr 13 14:46:40 CEST 2008
On Saturday 12 April 2008, Thiago Macieira wrote:
> Jeff Mitchell wrote:
> >Jeff Mitchell wrote:
> >> Peter Kümmel wrote:
> >>> Christian Ehrlicher wrote:
> >>>>> Unfortunately, it doesn't produce anything. It just shifts the
> >>>>> errors down by one line...no warnings about previous definitions of
> >>>>> interface are given.
> >>>>>
> >>>>> However, doing:
> >>>>> #undef interface
> >>>>>
> >>>>> Makes compile work again.
> >>>>>
> >>>>> How do I solve this? It's probably a result of including some of
> >>>>> the various Microsoft files I needed to include in order to get WMI
> >>>>> methods written. But I don't really want to #undef things that are
> >>>>> supposed to be defined willy-nilly, nor can I expect that "patch
> >>>>> Qt" is a reasonable answer :-)
> >>>
> >>> You could also remove "interface" in the Qt header or rename it, the
> >>> name isn't important in the header:
> >>>
> >>> static QDBusMessage createSignal(const QString &path, const QString
> >>> &interface_this_name_is_totally_arbitrary, const QString &name);
> >>>
> >>> Then we could try to post a patch to Trolltech not to use "interface"
> >>> as name for variables in declaration.
> >>
> >> Thiago, is there a snowball's chance in hell of this happening?
> >> (especially in 4.4?) I'm including some standard include headers in
> >> my files on Windows to query WMI for hardware information. I'm still
> >> trying to pinpoint the exact MS include file that is causing
> >> this...there are several that #define interface, but so far none that
> >> appear in my includes list...but I haven't been able to check the
> >> normal VC includes yet (i.e. I don't *think* that any of the Win2K3
> >> SDK ones are defining it).
> >
> >Testing this, I forgot that there's a method named interface()...it
> >doesn't only appear in unimportant places. Which means that to change
> >it would be to break API...not going to happen. Not sure if an "#undef
> >interface" might be possible...
>
> The solution is the same as for X11.h:
>
> 1) do not include it if you can help it
> 2) include it LAST then include a fix header (similar to fixx11h.h)
>
> Try to keep all includes of platform-specific stuff to platform-specific
> files.
It is a platform-specific file...the WMI backend for Solid is only built on
Windows.
The only way I can see going forward right now is either dropping a Microsoft
include (which I don't think is possible, since I'm using the includes that
MSDN used in its WMI example) or not having any dbus connectivity in the WMI
backend. This might be okay...I was hoping to avoid it though.
I took a look at fixx11h.h. If we need dbus with Solid on Windows, I'll do
something similar.
Thanks for the pointer to that file...
Jeff
More information about the Kde-windows
mailing list