| | [ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | SVN ⇄ GIT ]
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: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| #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 | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
