RE: [fltk.general] Fl_Text_Display - Cursor?

[MacArthur, Ian (Selex ES, UK)]

> I am wondering if someone can tell me how to
> make the cursor visible on Fl_Text_Display ?
>  I have selected a style and changed the colors
> around as I try to make it visible but I can't
> seem to get it to come up in the Fl_Text_Display
> widget.

This pretty much should Just Work.

Try the editor example in the test folder; does it work for you? Does it show the caret as desired? It ought to.

If it works, and your code does not, then try to study the example to see where things differ.


> I just wanted something so I can step through the
> text in the text display, similar to the little
> carrot in Fl_Output.

Um, I'm hoping you mean "caret" rather than "carrot" here... ;-)

Anyway, try the editor example, as I suggest above, and see how that goes. If it works, but your code does not, and you can't figure out where you have gone awry, then create a small, single file, compileable example that exhibits the fail, and we can all take a look and see what has gone wrong.




Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[dmnan]

Thanks, but the text_editor is different to the text_display.  The text_display example doesn't show a cursor unfortunately,,, Yet the Fl_Text_display page in the fltk documentation refers to a cursor / cursor style / etc..   

So I'm wondering if there is a visible cursor in the Fl_text_display widget for navigating through each character of the text display contents?

[dmnan]

Ok.

Here is some code.  I'm not having trouble with it because I don't know how to make the cursor appear. 

The code compiles fine (but still no cursor).

#include <iostream>
#include <FL/Fl.H>

#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>
#include <FL/Fl_Text_Display.H>




using namespace std;


int main(int argc, char **argv)
{


Fl_Window *mywindow = new Fl_Window(800,500,"MyWindow");


Fl_Text_Buffer buf;


Fl_Text_Display *outs = new Fl_Text_Display (50,50,200,100,0);


buf.text("Test 123     @#$%^&**");


outs->textfont(FL_BOLD);
outs->textcolor(8);
outs->selection_color(1);
outs->cursor_color(2);
outs->cursor_style(5);
outs->buffer(buf);
// I'm just not sure how to make the cursor appear outs->?


 mywindow->show(argc, argv);
  return Fl::run();
}

On Thursday, August 7, 2014 10:07:40 PM UTC+10, MacArthur, Ian (Selex ES, UK) wrote:

[MacArthur, Ian (Selex ES, UK)]

> Thanks, but the text_editor is different to the text_display. The
> text_display example doesn't show a cursor unfortunately,,, Yet the
> Fl_Text_display page in the fltk documentation refers to a cursor /
> cursor style / etc..

Well, that's not strictly correct; the Fl_Text_Editor widget derives directly from Fl_Text_Display, and most of the functionality, including the handling of cursor motion, and cursor display, come from the underlying Fl_Text_Display widget class.

However, the Fl_Text_Display widget has no input capability, and tends to "shrug off" keyboard input by default, so has no cursor *displayed* by default. However, it does *have* a cursor...

> So I'm wondering if there is a visible cursor in the Fl_text_display
> widget for navigating through each character of the text display
> contents?

Yes, you need to turn it on with Fl_Text_Display->show_cursor();

However... that may not be quite what you want, since by default a "pure" Fl_Text_Display will not take keyboard input, so whilst that will *show* the cursor, it likely still will not move in response to keyboard input.

For that, you need to do at least some of what Fl_Text_Editor does to "enable" keyboard handling...

> Here is some code. I'm not having trouble with it because I don't know how
> to make the cursor appear.
> The code compiles fine (but still no cursor).

You have not shown the cursor....

> outs->textcolor(8);
> outs->selection_color(1);
> outs->cursor_color(2);
> outs->cursor_style(5);

Try not to use "magic numbers" like that, it makes the code very hard to read / maintain, try to use the "proper" values instead... e.g.

outs->cursor_style(Fl_Text_Display::HEAVY_CURSOR);


> // I'm just not sure how to make the cursor appear outs->?

outs->show_cursor();

Here's a worked example, that shows a way (albeit a bit of a hack) to catch key events and pass them on to the Fl_Text_Display widget for processing:

++++++++++++++++++++++++++++++
// fltk-config --compile text-display.cxx
//

#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Menu_Bar.H>
#include <FL/Fl_Text_Buffer.H>
#include <FL/Fl_Text_Display.H>
#include <FL/Fl_Text_Editor.H>

//#include <FL/names.H>

#define EDIT_CLASS Fl_Text_Display
//#define EDIT_CLASS Fl_Text_Editor

#define TS 14 // default editor textsize

static Fl_Text_Buffer *textbuf = 0;

// Editor window functions and class...
class EditorWindow : public Fl_Double_Window {
public:
EditorWindow(int w, int h, const char* t);
~EditorWindow() {};
EDIT_CLASS *editor;

int handle(int ev);
};

EditorWindow::EditorWindow(int w, int h, const char* t) :
Fl_Double_Window(w, h, t),
editor(NULL)
{
// nothing to do here...
} // constructor

int EditorWindow::handle(int ev)
{
int res = Fl_Double_Window::handle(ev);

if (FL_KEYUP == ev)
{
int key = Fl::event_key();
switch (key)
{
case FL_Left:
editor->move_left();
res = 1;
break;
case FL_Right:
editor->move_right();
res = 1;
break;
case FL_Up:
editor->move_up();
res = 1;
break;
case FL_Down:
editor->move_down();
res = 1;
break;

default:
break;
}

}

// printf("handle: ev = %s, res = %d\n", fl_eventnames[ev], res);
// fflush(stdout);

return res;
} // hanlde method


static void close_cb(Fl_Widget*, void* v)
{
EditorWindow* w = (EditorWindow*)v;
w->hide();
}

static Fl_Menu_Item menuitems[] = {
{ "&File", 0, 0, 0, FL_SUBMENU },
{ "&Quit", FL_COMMAND + 'q', (Fl_Callback *)close_cb, 0 },
{ 0 },
{ 0 }
};

static EditorWindow* new_view()
{
EditorWindow* w = new EditorWindow(660, 400, "Format Text");
w->begin();
Fl_Menu_Bar* m = new Fl_Menu_Bar(0, 0, 660, 30);
m->copy(menuitems, w);
w->editor = new EDIT_CLASS(0, 30, 660, 370);
w->editor->textfont(FL_COURIER);
w->editor->textsize(TS);
w->editor->buffer(textbuf);

textbuf->text();
w->end();
w->resizable(w->editor);
w->callback((Fl_Callback *)close_cb, w);
return w;

}

int main(int argc, char **argv)
{

textbuf = new Fl_Text_Buffer;

EditorWindow* window = new_view();
window->show(argc, argv);

window->editor->cursor_style(Fl_Text_Display::NORMAL_CURSOR);
window->editor->cursor_color(FL_RED);
window->editor->show_cursor();
for (int iter = 0; iter < 16; ++iter)
{
window->editor->insert("This is a line of text to display\n");
}

return Fl::run();
}

/* end of file */

[dmnan]

Good point. Thanks for that.  I have managed to get the cursor to show now.  For some reason I didn't see this but it's showing now.

I wanted to use a display as I'm creating a formula builder which will have no keyboard inputs.  Just my own events controlling the motion of the cursor.  I suppose I could have done this with an editor but I couldn't work out how to stop keyboard editing of the editor so I stuck with the text_display.  

Works fine now, thanks.

[Greg Ercolano]

On 08/07/14 07:32, MacArthur, Ian (Selex ES, UK) wrote:
> Here's a worked example, that shows a way (albeit a bit of a hack) to catch
> key events and pass them on to the Fl_Text_Display widget for processing:

Neat, Ian!

And here's a small mod to the handle() function that adds shift-selection
to your example, so that one can extend a selection with shift + arrow keys.

Seems there are some bugs in Fl_Text_Display when used this way;
I noticed the cursor looses visibility when navigated within the
selection area, or over the first character to the right of selection.

Arguably this should all be optional behavior part of Fl_Text_Display,
so that one can use keyboard nav with Fl_Text_Display, but without being
able to change the contents.. similar to what we have currently
in Fl_Multiline_Output.


--- snip

int EditorWindow::handle(int ev) {
int res = Fl_Double_Window::handle(ev);

if (FL_KEYUP == ev) {
int key = Fl::event_key();

int shift = Fl::event_state() & FL_SHIFT;
int sel_beg=0, sel_end=0, new_pos=0, old_pos = editor->insert_position();
Fl_Text_Buffer *buff = editor->buffer();
if ( shift ) buff->selection_position(&sel_beg, &sel_end);

switch (key) {
case FL_Left:
editor->move_left();

new_pos = editor->insert_position();
if ( shift )
if ( old_pos == sel_beg ) buff->select(new_pos, sel_end); // extend left
else if ( old_pos == sel_end ) buff->select(sel_beg, new_pos); // shrink right
else buff->select(new_pos, old_pos); // new selection

res = 1;
break;
case FL_Right:
editor->move_right();

new_pos = editor->insert_position();
if ( shift )
if ( old_pos == sel_end ) buff->select(sel_beg, new_pos); // extend right
else if ( old_pos == sel_beg ) buff->select(new_pos, sel_end); // shrink left
else buff->select(new_pos, old_pos); // new selection

res = 1;
break;
case FL_Up:
editor->move_up();

new_pos = editor->insert_position();
if ( shift )
if ( old_pos == sel_beg ) buff->select(new_pos, sel_end); // extend top
else if ( old_pos == sel_end ) buff->select(sel_beg, new_pos); // shrink bot
else buff->select(new_pos, old_pos); // new selection

res = 1;
break;
case FL_Down:
editor->move_down();

new_pos = editor->insert_position();
if ( shift )
if ( old_pos == sel_end ) buff->select(sel_beg, new_pos); // extend bot
else if ( old_pos == sel_beg ) buff->select(new_pos, sel_end); // shrink top
else buff->select(new_pos, old_pos); // new selection

res = 1;
break;
default:
break;
}
}

return res;
} // handle method

--- snip

[Ian MacArthur]

On Thu Aug 07 2014 17:16:19, Greg Ercolano wrote:
>
> On 08/07/14 07:32, MacArthur, Ian (Selex ES, UK) wrote:
>> Here's a worked example, that shows a way (albeit a bit of a hack) to catch
>> key events and pass them on to the Fl_Text_Display widget for processing:
>
> Neat, Ian!

Thanks, though as I say, I do think that (although it works) this approach is a wee bit suspect; not the “proper” way...

> And here's a small mod to the handle() function that adds shift-selection
> to your example, so that one can extend a selection with shift + arrow keys.

Cool : never even occurred to me to add that!

> Seems there are some bugs in Fl_Text_Display when used this way;
> I noticed the cursor looses visibility when navigated within the
> selection area, or over the first character to the right of selection.

OK, hmm, interesting...

> Arguably this should all be optional behavior part of Fl_Text_Display,
> so that one can use keyboard nav with Fl_Text_Display, but without being
> able to change the contents..

I was wondering about that; what I think is that, rather than “adding” this to Fl_Text_Display, it would be “better” to allow Fl_Text_Editor to be set into some sort of “read only” mode...

Ideally, I suppose that is what editor->set_output(); would do to an Fl_Text_Editor widget, I guess?

But in practice, if you do actually call set_output(); on an Fl_Text_Editor widget, it just becomes unresponsive, not what I’d hoped for at all...

> similar to what we have currently
> in Fl_Multiline_Output.

Well now, I did wonder, based on the OP’s description of what he is trying to achieve, if something based on Fl_Multiline_Output or even Fl_Browser might have been a better (or at least simpler!) fir for his needs...

I suppose an Fl_Browser with your ANSI escape sequence patch might cover a lot of the needed ground.

[Greg Ercolano]

On 08/07/14 14:26, Ian MacArthur wrote:
> I was wondering about that; what I think is that, rather than "adding"
> this to Fl_Text_Display, it would be "better" to allow Fl_Text_Editor
> to be set into some sort of "read only" mode...

Ya, that's kinda what I mean; have the functionality built in
in whatever way is best.

> But in practice, if you do actually call set_output(); on an
> Fl_Text_Editor widget, it just becomes unresponsive, not what I'd hoped for at all...

I haven't really needed text display only with keyboard nav,
but I can see where it would be useful.

Perhaps it was meant to be added to the widget, but was never completed.

> Well now, I did wonder, based on the OP's description of what he is trying
> to achieve, if something based on Fl_Multiline_Output or even Fl_Browser
> might have been a better (or at least simpler!) fir for his needs...

According to the OP, he wanted Fl_Text_Display to behave like
Fl_Output with its keyboard nav caret, which I take to mean
he wants to be able to do keyboard nav text selection.

> I suppose an Fl_Browser with your ANSI escape sequence patch might cover a lot of the needed ground.

I don't know -- Fl_Browser is quite different from Fl_Output;
no word selection, no copy/paste abilities.

Fl_Help_View is another option to Fl_Text_Display, but I don't
think it has keyboard nav either, though it does have mouse
selection and ^C cut buffer ability, which is pretty amazing
actually; it's tough to do in an HTML widget. I think that was
added relatively recently (last few years).