Cue banner (prompt text) for empty scintilla window

[i***@gmail.com]

Good afternoon all,

This might be a silly question, and I hope it is - then someone call tell
me off and give a quick pointer for the answer.

I am using scintilla windows in a few places in my application, and want to
be able to put in a hint text for what they are used for when they are
empty. Essentially, I want the same functionality as MS edit windows have
with EM_SETCUEBANNER:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb761639(v=vs.85).aspx

I could probably subclass the window, and hook the WM_PAINT mechanism for
the window, and put up my own text, but this is fiddly, and possibly
fragile. If the ability exists within scintilla, that'd be great!

Thanks,

Iain,

[Neil Hodgson]

Scintilla does not directly support this.

I could probably subclass the window, and hook the WM_PAINT mechanism for the window, and put up my own text, but this is fiddly, and possibly fragile.

Add the cue text to Scintilla. When a key is pressed, remove the cue and allow the key to go through.

Neil

[i***@gmail.com]

Post by Neil Hodgson
Scintilla does not directly support this.

...

Post by Neil Hodgson
Add the cue text to Scintilla. When a key is pressed, remove the cue
and allow the key to go through.
Neil

In hindsight, my idea of subclassing the window and handling WM_PAINT when
there's no text is a bad one - what about margins? What about DirectWrite,
and non MS platforms? So, to be fair, I should think of a Scintilla
friendly way.

There are problems with your idea of adding text to Scintilla, and removing
it when a key gets pressed...
1) Easy to mess up, especially if there were several scintilla windows
involved.
2) This text would be actually be in the window - it would be selectable,
copyable, and so on.
3) Any lexer and equivalent settings would have to be turned on or off too
- it wouldn't be good if the hint text ended up getting syntax highlighted
too!
4) You could no longer just do m_wndFancyEdit.GetText (...), you'd have to
check if the hint text was enabled, and so on.
There are other reasons, I'm sure, and it's a fragile solution.

To add this to scintilla, you'd need a couple of messages, I think:
SCI_HINTSETTEXT,<unused>, const char *szHint, with NULL/"" being don;t
bother
SCI_HINTSETSTYLE, nStyle, where nStyle is the style number to be used to
display the text.

So, you could do:
SCI_STYLESETITALIC, n, 1
SCI_STYLESETFORE, n, RGB(128,128,128)
SCI_HINTSETSTYLE, n
SCI_HINTSETTEXT, 0, "Enter custom code here"

n could be any valid style number. As it would not apply to any cell, it
could be above 32, and hence use the last predefined style number.

I don't mind doing the digging and seeing what's involved - it would not be
my first contribution to scintilla - but I'd like a blessing of the idea
first. I've got a lot of benefit from scintilla, so I'm happy to give back,
and I think this is a good idea, but I doubt its worth my effort if I'd be
the only one ever using it.

Thanks,

Iain.

[Neil Hodgson]

In hindsight, my idea of subclassing the window and handling WM_PAINT when there's no text is a bad one - what about margins? What about DirectWrite, and non MS platforms? So, to be fair, I should think of a Scintilla friendly way.

From my point of view, I want to avoid adding much code to Scintilla. An alternate display mode may affect a lot of code.

There are problems with your idea of adding text to Scintilla, and removing it when a key gets pressed...
1) Easy to mess up, especially if there were several scintilla windows involved.
2) This text would be actually be in the window - it would be selectable, copyable, and so on.

The other side of that is that existing code would work with the feature and not have to cope with the new mode.

3) Any lexer and equivalent settings would have to be turned on or off too - it wouldn't be good if the hint text ended up getting syntax highlighted too!

Its possible applications would choose to use this to display an example instead of a prompt and that would want styling. Or they'd just want to use different styles in a prompt such as
Search for /name/ or /identifier/

4) You could no longer just do m_wndFancyEdit.GetText (...), you'd have to check if the hint text was enabled, and so on.
There are other reasons, I'm sure, and it's a fragile solution.

I'm seeing fragility from the other side.

I don't mind doing the digging and seeing what's involved - it would not be my first contribution to scintilla - but I'd like a blessing of the idea first. I've got a lot of benefit from scintilla, so I'm happy to give back, and I think this is a good idea, but I doubt its worth my effort if I'd be the only one ever using it.

Looking at other implementations of cue text, there are possible options involving focus and presence of typed characters. Some implementations return to displaying the cue text when any typed text is removed.

If there is significant desire for this from others then it may be worth adding but I suspect cue text is normally wanted for simple single line input fields and not for the normal uses of Scintilla where its complexity is useful. Any implementation needs to be very simple and limited in impact, otherwise it doesn't appear worth it to me.


Neil

[Jeff Pohlmeyer]

Maybe you could hijack the calltip API to get something like you want?
(Seems like call tips and cue banners more-or-less perform the same
function.)

- Jeff