Matthew,


<< It needs to just know that the property type is open or closed, and retain that across components of different types without them. I'd use a stringlist and keep the properties open in it. If closed, remove the item. >>

Yeah, I wish it were that simple, but the Object Inspector functionality is pretty complex because of its integration with what's going on in the form designer.  I'll have to analyze it all to see what's involved.

<< This was a new project, with the forms saved as I finished them. >>

Hmm, can't reproduce this one, so if you come across it again, please try to note the current steps involved and I'll be happy to fix any issue involved.

<< Not actually tried that, but it is two identical handlers in the same procedure. >>

Ahhh, now I get it.  This is now fixed.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> << The values in LocalStorage can be NULL, and I used to test against
> nil to check if it was valid. This appears to not be allowed any
> more. Options? >>
>
> Use the Exists method, it performs the proper checks for you.  The
> compiler allowing nil comparisons to strings was always a little
> flaky in conceptual terms (strings are never nil in JS), so I got rid
> of it.

There is no Exists method for local storage, it appears. Exists()
appears to be a cookie tester, and localstorage (the standard
javascript capability) doesn't have a way to test if a value exists.
Thus the code will read a value, but if isn't there.

  szJSON := Window.LocalStorage.GetItem('my_options');
  if ISVALID(szJSON) then // how to test this?    

--

Matthew Jones

Matthew Jones wrote:

> There is no Exists method for local storage, it appears

WRONG! (I love having the source to the framework!)

The key is I have it as Window.LocalStorage but EWB2 surfaces it as a
plain LocalStorage, which does have an Exists function. Super...

--

Matthew Jones

Matthew Jones wrote:

> I would like to set the placeholder text for edit boxes
> ("enter email address" or something). The propery exists for input
> elements. Isn't an edit box an input element?

In EWB1 I hacked the library code to make Display public, and used code
like this:

   editFirstName.Display.SetAttribute('placeholder','First name');

I'd really like to know how to make this work in EWB2...

--

Matthew Jones

Matthew,

<< I'd really like to know how to make this work in EWB2... >>

You can only get at the protected TInputElement.PlaceHolder property from a TInputControl descendant class.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> << I'd really like to know how to make this work in EWB2... >>
>
> You can only get at the protected TInputElement.PlaceHolder property
> from a TInputControl descendant class.

I don't think I understand enough to know what that means! Maybe I'm
unusual but I really like the placeholder ability, and want it in my
applications to hint to people.

--

Matthew Jones

Matthew,

<< I don't think I understand enough to know what that means! >>

You'll need a TInputControl descendant class in order to get at the underlying TInputElement element that contains the Placeholder property.

<< Maybe I'm unusual but I really like the placeholder ability, and want it in my applications to hint to people. >>

You're not unusual, but there are limitations/downsides to using the placeholder attribute, which is why it's a) there in the underlying UI element class b) not surfaced in EWB 2:

http://caniuse.com/#feat=input-placeholder

(look at the Known Issues tab).   And, IE9 (our base IE browser) does not support it, so using it/implying that we support it would generate support requests.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> http://caniuse.com/#feat=input-placeholder
>
> (look at the Known Issues tab).

Okay, so all you have to do is exclude its use in IE9. And IE10. And
IE11. Basically, don't support Placeholder under IE. I was going to say
that was a joke, but with only 8% of browser use, and none on mobile
where placeholder is most effective, I think it is quite realistic...

--

Matthew Jones

Matthew,

<< Okay, so all you have to do is exclude its use in IE9. And IE10. And IE11. Basically, don't support Placeholder under IE. I was going to say that was a joke, but with only 8% of browser use, and none on mobile where placeholder is most effective, I think it is quite realistic... >>

The problem is going down this road will start to result in more and more notes everywhere about which versions of which browsers support which features.  This a) defeats the whole purpose of EWB, and b) is a documentation nightmare.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> The problem is going down this road will start to result in more and
> more notes everywhere about which versions of which browsers support
> which features.  This a) defeats the whole purpose of EWB, and b) is
> a documentation nightmare.

I see where you are coming from, but it also means lowest common
denominator, and is cutting a feature for 94% of the browsers for the
problems of 6%. It is of course your decision, but it would also be
nice for advanced users who "must have" this feature to be able to add
it. In EWB1 I was able to make the Display property public and set the
attribute myself.

I was thinking what a clever game Microsoft are playing with the new
Edge browser. It is "new" and has limits because they haven't added all
the features yet, like extensions. It is also now the default in
Windows 10 I think. Imagine how much outcry there would have been if
they had just cut a load of things from IE - but they have effectively
done exactly this to suit their commercial purposes, only they just
don't have to ever implement things they don't want now. Anyway, that's
a side thought - does Edge support these things better? IE is going to
get smaller over time. Me, I vote for a conditional and a bit of
documentation. 8-)


--

Matthew Jones