How do I do this properly

[roger tunnicliffe]

I have some code as follows:-

void win2_showChart(Fl_Widget *w, void *data)
{
    win2_accountNo_callback(win2,&xNull);
    for (int k;k<1000000;k++){;}

    win2_tabs->hide();
    win2_chart->show();
    win2->redraw();
}

win2_accountNo_callback sets a new value for FL_Output, however unless I put in the "timer" to "slow something down ??" it will not display correctly. I thought that's what win2->redraw was supposed to do ?

Cheers

Roger 

[Mo_Al_]

What's the definition of win2_accountNo_callback, does it somehow involve spawning a thread or a networked call?

It's also better to use something like an FLTK timeout, since that for-loop might be optimized out of your binary when building with optimizations.

[Greg Ercolano]

    Hmm, you shouldn't have to slow anything down to get a widget to update.
    redraw() schedules that widget (and its children) to redraw when you return
    to the application loop, and redrawing is handled by that, to ensure the
    widgets are drawn in order (parents first, then children).

    It looks like you're even telling the parent window to redraw, which should
    redraw everything in that window.

    If it's not redrawing properly, possible causes are:

        * Child widgets are created outside their parent's xywh boundaries
        * Child widgets are not parented properly, which can happen if the groups aren't end()ed.

    It would in this case help to see more of your code, esp. the part where you
    construct the widgets (win2, win2_tabs, win2_chart, etc), or if you can replicate by
    creating a small, self contained single file that is an easily buildable application
    so we can see what's going on.

    Sometimes you can discover the issue yourself in the process of building
    a simplified app, i.e. catch a bug in the construction.

[Ian MacArthur]

OK - there's a few things you need to get your head around here. The key point here is that updating the display is largely asynchronous, so calling redraw() does not *do* the redraw, it just tells the rendering system that that object needs to be redrawn next time it is the neighbourhood...

Further, this looks like a callback method?

You do not want to do *anything* time consuming in a callback method if you can avoid it, since the callbacks are inextricably linked to event processing, so any time spent in a callback will inhibit event processing and make the GUI unresponsive. Callbacks need to be quick "in and out" jobs as far as possible, with any heavy lifting deferred (agin, probably  asynchronously) to other processing "elsewhere" in your code.

The *third* observation I'd make is that I'd be quite surprised if adding an empty "for" loop actually introduces a delay - any modern compiler should be optimizing the empty loop away, unless you either have inhibited the optimizer (you might have done) or explicitly tagged the loop volatile (you did not.)

In general, if you mark an object for redraw, then it should be redrawn the next time the display is refreshed; trying to force it to draw "right now" is unlikely to be useful.

What are you trying to achieve? What effect are you seeing that seems wrong?

 

[roger tunnicliffe]

Thx for the replies people.

I've checked and I don't believe I have done this wrong:-

        * Child widgets are created outside their parent's xywh boundaries

        * Child widgets are not parented properly, which can happen if the groups aren't end()ed..

The callback relates to the alphanumeric spinner you can see here (Account No). 

I have attached the code but don't really expect anyone would be that interested so if no-one wants to do a "deep dive" then that's okay.

I also noticed that just taking a screen shot messed up the "account No" input, but I think that's because I am still messing around

developing this stuff.

I am thinking this is one of those obscure things that is just not worth the time investigating so I am happy to live with it for the time being

unless someone thinks it's a problem worth pursuing.

Thanks again

Cheers

Roger

[Greg Ercolano]

On 10/6/22 15:04, roger tunnicliffe wrote:

Thx for the replies people.

I've checked and I don't believe I have done this wrong:-

        * Child widgets are created outside their parent's xywh boundaries

    I'm working on reducing your app so it'll compile without the .cpy stuff.
    You do have to watch out for things like this:

                win2_tabs         = new  Fl_Tabs(x,y+25,x+400,y+200);
                        win2_grp1 = new Fl_Group(x,y+50,x+400,y+200,"Transaction");

    If you look closely, you'll see that the win_grp1's height is too large
    for the parent; its 'y' position is 25 pixels lower than the parent, but the
    height is the same, which means it'll extend 25 pixels beyond the bottom
    of the parent win2_tabs.

    To fix the above you'd use instead:

                win2_tabs         = new  Fl_Tabs(x,y+25,x+400,y+200);
                        win2_grp1 = new Fl_Group(x,y+50,x+400,y+200-25,"Transaction");

    I haven't checked the code yet, still working on reducing the code
    to just the GUI code, so it'll build.

[roger tunnicliffe]

Thanks for your effort  (not sure your name)

I think you will strungle without the copy files so here they are..

Thanks again

Roger

[roger tunnicliffe]

*struggle

[Greg Ercolano]

On Friday, October 7, 2022 at 11:57:12 AM UTC+11 roger tunnicliffe wrote:

Thanks for your effort  (not sure your name)

I think you will struggle without the copy files so here they are..

    Yes, mainly I needed the definition of menu_items.
    I was able to strip out all the other stuff and just use fake values.

    Since the issue seems to be focused on the "account no" widget(s)
    not displaying properly, I focused on those.

    Hmm, it looks like there's two widgets.. a spinner and an output widget,
    but based on their x,y positions.. they're in the same position?

           win2_accountNo          = new Fl_Spinner(x+50,y+25,60,20,"Account No...:");
           win2_accountNoX         = new  Fl_Output(x+50,y+25,46,20);

    Widgets really shouldn't overlap unless for sure one is set to hide()
    while the other is set to show(). But I think both are being shown
    at the same time, which would surely lead to drawing problems.

    Note that deactivate() and hide() are not the same things;
    deactivate() just "grays out" the widget and makes it ignore events
    such as clicks and keyboard input, whereas hide() makes the widget
    not draw at all, and is not involved in event handling at all.

[roger tunnicliffe]

Thx Greg.

Yes, win2_accountNoX was an effort to produce an alphanumeric spinner (I couldn't find one in fltk, I guess you could tell me if there is one).

It did not display too well as you have noted but this morning I have re-coded that with

            win2_accountNo->color(0xE1E1E100);
            win2_accountNo->textcolor(0xE1E1E100);

which hides the the numeric value nicely.

having done that and moved a bit of code around I still have the issue with timing.

It seems that without the 1,000,000 step loop it will now display "A" instead of "AAAAA" implying that it is still some sort of timing issue 

and it's not quite ready to redisplay. ??

Thx for your efforts.

[Greg Ercolano]

On 10/6/22 19:33, roger tunnicliffe wrote:

Thx Greg.

Yes, win2_accountNoX was an effort to produce an alphanumeric spinner (I couldn't find one in fltk, I guess you could tell me if there is one).

    No spinner for alphanumerics, if I understand you correctly.
    Fl_Spinner AFAIK is numeric only.

    You can of course make a custom composite widget that derives
    from an Fl_Group with two up/down buttons around an Fl_Input widget,
    the up/down buttons invoke a callback that handles cycling the
    alphanumerics in the way you want, and you can provide methods
    that get/set the value. Fl_Input would both show the value and also
    let someone just go ahead and type it in.
 
    If that sounds useful we can advise, just describe how the alphanumeric
    aspect should work.

    It's be best if for this thread if you could reduce the app to just the FLTK
    code, without the non-FLTK stuff to demo the problem. So if the problem
    ist just with the win2 window's widgets, and the menu items aren't important,
    then reduce the test app to just that, so anyone here can build and run.

It did not display too well as you have noted but this morning I have re-coded that with

            win2_accountNo->color(0xE1E1E100);
            win2_accountNo->textcolor(0xE1E1E100);

which hides the the numeric value nicely.

    I just don't think you can put both an Fl_Spinner and Fl_Output
    overlapping each other.

    That's just going to give unpredictable behavior, even if it "works".
    If the 1M "delay" is making it work, it's most likely by fluke.

    Try replacing those two widgets with just an Fl_Output and see
    if the drawing problems go away.

    If so, then you should be able to make a composite widget by deriving
    a class from Fl_Group that has up/down arrows around an Fl_Output
    that will do what you want without overlapping widgets.

[roger tunnicliffe]

Thx Greg,

I now  have a bare bones program that will highlight the problem.

Line 63 is where my "timer" is. If you leave it commented out then the win2 spinner will show a single "a".

press the up or down and you will be shown "aaaaa"

Now include the "timer" and you will find  you are shown "aaaaa" as one would expect.

I would image that, depending on the speed of your system you may need to adjust the 1,000,000 times I have used.

As I said, unless you are just plain curious I wouldn't sweat over this. I am happy use the numeric spinner as I am really

just developing this so that I can build the interface to languageONE.

Cheers

Roger

[Greg Ercolano]

On 10/7/22 16:14, roger tunnicliffe wrote:

Thx Greg,

I now  have a bare bones program that will highlight the problem.

Line 63 is where my "timer" is. If you leave it commented out then the win2 spinner will show a single "a".

press the up or down and you will be shown "aaaaa"

Hi Roger,

    Great -- I tried your new test program and get the same behavior
    with or without the for() loop; I see "aaaaa" in both cases.

    The thing you /have/ to understand is that you /cannot/ overlap the spinner
    and output widgets like you have; they are siblings (in the same group) and
    since they're both show()n at the same time, they overlap and will not draw
    correctly/consistently because they're drawing over each other.

    Just because they are defined in a particular order doesn't mean they'll
    both be redrawn in that order; sometimes one widget will need a redraw
    when the other does not, so that one will 'show through' over the other.
    And vice versa.

    There's also a problem of event delivery for overlapping widgets, esp
    when both want to consume the same events. One will eclipse events
    from the other, depending on which has focus, etc. Focus is keyboard navicable
    with keys like Tab and Shift-Tab, so playing with those I can sometimes see the
    spinner widget draw its text, and sometimes the Fl_Output.

I would image that, depending on the speed of your system you may need to adjust the 1,000,000 times I have used.

    I've modified your program (see attached) to remove the overlapping spinner
    widget,  so it just operates only with Fl_Output, and that behaves fine.

    You should find the for() loop does not matter, simply because the overlap
    is removed.

   

As I said, unless you are just plain curious I wouldn't sweat over this. I am happy use the numeric spinner as I am really just developing this so that I can build the interface to languageONE.

    Sure, either use the Fl_Spinner, or use Fl_Output, but don't use both.
    Or if you do use both, they must not overlap. They can be next to each other,
    just not one on top of the other, with both show()n at the same time.

[roger tunnicliffe]

Thx for your effort Greg, I'll press on. 

cheers

Roger