Help with cursor callback.

[Jon Cooper]

Hello, I have a text input widget which takes a single line of text and has a scrollbar widget beneath it that lets the user move the cursor in the visible text. 

This only works once the user has clicked somewhere in the text so that the cursor is visible and I am quite happy with that. If the user moves the cursor with the left or right keyboard arrows and inserts extra text or deletes text at some point in the string, as soon as the string changes, there is a callback that moves the scroll bar to the part of the string that is being edited. That is good because it shows where the changes are being made relative to the length of the string. 

What I would like it to do is to move the scrollbar whenever the user navigates with the left or right keyboard arrow. Note I mean the keyboard arrows, not the left or right scroller arrows which work correctly. At the moment the callback which moves the slider is set to be called by:

inpseq->when(FL_WHEN_CHANGED); 

and I have tried the various options like WHEN_NOT_CHANGED, WHEN_RELEASED, WHEN_NOT_RELEASED and WHEN_NOT_RELEASED_ALWAYS but these don’t work for my purposes. 

I also tried changing Greg’s function which pastes in the text with a right mouse click (!) to add something which detects left and right arrow keyboard events. 

With that, if I click somewhere in the text to edit it, I am not longer able to make any changes or move the cursor left or right, but it does move the slider! Evidently the red text above says the code is ‘masking’ the keyboard keys from their normal role!! Is there anyway that I can unmask them from this!? 

Sorry, I am still on 1.3.8 and meanwhile I will try to update as far as my linux distro and 20 YO computer allow, in case that helps. Cheers, Jon.C.

[Ian MacArthur]

Without seeing more of your code in context, it's hard to be sure, since there are a number of things that could be awry here.

However, there are a few things that strike me straight away.

Firstly, what do you think the line:

          if ( Fl::event_button() == FL_Left | FL_Right) {

Is testing for?

I'm assuming you envisage that as saying "If ( Fl::event_button() == FL_Left) || ( Fl::event_button() == FL_Right  )" but that's not what you have coded.

That test will OR FL_Left  with FL_Right, i.e. ( 0xff51 | 0xff53 ) then test the result (which results in just 0xff53 again, or FL_Right) so in effect that's ONLY looking for FL_Right.

I doubt that's what you intended.

The next issue might be the:

       return (1);

Or, by extension, whatever value you are returning from your handle method.

If you want the event to be propagated to other widgets, then you should not be returning non-zero here. In FLTK, if a handle method returns non-zero for an event, the system assumes that event has been "used" and does not pass it on to any other widget.

So if you want to catch an event, but also propagate it to other widgets, you need to be careful with what the handle methods return. For a derived classes handle() method, it is common to explicitly call the handle() method of the base class (either before or after your own added checks) and to determine the return value based on appropriate logic from that.

Or if you just want to see that an event occurred, but not "interfere" with it at all, you might just return 0.

As it stands, I suspect that your derived handle method is "eating" all the keyboard events and not allowing them to pass on to the rest of the code, but we cannot see enough of your method to know for sure.

Anyway, some ideas to poke at - hope that helps.

[Albrecht Schlosser]

On 8/12/26 10:03 Ian MacArthur wrote:

Without seeing more of your code in context, it's hard to be sure, since there are a number of things that could be awry here.

However, there are a few things that strike me straight away.

Firstly, what do you think the line:

          if ( Fl::event_button() == FL_Left | FL_Right) {

Is testing for?

I'm assuming you envisage that as saying "If ( Fl::event_button() == FL_Left) || ( Fl::event_button() == FL_Right  )" but that's not what you have coded.

That test will OR FL_Left  with FL_Right, i.e. ( 0xff51 | 0xff53 ) then test the result (which results in just 0xff53 again, or FL_Right) so in effect that's ONLY looking for FL_Right.

I doubt that's what you intended.

And, that all said, let me extend what Ian wrote: Fl::event_button() is the wrong method to use here!

FL_Left and FL_Right are keyboard key values which would be the correct keys to test, but then Fl::event_key() would be the proper method to use inside `case FL_KEYBOARD:`, something like:

    if (Fl::event_button() == FL_Left) || (Fl::event_button() == FL_Right) {

Note also that Fl::event_button() is only defined when used inside mouse button press event handling and returns distinct (enum) values for the respective mouse buttons (FL_LEFT_MOUSE, FL_MIDDLE_MOUSE, FL_RIGHT_MOUSE, FL_BACK_MOUSE, FL_FORWARD_MOUSE), see documentation here:
https://www.fltk.org/doc-1.3/group__fl__events.html#ga7ae6d99ceb1a2afb8a1dc4455ac941cd

Note that the last two values were added in a later update than 1.3.8 (the docs of 1.3.8 don't mention them, and I remember that they have been added during 1.3/1.4 development).


@Jon Cooper: I suggest to upgrade at least to the current 1.3 release, i.e. from 1.3.8 to 1.3.11 (there will definitely be no more 1.3.x releases). I also recommend to upgrade to 1.4.5 or any later 1.4.x release (if there will be such releases after 1.4.5). FLTK 1.4 is backwards compatible (API), but please read the documentation, particularly chapter "Migrating Code from FLTK 1.3 to 1.4":
https://www.fltk.org/doc-1.4/migration_1_4.html

The introduction of screen scaling and Wayland support added some subtle differences you should be aware of, and FLTK 1.4 no longer includes Windows (VS) and macOS (Xcode) IDE files.

[Albrecht Schlosser]

Sorry, silly copy-paste bug!

On 8/12/26 14:40 'Albrecht Schlosser' wrote:

FL_Left and FL_Right are keyboard key values which would be the correct keys to test, but then Fl::event_key() would be the proper method to use inside `case FL_KEYBOARD:`, something like:

    if (Fl::event_button() == FL_Left) || (Fl::event_button() == FL_Right) {

should read:

    if ((Fl::event_key() == FL_Left) || (Fl::event_key() == FL_Right)) {

You may omit the inner parentheses.

Disclaimer: untested.

[Jon Cooper]

Hello Ian and Albrecht. Thank you for looking at that. I knew it had to be my natural stupidity. I will try as you suggested and let you know. As regards version, I got it up to 1.4.5 without any major issues. Thank you again.

[Albrecht Schlosser]

On 8/12/26 16:29 'Jon Cooper' wrote:
> Hello Ian and Albrecht. Thank you for looking at that.

Welcome.

> As regards version, I got it up to 1.4.5 without any major issues.

Great to read that. If there were issues caused by FLTK (maybe docs) and
not your software in particular [1], I'd appreciate getting your
feedback. Just in case we need to improve our docs.

----

[1] Also, just to know: are you using a stock FLTK release, or do you
use some local patches? In my first experiences with FLTK I used my own
local patches, but later I decided that it would be better to do
everything in user code - which was indeed possible. That's much easier
for later upgrades. Just my 2 ct.

[Bill Spitzak]

I think you need to call the base class event handler from your event handler. Do that before getting the cursor position.

In fact you might want to do this after *any* keystroke, and maybe mouse-up or others. All of them can move the cursor.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/5d01cee4-5564-4b82-9b65-98556200a664%40aljus.de.

[Jon Cooper]

Thank you all for your help which gave me critical clues. I got it to work as I was hoping with the following. I had to get rid of the "OR" and just treat the left arrow key and right arrow key clicks as separate things and specify the new cursor and scroller positions after each click.

Do please let me know if there is a neater or less repetitive way of doing it. It works fine for my purposes now anyway. I never thought it would work so thanks again! 

[Jon Cooper]

Sorry, I forgot to mention about upgrading from 1.3.8 to 1.4.5. I can't remember exactly the order of things but the files from github didn't work initially with "sudo ./configure" so I eventually had to run it with "sudo ./configure --disable-xft" but I actually can't remember what I was doing very well and I had bad fonts initially but this is the command history which I can find, although I am not sure if it is everything: 

  430  sudo apt-get -y install libxft-dev
  431  apt --fix-broken install
  432  sudo apt --fix-broken install
  433  sudo apt-get -y install libxft-dev
  434  sudo ./configure
  435  make
  436  sudo make install
  437  ./configure
  438  install pkg-config
  439  configure --disable-xft
  440  sudo ./configure
  441  pwdd
  442  cd ..
  443  ls -lrt
  444  dpkg -i fltk-options_1.4.4-4_amd64.deb
  445  sudo dpkg -i fltk-options_1.4.4-4_amd64.deb
  446  sudo dpkg -i fltk-options_1.4.4-4_amd64.deb
  447  ls -lrt
  448  sudo dpkg -i fltk-options_1.4.3-1_amd64.deb
  449  ls -lrt
  450  sudo dpkg -i fltk-options_1.4.4-4_amd64.deb
  451  sudo ./configure
  452  pwdd
  453  pwd
  454  ls
  455  cd fltk-1.4.5
  456  sudo ./configure
  457  sudo ./configure --disable-xft
  458  make
  459  sudo make install

A lot of those commands didn't work or help but it eventually runs 1.4.5 and the fonts look normal. I remember installing a deb for fltk-options but I can't remember if it worked or helped, sorry!!

[Ian MacArthur]

On Thursday, 13 August 2026 at 00:45:02 UTC+1 jonathanbart... wrote:

Sorry, I forgot to mention about upgrading from 1.3.8 to 1.4.5. I can't remember exactly the order of things but the files from github didn't work initially with "sudo ./configure" so I eventually had to run it with "sudo ./configure --disable-xft" but I actually can't remember what I was doing very well and I had bad fonts initially but this is the command history which I can find, although I am not sure if it is everything: 

Just a note that, form FLTK 1.4 onwards, the preferred configure scheme is to use cmake rather than to use the legacy configure scripts.

The cmake scheme _might_ do a better job  of tailoring to your machine. (Even on an older system, cmake is pretty well supported now...)

A quick recipe for that.

cd into the folder that fltk-1.4.5 is in.

mkdir build_v1

cd build_v1

cmake -G "Unix Makefiles"  ..

make -j4

And see how that gets on. Any issues, let us know!

Also, note the "two dots" on the end of the cmake command line - they are part of the command, and need to be there!

[Bill Spitzak]

It would be simpler and more reliable to do something like this:

  if (Fl_Input::handle(e)) {

     set_scrollbar(cursor, length);

     return true;

  }

  return false;

This would update the scrollbar after any possible change done to the text. I think you also want to handle the length of the text changing.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/6a457264-507e-4c99-ae55-32408160d30an%40googlegroups.com.

[Jon Cooper]

Hello, thank you. I have a callback function which determines the length of the text and sets the scroll bar limits. It is called when the text is changed. Here is a link to a minimal example demonstrating what I have: https://pastecode.io/s/8ervprkr

It almost works as I would like. The only thing that does not work is that if you change the insertion point in the text by clicking somewhere with the left mouse button, the scroll bar position does not register the change in the cursor position or update.

I think what you suggested should sort that out but my C/fltk/brain is not good enough to know how to put it in the code, sorry, but I will keep trying ...

[Brian Larsen]

In your "int handle(int e)" routine, try adding this block to your switch statement.

case FL_PUSH:
  if (Fl::event_button() == FL_LEFT_MOUSE) {
    // Let FLTK handle the updating the mouse position for inpseq.
    Fl_Input::handle(e);

    // Get the updated mouse position and adjust the scroller.
    cursor_pos = inpseq->insert_position();
    scroller->value(cursor_pos);

    return(1);
  }

  break;

[Jon Cooper]

Thank you very much. That does work perfectly!!