XtSetSensitive problem - Motif

This is a discussion on XtSetSensitive problem - Motif ; Hi, I have a problem with my application. When I invoke the XtSetSensitive function on the base widget of the graphic component I want to disable, the widget (and all its child widgets) doesn't turn into grey untill I move ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: XtSetSensitive problem

  1. XtSetSensitive problem

    Hi, I have a problem with my application.

    When I invoke the XtSetSensitive function on the base widget of the
    graphic component I want to disable, the widget (and all its child
    widgets) doesn't turn into grey untill I move the mouse or click it.

    Do you know why?

    Thank you

    Luca

  2. Re: XtSetSensitive problem

    lcdll@libero.it (Luca) wrote in
    news:a97dd389.0312230736.4f8d99ff@posting.google.c om:
    > When I invoke the XtSetSensitive function on the base widget of the
    > graphic component I want to disable, the widget (and all its child
    > widgets) doesn't turn into grey untill I move the mouse or click it.


    Subject 211 in the Motif FAQ. My web site has a copy of the FAQ.

    Ken Lee, http://www.rahul.net/kenton/

  3. Re: XtSetSensitive problem

    Ken Lee wrote in message news:...
    > lcdll@libero.it (Luca) wrote in
    > news:a97dd389.0312230736.4f8d99ff@posting.google.c om:
    > > When I invoke the XtSetSensitive function on the base widget of the
    > > graphic component I want to disable, the widget (and all its child
    > > widgets) doesn't turn into grey untill I move the mouse or click it.

    >
    > Subject 211 in the Motif FAQ. My web site has a copy of the FAQ.
    >
    > Ken Lee, http://www.rahul.net/kenton/


    hi ken, I saw the subject 211 in the Motif FAQ but it didn't solve the
    problem:

    "Answer: For each change you make, the widget decides if it needs to
    redraw.
    If so, Xt calls XtClearArea to generate an expose event. You main
    loop
    dispatches the resulting expose event to your widget, causing a
    redisplay.
    Note that the redisplay may be delayed somewhat if you do not
    immediately
    return to the event loop after calling XtSetValues. You can often
    work around
    this by calling XmUpdateDisplay()."

    First of all, I think that calling XtSetSensitive on a widget, should
    cause the widget to call XtClearArea, resulting in the widget being
    redrawn.

    Second, I suppose the answer in the faq assumes the call to
    XtSetSensitive is made from inside some callback , since it says "Note
    that the redisplay may be delayed somewhat if you do not immediately
    return to the event loop after calling XtSetValues"

    My case is different: I call XtSetSensitive from a separate task, from
    which I have access to the pointer to the component's base widget I
    want to set sensitive or insensitive.

    I've also tried to use XmUpdateDisplay, but sometimes it works,
    sometimes I get back strange aSync error messages from the X server.

    The fact that the widget becomes grey as sson as I click the mouse,
    implies that the XtClearArea to generate the expose event is sent by
    the widget, am I right?

    Please can you check my follwoing sequence of actions and see if it's
    right?

    1.I call XtSetSensitive(w, false) on the widget w I want to disable

    2.Internally the function does what it has to do (setting the
    sensitive resource and optionally traversing the widget tree setting
    the ancestor_sensitive resource...)

    3.Before exiting, let's assume the XtSetSensitive function calls
    XClearArea Xlib function

    4.the execution of this function causes an X protocol request to be
    sent to the X server

    5.the X server, in its turn, on receipt of this request, sends back to
    the widget an expose event

    6.the event is sent to the Xt event queue.

    7.the Xt event loop extracts (sooner or later) it from the queue and
    dispatches the event to the widget that redraws itself

    If what I've just said is true, for some reason the expose event isn't
    extracted from the queue and dispatched untill I injects some other
    events into the queue for example by clicking the mouse.

    If I'm wrong, there's something about the way X works that I've
    misundestood.

    Can you help me in some way?

    Thank you

    Luca

  4. Re: XtSetSensitive problem

    Luca wrote:
    > First of all, I think that calling XtSetSensitive on a widget, should
    > cause the widget to call XtClearArea, resulting in the widget being
    > redrawn.


    Consider the push buttons inside a menu. When you call XtSetSensitive, the
    menu isn't necessarily being displayed, so forcing a redraw would be wrong.

    While a pull down menu is not active , with just the menu bar visible, are the
    individual push buttons in the menu managed or unmanaged ? If they are
    managed, in what stated are they to be invisible ? (sorry for newbie question).


    > The fact that the widget becomes grey as sson as I click the mouse,
    > implies that the XtClearArea to generate the expose event is sent by
    > the widget, am I right?


    Does the "I click the mouse" mean that you can click anywhere in the window
    and the widget then changes appearance, or is it only when you click on the
    widget that the SetSensitive change becomes visible ?

    > 3.Before exiting, let's assume the XtSetSensitive function calls
    > XClearArea Xlib function


    Shouldn't it simply flag the widget as needing update on the display so that
    at the end of the even handling, the X client will send to the x server the
    list of widgets to update ?

  5. Re: XtSetSensitive problem

    JF Mezei wrote in message news:<3FE9DFAA.714BE8C0@istop.com>...
    > Luca wrote:
    > > First of all, I think that calling XtSetSensitive on a widget, should
    > > cause the widget to call XtClearArea, resulting in the widget being
    > > redrawn.

    >
    > Consider the push buttons inside a menu. When you call XtSetSensitive, the
    > menu isn't necessarily being displayed, so forcing a redraw would be wrong.


    Yes, you're right, I meant calling XtSetSensitive on widgets currently
    visible

    >
    > While a pull down menu is not active , with just the menu bar visible, are the
    > individual push buttons in the menu managed or unmanaged ? If they are
    > managed, in what stated are they to be invisible ? (sorry for newbie question).


    I think that the pulldown mwnu and its items get managed when the user
    clicks on the cascade button that causes the pulldown menu to be
    popped down

    >
    >
    > > The fact that the widget becomes grey as sson as I click the mouse,
    > > implies that the XtClearArea to generate the expose event is sent by
    > > the widget, am I right?

    >
    > Does the "I click the mouse" mean that you can click anywhere in the window
    > and the widget then changes appearance, or is it only when you click on the
    > widget that the SetSensitive change becomes visible ?


    It means "anywhere I click in the screen where there is a widget
    (visible) whose sensitive state is true"

    >
    > > 3.Before exiting, let's assume the XtSetSensitive function calls
    > > XClearArea Xlib function

    >
    > Shouldn't it simply flag the widget as needing update on the display so that
    > at the end of the event handling, the X client will send to the x server the
    > list of widgets to update ?


    I don't know

    I think that my problems arise from the fact that I'm calling the
    XtSetSensitive function from a separate task and not from inside the
    task where there is the Xt event loop (XtAppMainLoop).
    I also have to say that my case is particular in that I'm writing my
    application on VxWorks using the porting to VxWorks of X/OpenGL.
    VxWorks dosn't have the concept of thread, you can only create tasks,
    but all tasks share the same address space, that's why I'm able to
    access widgets created by one task from another task

  6. Re: XtSetSensitive problem

    Luca wrote:
    > I think that my problems arise from the fact that I'm calling the
    > XtSetSensitive function from a separate task and not from inside the
    > task where there is the Xt event loop (XtAppMainLoop).


    Have you considered having the main app define an event that triggers a
    callback (and in that callback, you use the SetSensitive). And then, from your
    separate task, you generate that event. Thsi way, the main task gets
    "awakened", calls the callback that then performs the set sensitive).

  7. Re: XtSetSensitive problem

    BTW, on VMS where we have asynchronous routines (for instance for IO
    completion), this is the recommended way to interface with the X system since
    ASTs can interrupt the mainline code at a time when you can't call another X
    system service (for instance, if the mainline is already within an X routine).

    The event queing routine (name escapes me at the moment) is AST reentrant on VMS.

  8. Re: XtSetSensitive problem

    JF Mezei wrote in message news:<3FF348FA.C1E468D4@istop.com>...
    > Luca wrote:
    > > I think that my problems arise from the fact that I'm calling the
    > > XtSetSensitive function from a separate task and not from inside the
    > > task where there is the Xt event loop (XtAppMainLoop).

    >
    > Have you considered having the main app define an event that triggers a
    > callback (and in that callback, you use the SetSensitive). And then, from your
    > separate task, you generate that event. Thsi way, the main task gets
    > "awakened", calls the callback that then performs the set sensitive).


    That could be a solution, but in any case, given that I have defined a
    new event type, when I inject it into the event queue, I do that from
    a separate task, so I run the risk of getting async error messages
    because there can be two tasks accessing the event queue at the same
    time, and X is not "task safe".

    Anyway it's worth trying.

    For defining new event types, have I got to look in the Xlib
    documentation or in the Xt one, maybe more likely both of them

    Thank you

    Luca

  9. Re: XtSetSensitive problem

    JF Mezei wrote in message news:<3FF349BD.3A74D29F@istop.com>...
    > BTW, on VMS where we have asynchronous routines (for instance for IO
    > completion), this is the recommended way to interface with the X system since
    > ASTs can interrupt the mainline code at a time when you can't call another X
    > system service (for instance, if the mainline is already within an X routine).
    >
    > The event queing routine (name escapes me at the moment) is AST reentrant on VMS.


    Sorry for my ignorance, but I don't know what BTW, VMS and AST stand for.
    Can you tell me their meanings?

    Thank you
    Luca

  10. Re: XtSetSensitive problem

    Luca wrote:
    > That could be a solution, but in any case, given that I have defined a
    > new event type, when I inject it into the event queue, I do that from
    > a separate task, so I run the risk of getting async error messages
    > because there can be two tasks accessing the event queue at the same
    > time, and X is not "task safe".


    Then consider taking a lock prior to injecting an event and release it after.
    This way, if one task tries to inject an event while another is in the process
    of injecting one, the first one will wait when it requests the lock until the
    second one releases the lock.

    and to answer your other questions, an AST on VMS and an Asynchronous System
    Trap. On some other routines, they call them "completion routines", although
    the VMS implementation is more versatile. You specify a routine and argument
    to execute when a certain condition occurs.

    When that condition occurs, that routine interrupts whatever else your program
    was doing and executes in its own context (you won't be messing with the
    mainline's registers etc). Once the AST routine returns control, the mainline
    continues where it had left off, oblivious to what had happened. ASTs are
    queued for execution, one at a time. So if you have a timer that triggers and
    AST at the same time as an IO that completes, then the second one will wait
    until the first AST routine as completed before it executes.

+ Reply to Thread