Implementing Placeholder Text

[bogs]

I'm really digging LC but a number of it's desktop controls are... well, antiquated. And in dire need need of a refresh.

The base field object is quite a capable foundation on which to add a behavior script to handle these and more.

While I didn't add a behavior anything (the IDE I use is WAY before that kind of stuff), I certainly don't see the problem with the controls as is. As an example along the lines of Craigs listed up there (an old fashion solution), I knocked this together (about 3 minutes).

PlaceholderSample.livecode.zip

...a place to hold my stuff...

(768 Bytes) Downloaded 218 times

If you wanted to have a single control to drag out of it, you could make a group of it and have just that.

*Edited to add this -

Arguably this and other features like password text really should be available as variations on the standard field, no?

Lc has a standard 'ask password' variation of the dialog boxes, however, rolling your own in a field isn't terribly difficult either.

[stam]

I certainly don't see the problem with the controls as is.

The current controls do have oddities that make them suboptimal in modern systems. I still for the life of me don't understand why changing the border thickness should affect appearance as much as it does for example.

Functionally, i would agree 'there is nothing wrong'. But that doesn't make the optimal.

My point was the convenience however - which is LC's main selling point for me. Being able to just add the placeholder text as a property in the inspector panel is a much more natural and convenient way to do this. Or ticking a tick box in the inspector panel to make it a password field that obscures the text.

Yes - i can write these myself, but a) they tend to need ongoing finicking between project and as these features are not included in the IDE it means i have go hunt for this in my own libraries and add it (or re-invent the wheel again).

The control appeances do look like they below to a different decade as UIs have moved on - this needs fixing.

I would not be averse to having conveniences like this as an in-app purchase for example. This may be of benefit to all.

[bogs]

The current controls do have oddities that make them suboptimal in modern systems. I still for the life of me don't understand why changing the border thickness should affect appearance as much as it does for example.

I'm not trying to be dense (particularly), but I really am not sure what you mean by the above. Realizing that you are probably using a newer IDE than I am regularly in, I cracked 9.6 open, and placed a field on it.

I am on 'nix, dunno what OS your on, but in this picture, what appearance issue exactly are you talking about?



As far as I can tell, only the border is changed, as I'd expect it too with a 16 fold increase.

My point was the convenience however - which is LC's main selling point for me. Being able to just add the placeholder text as a property in the inspector panel is a much more natural and convenient way to do this. Or ticking a tick box in the inspector panel to make it a password field that obscures the text.

Having recently had my own debate about the way certain things get returned, I certainly can understand the point about convenience, however most of the other languages I looked at to find examples of don't include a gadget of that type either (realbasic, python, oracle adobe, etc). Instead, in the results my search turned up, you get instruction on how to turn a field into place holder **text field.

I am not saying this is right or wrong because someone else does or doesn't have the same feature, by the way, just pointing out what 'is' from what I see.

I would not be averse to having conveniences like this as an in-app purchase for example. This may be of benefit to all.

Well, you may want to look at this, I think it might suit what your looking for
http://www.droptools.sonsothunder.com/userguide.irev

You might also find this page of Ken's site interesting - http://www.droptools.sonsothunder.com/all.irev

** Realbasic / Xojo actually *does* have a text field setup with a place holder property, but as far as I can tell, it is for mobile only.

[stam]

I've used droptools to try some plugins - unfortunately did not have a great experience as the specific plugin didn't really work well and I started getting annoyed how it would inject new stacks into my project so I've got rid of it. No thanks

But that is again my point: In my mind LC should be offering standard controls that either mimic or actually are native controls -- and these include things like placeholder text, password/concealed text and other settings as baseline standard. At least for MacOS, you can see the interface guidelines here. Check out that placeholder text right there

i would not expect to have to add a plugin just to have standard features of standard controls. Yep, all these things can be programmed in, but I'm saying they would be ideally built into the IDE as they are so commonplace and standard interface elements.

I, and i'm sure almost everyone else, have limited time and i don't want spend it programming in what should be a standard interface element and what's even trickier is making it look native on each platform, i want to be building my app! -- for this i would hope the clever people designing the IDE to come up with these solutions. I'm lazy, see?


As for the odd effects of line width, see here:

The old trick of creating an embossed look is outdated both in the sense that this is no longer a good or accepted look on mac/win and also in sense of how this is implemented.

Another example is how if you set a button to 'transparent' style, click it produces an extremely ugly variation of this, instead of a fill effect:

yep, i know i can change this - but i have to keep doing that every time... The less said about the tab bar, the better...

In the grand scheme of things these are lesser niggles and i'm really enjoying and investing a lot of time in LiveCode -- but these do niggle

[bogs]

The old trick of creating an embossed look is outdated both in the sense that this is no longer a good or accepted look on mac/win and also in sense of how this is implemented.

Erm, you know you can simply uncheck the 'threeD' property, and loose the bold up there, right? hee hee.

Sorry, I work on neither of the two OS'es you mention, and most of the time I am on one, it is an older one pre mac 10 or win 7, so my input on anything related to those would be of minimal or no value.

I'll take your word on clicking a transparent button on your OS, this is what it looks like on 'nix -

The less said about the tab bar, the better...

Well, there I think we agree completely, I thought it was a funny way to implement it as well. Oh well, onward and outward

[stam]

Erm, you know you can simply uncheck the 'threeD' property, and loose the bold up there, right? hee hee.

erm... *cough*... live and learn i suppose

[glenn9]

While I didn't add a behavior anything (the IDE I use is WAY before that kind of stuff), I certainly don't see the problem with the controls as is. As an example along the lines of Craigs listed up there (an old fashion solution), I knocked this together (about 3 minutes).

PlaceholderSample.livecode.zip

If you wanted to have a single control to drag out of it, you could make a group of it and have just that.

Bogs, Craig,

Thanks for posting the stacks, this solution seems to work for me, and another learning point for me on a novel way of using layers...!

Kind regards,

Glenn

[bogs]

Glad you liked em, as I'm sure Craig is as well heh. I don't think, by the way, that mine was as thorough a solution as Trevor's was, although it could be improved upon fairly easily.

Making the assumption you *do* use a relatively recent version of Lc, I'd really suggest that you go over Trevor's tutorial again, maybe just tackling and taking apart small bits of it, until you understand what he is doing, and why.

If you don't get something, feel free to ask, anyone that knows will answer it here.

[TerryL]

One method for placeholder text in data entry fields:
1) Drag a scrolling field and resize height to show one line, width as desired. In properties inspector untick vertical scrollbar, and tick dontWrap, autoTab.
2) Place in field script:
--placeholder text in data entry flds: place in fld script, fld name = placeholder text
on openField --click in
set the textColor of me to empty --default color
end openField

on exitField --no text change
if text of me = the short name of me then set the textColor of me to "gray"
end exitField

on closeField --text change
if me = empty then
set the textColor of me to "gray"
put the short name of me into me
end if
end closeField

2b) As an alternative, put step 2 code in a button script. The data entry field can then be set to use the button's script. This sharing behavior can only be done with a button. It might be useful where the same large code is used by many objects, and makes it convenient to edit the code once for all objects. Ideal for data entry fields. In the field's properties inspector > advanced, choose the button scripted with step 2 code. OR in msg box:
set the behavior of fld 1 to the long id of btn 1 --btn's script used by another object with behavior property
(Note the behavior link is broken if the stack's name is changed.)

3) Copy and paste as many data entry fields needed. In the last field's script, include these two handlers to complete the tabKey/returnKey loop. If there are other non-data entry fields, re-number the data entry fields from 1 to...x in sequential series with properties inspector > position.
on returnInField --first placeholder field
select text of fld 1
end returnInField

on tabKey
returnInField
end tabKey

4) In properties inspector, name each entry field = placeholder text. Tab through each empty entry field to populate with placeholder text.

[jacque]

I attach a behavior script that is generalized for any field. I adjust it as needed (colors, for example,) but here is the skeleton outline. It assumes there is a custom property of the field named "cDefaultPrompt" that contains the placeholder text you want to show.

Code: Select all

constant kDisabledColor = "138,138,138" -- text, if bg is white

function textFldEmpty
  get the text of me
  if it = "" or it = the cDefaultPrompt of me then
    return true
  end if
  return false
end textFldEmpty

on openField
  if textFldEmpty() then
    put "" into me
    if the backcolor of me = "255,255,255" or the backcolor of me = "" then
      set the textcolor of me to empty -- default textcolor is black
    else
      set the textcolor of me to "255,255,255" -- for color bg
    end if 
  end if 
end openField

on closeField
  resetDefaultText
end closeField

on exitField
  resetDefaultText
end exitField

on resetDefaultText
  if textFldEmpty() then
    put the cDefaultPrompt of me into me
    if the backcolor of me = "255,255,255" or the backcolor of me = "" then
      set the textcolor of me to kDisabledColor
    else
      set the textcolor of me to "255,255,255" -- color bg
    end if 
  end if
end resetDefaultText

[golife]

I checked all solutions (sample stacks) and also the stack supplied in the lessons. They are all working well.

Even though Apple's user interface guidelines talk about placeholder text that simply disappears when the user entered data without any other label, other guidelines strongly recommend having a label nevertheless. When you use your mobile and enter information, usually you will still see a label despite a placeholder text that was there.

In Material Design it is recommended to use a placeholder text as a label and move the label with the same text to the top of the field once data is entered. It is even animated. I find this more logical and user friendly even though it eats up more space. But since all controls are placed in vertical order every control below moves down, it is accepted.

On Desktop I prefer good old-fashioned labels on the left or the top. The "placeholder text" here can be an actual default text. It is an anticipated text that the user would enter with a high probability, for example a current date is already entered, a certain number, a specific string that can be assumed. Otherwise, it is better to leave the filed empty.

If specifying more methods and properties of text fields (or rather text field groups), I am thinking of user properties and associated controls/objects for help text, for validation (indicating a field that requires the change of data through color/icons), for pick/value lists (user can pick data) while he types, ... but sometimes, less is more when trying to read the mind of the user. For tool tips I use my own fields since the built-int tooltip is too small and it does not allow any settings to behave and present itself as I want.

Very often also simple icons can replace the label. Most icons are known by now and there is no need to also show text. A tooltip for the icon is sufficient in such cases.

So, we have a group of objects that are needed to look and behave in a modern way, including graphics, icons, labels, help fields, pick lists, and also, not to forget, validation and formatting according to local expectations.

Then, as discussed, fields are also used for search (specific search fields), for the entry of passwords (with the option to show the password), and their behavior and design will change accordingly.