BadPixmap when requesting a color by name. - Xwindows

This is a discussion on BadPixmap when requesting a color by name. - Xwindows ; Hi, I have been reading very many locations about similar problems but without any result. So I'm trying here now. OK, we have a "getPixelByName" method and in most cases this is working. Now, inside one dialog I get several ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: BadPixmap when requesting a color by name.

  1. BadPixmap when requesting a color by name.

    Hi,

    I have been reading very many locations about similar problems
    but without any result. So I'm trying here now.

    OK, we have a "getPixelByName" method and in most
    cases this is working. Now, inside one dialog I get several
    times the "BadPixmap" message when requesting the
    Pixel value for "white" or "black".

    I don't see why. The widget I'm using to request for the color
    is a XmText widget and I have created it before with XmCreateText.
    The error handler yells and the callstack shows the XAllocNamedColor
    calling the error handler (at least).

    However the correct color is set!
    And of course I don't want to hide the message...

    Could some help please?

    kindly
    Thomas

  2. Re: BadPixmap when requesting a color by name.

    In comp.windows.x, Thomas Lehmann

    wrote
    on Mon, 9 Jun 2008 06:03:04 -0700 (PDT)
    <6160f3b4-793f-40f2-a74e-a7f99050d48d@k37g2000hsf.googlegroups.com>:
    > Hi,
    >
    > I have been reading very many locations about similar problems
    > but without any result. So I'm trying here now.
    >
    > OK, we have a "getPixelByName" method and in most
    > cases this is working. Now, inside one dialog I get several
    > times the "BadPixmap" message when requesting the
    > Pixel value for "white" or "black".
    >
    > I don't see why. The widget I'm using to request for the color
    > is a XmText widget and I have created it before with XmCreateText.
    > The error handler yells and the callstack shows the XAllocNamedColor
    > calling the error handler (at least).
    >
    > However the correct color is set!
    > And of course I don't want to hide the message...
    >
    > Could some help please?
    >
    > kindly
    > Thomas


    First, BadPixmap has nothing to do with color allocation. Most likely a
    previous call is failing. Have you tried --sync on the command line?

    --
    #191, ewill3@earthlink.net
    Windows Vista. Now in nine exciting editions. Try them all!
    ** Posted from http://www.teranews.com **

  3. Re: BadPixmap when requesting a color by name.

    On 9 Jun., 16:55, The Ghost In The Machine
    wrote:
    > In comp.windows.x, Thomas Lehmann
    >
    > wrote
    > on Mon, 9 Jun 2008 06:03:04 -0700 (PDT)
    > <6160f3b4-793f-40f2-a74e-a7f99050d...@k37g2000hsf.googlegroups.com>:
    >
    >
    >
    > > Hi,

    >
    > > I have been reading very many locations about similar problems
    > > but without any result. So I'm trying here now.

    >
    > > OK, we have a "getPixelByName" method and in most
    > > cases this is working. Now, inside one dialog I get several
    > > times the "BadPixmap" message when requesting the
    > > Pixel value for "white" or "black".

    >
    > > I don't see why. The widget I'm using to request for the color
    > > is a XmText widget and I have created it before with XmCreateText.
    > > The error handler yells and the callstack shows the XAllocNamedColor
    > > calling the error handler (at least).

    >
    > > However the correct color is set!
    > > And of course I don't want to hide the message...

    >
    > > Could some help please?

    >
    > > kindly
    > > Thomas

    >
    > First, BadPixmap has nothing to do with color allocation. Most likely a
    > previous call is failing. Have you tried --sync on the command line?


    OK, I can see the difference when using --sync running the application
    as normal.
    How do I have to pass the --sync when using a debugger like DDD or
    insight?
    (there the option looks like as it has not been passed also the
    callstack is
    showing the same as before)

  4. Re: BadPixmap when requesting a color by name.

    In comp.windows.x, Thomas Lehmann

    wrote
    on Mon, 9 Jun 2008 23:01:47 -0700 (PDT)
    <2da127f2-90d1-439a-97f0-13491e622cf3@59g2000hsb.googlegroups.com>:
    > On 9 Jun., 16:55, The Ghost In The Machine
    > wrote:
    >> In comp.windows.x, Thomas Lehmann
    >>
    >> wrote
    >> on Mon, 9 Jun 2008 06:03:04 -0700 (PDT)
    >> <6160f3b4-793f-40f2-a74e-a7f99050d...@k37g2000hsf.googlegroups.com>:
    >>
    >>
    >>
    >> > Hi,

    >>
    >> > I have been reading very many locations about similar problems
    >> > but without any result. So I'm trying here now.

    >>
    >> > OK, we have a "getPixelByName" method and in most
    >> > cases this is working. Now, inside one dialog I get several
    >> > times the "BadPixmap" message when requesting the
    >> > Pixel value for "white" or "black".

    >>
    >> > I don't see why. The widget I'm using to request for the color
    >> > is a XmText widget and I have created it before with XmCreateText.
    >> > The error handler yells and the callstack shows the XAllocNamedColor
    >> > calling the error handler (at least).

    >>
    >> > However the correct color is set!
    >> > And of course I don't want to hide the message...

    >>
    >> > Could some help please?

    >>
    >> > kindly
    >> > Thomas

    >>
    >> First, BadPixmap has nothing to do with color allocation. Most likely a
    >> previous call is failing. Have you tried --sync on the command line?

    >
    > OK, I can see the difference when using --sync running the application
    > as normal.
    > How do I have to pass the --sync when using a debugger like DDD or
    > insight?
    > (there the option looks like as it has not been passed also the
    > callstack is
    > showing the same as before)


    run --sync

    should work in the debugger.

    --
    #191, ewill3@earthlink.net
    "Woman? What woman?"
    ** Posted from http://www.teranews.com **

+ Reply to Thread