STR #3174

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #3174

Application:FLTK Library
Status:5 - New
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Scrollbar of deactivated Fl_Text_Editor not working
Version:1.3-feature
Created By:benmotek
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files


Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 benmotek
03:56 Jan 07, 2015
In some cases, we would like to make the text in an Fl_Text_Editor uneditable (for example, when the user loads a read-only file. Clearly, an Fl_Text_Display could also be used in these cases)

Currently, we achieve this by calling deactivate() on the Fl_Text_Editor widget and this properly disables the widget and it becomes grayed out. However, this also seems to disable the scrollbars and the user is not able to scroll down the widget to read the remainder of the text.

I tried to override Fl_Text_Editor's deactivate function and reactive its scrollbar afterwards, but this didn't work. Apparently a widget is active when all of its parents are also active..

I think it would be a very useful option of the scrollbar could remain active.
 
 
#2 AlbrechtS
06:30 Jan 07, 2015
FTR: Changed title from "...now working" to "...not working".

This seems doable, although the Fl_Text_Editor widget would probably need another member variable to store a special state variable. I'm thinking of something like set_readonly() and clear_readonly(), but the addition of the member variable would break the ABI. We could do it anyway by using ABI guards.

set_output() and clear_output() don't work, as well as deactivate(), because both methods also disable the scrollbars, as the OP wrote.

As a proof of concept I disabled Fl_Text_Editor's event handling by adding

  return Fl_Text_Display::handle(event);

somewhere near the beginning of Fl_Text_Editor::handle(), and it did the job, as I expected. I didn't test further, hence there may be other side effects I didn't notice.

Question to devs: do you think that something like this (described above) is useful, or are there other (better) ways to achieve the OP's goal (except replacing the widget with Fl_Text_Display)?

The latter sounds pretty easy: you could have two widgets, both with the same text buffer, and "replace" them on the fly with hide()/show().
 
 
#3 greg.ercolano
19:51 Oct 02, 2017
I think I'm -1 on making a deactivated widget act partially activated.

However, I'm +1 for a read_only() mode of Fl_Text_Editor, as I've
needed this myself I think.

This could be a simple flag that simply short circuits the handle()
method from handling typing new characters (but allowing navigation).
Also, preventing paste() operations, both with mouse + keyboard.

One way that might work is to have the app open both an Fl_Text_Editor
and hide() one while show()ing the other. Both would share the same
Fl_Text_Buffer so there'd only be one copy of the text.
 
 
#4 greg.ercolano
19:53 Oct 02, 2017
Arg, that last paragraph in my last comment should read:

--- snip
One way that might work is to have the app open both an Fl_Text_Editor
*AND Fl_Text_Display*, and hide() one while show()ing the other.
Both could share the same Fl_Text_Buffer so there'd only be
one copy of the text.
--- snip
 
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.