Tim,

I took a little time out to upgrade to 1.02B1 today.

Previously (1.01B5) I had modified WebCtrls to make the Base and Display properties of TControl public. The main reason for this was to make a call to the SetAttribute method of descendant TEdits and TMemos in order to hack in support for placeholders.

To my surprise, however, my project compiled just fine without these changes, even though the properties remain protected in the new framework.

In short, it seems as though the compiler is allowing access to protected properties. You can repeat this by dropping a TEdit on a form in a new project then accessing its protected Display property from code.

Cheers
Mark

>>To my surprise, however, my project compiled just fine without these changes, even though the properties remain >>protected in the new framework.

The plot thickens!

Reverted to 1.01B5, commented out my code that makes the properties public, and they can still be seen.

So either (a) I am now too old for this or (b) this has been a compiler issue since 1.01B5 and maybe earlier

Please confirm ..............

If you can give a line to stick in a project, I will try to give it a go. But I
note that EWB seems to cache files, even if closed and changed externally, so be
sure that you are really using the changed files. (One thing I sometimes do is add
an error, and if it is being read, it will fail to compile.)

/Matthew Jones/

>>If you can give a line to stick in a project, I will try to give it a go.

Yup. No problem. Try dropping a TEdit onto a form then adding this in code:

Edit1.Display.SetAttribute('placeholder','Enter some text in here');

This will access the Display property and then its SetAttributeMethod, in this particular instance in order to create a placeholder for the TEdit. For me all compiles well, even though the Display property is defined as Protected (via TControl).

>>But I note that EWB seems to cache files, even if closed and changed externally, so be
>>sure that you are really using the changed files.

Yup. Tried that one. Definitely the right framework source.

Cheers
Mark

Compiles here too. Hmm, in the latest version. And it is a "protected" property.
Looks like you are on a winner for the moment then. 8-)

/Matthew Jones/

Mark,

<< Previously (1.01B5) I had modified WebCtrls to make the Base and Display
properties of TControl public. The main reason for this was to make a call
to the SetAttribute method of descendant TEdits and TMemos in order to hack
in support for placeholders.

To my surprise, however, my project compiled just fine without these
changes, even though the properties remain protected in the new framework.
>>

I'll check it out - there may be something funky going on due to the fact
that the code is in a TForm-descendant implementation, and TForm descends
from TControl.  The compiler is probably not being strict enough in how it
allows access, because of this (duh .

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

> Edit1.Display.SetAttribute('placeholder','Enter some text in here');
>
> This will access the Display property and then its
> SetAttributeMethod, in this particular instance in order to create
> a placeholder for the TEdit. For me all compiles well, even though
> the Display property is defined as Protected (via TControl).

I note that this has stopped working in the latest version. I have manually edited
the framework to make the Display property public. Some proper support for adding
SetAttribute calls to the display would be excellent, so that we may customise it
for specific needs.

I'll just post these as useful things for iOS/EWB users:
   // turn off autocompllete
   editTarget.Display.SetAttribute('autocomplete','off');

   // set a numeric keyboard
   editTarget.Display.SetAttribute('pattern','\d*');
   
   // set an alternative keyboard (only one of the second values!)
   editTarget.Display.SetAttribute('type','tel, email, or url');


/Matthew Jones/

Matthew,

<< I note that this has stopped working in the latest version. I have
manually edited the framework to make the Display property public. Some
proper support for adding SetAttribute calls to the display would be
excellent, so that we may customise it for specific needs.  >>

The reason that it's protected is because it's *very* easy to screw
something up with EWB's framework by directly manipulating the HTML
elements.  EWB mirrors many element attributes in code for performance
reasons, and modifying these attributes outside of EWB's control can cause
weird behaviors that a) won't be readily apparent and b) will most likely
increase our support requirements if someone doesn't know what they're
affecting with the changes.  Even the most seemingly innocuous stuff can
cause problems (changing element tab indexes, for example).

Having said that, if you want to make that stuff public and directly
manipulate it, I certainly can't stop you.

Tim Young
Elevate Software
www.elevatesoft.com

I can quite understand that. I might suggest you add an undocumented
"UnsafeAddAttribute" function that does this for those who must have it. Or
document it with strong warnings. Hmm, I might also suggest that this be controlled
by an "EnableUnsafeAttributes" function, so that we must call that too. That would
make it an easy thing to test if we'd broken something - don't call that, nothing
could be broken, code works, must be something we did.

/Matthew Jones/

Matthew,

<< I can quite understand that. I might suggest you add an undocumented
"UnsafeAddAttribute" function that does this for those who must have it. Or
document it with strong warnings. Hmm, I might also suggest that this be
controlled by an "EnableUnsafeAttributes" function, so that we must call
that too. That would make it an easy thing to test if we'd broken
something - don't call that, nothing could be broken, code works, must be
something we did.  >>

Hmmm, it's a good idea but I'll have to think about this some more.  It
might be easier to do what I planned, I.e. just add the relevant methods for
the various attributes that are needed.  The HTML standard doesn't change
that often, so I'm not super-concerned about getting too far behind.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com