The obvious pitfall is productivity. It takes more time to type string delimiters and it's prone to typos and forgetting to do it at all.

I think the best answer is, simply, for a PEM editor to be more like Excel. Excel is smart enough to know that if you start typing

Fourscore and

in a cell, it's going to be a string. If you type

'1.00

then that's a string too, and Excel is smart enough to throw away the leading '.

I've just used Excel as one example of another way to handle data entry, but the more I think about it, Excel may be a good model to emulate. It would make a PEM editor consistent with Office, which can't be a bad thing. As for productivity, lots of people enter tons of data into Excel every working day and I bet MS has put a *lot* of effort into making sure data entry in Excel is as productive and error-free as possible.

This could potentially give the best of both worlds - terse data entry for programmers, but consistent display of property values.

>Al--
>
>For consistency then, you would also insist that you would create values for properties the same way ... using quotation marks for character strings?
>
>Jim
>
>
>>>>MyProp = "This is a string" -> appears as: This is a string
>>>>MyProp = 1.00 -> appears as: 1.00
>>>>MyProp = "1.00" -> appears as: ="1.00"
>>>>
>>>>The behaviour would need to change to:
>>>>
>>>>MyProp = "This is a string" -> appears as: "This is a string"
>>>>MyProp = 1.00 -> appears as: 1.00
>>>>MyProp = "1.00" -> appears as: "1.00"
>>>
>>>Well,
>>>
>>>1.
>>>? "This is a string"
>>>2.
>>>? 1.00
>>>3.
>>>? "1.00"
>>>
>>>In words: If you print a string you also don't print it's delimiters, those are only needed in source code and delimit the string itself from code.
>>
>>Hmm. The property sheet is used with classes/forms etc. which are source code. Only programmers look at the properties.
>>
>>>Therefore I think the property sheet is quite okay all in all. It's of course needed to make a difference of a numeric value 1.00 from a string containing what could also be a numeric value "1.00", which therefore is shown as ="1.00". It's making use of the normal behaviour of the sheet to evaluate anything starting with =, and so it's not to be confused by a string containing delimiters eg as in stringvar = ["string"], which really has the " in it's string value.
>>
>>I already understood why the stock VFP PEM editor currently works that way. But imagine, for a moment your background is anything other than VFP. Almost all strings display without delimiters, except for numeric strings which show up as ="1.00". This is a classic WTF. It's inconsistent. Good code minimizes WTFs.
>>
>>>If the sheet would show all strings with delimiters, then you'd need to assure the user can't delete a single one of them. Also you couldn't write a string in the property window, which has " in it.
>>
>>Well, that's like saying you can't write a string with " in it in code. That's why VFP supports 3 types of string delimiters, [], '' and "". Why couldn't they be used?
>>
>>>So I don't agree this your proposed way is more elegant. What I would prefer as elegant is coloring the values depending on their type, like you can color strings and expressions differntly in code, but for the sake of entering differnt things, it's good as it is, because you can enter =..., but you can't enter color, you would need to determine the type.
>>
>>Colour is interesting, but there are many property types and the differences between colours might be hard to discern for some people and/or some monitors.
>>
>>>If I think of dates alone, you'd either need a format independant on any country specific formatting or you'd need to define that format too.
>>
>>STRICTDATE would work fine.
>>
>>>I don't feel you thought about this thoroughly enough.
>>
>>Actually, in addition to the points above I've been letting this idea roll around in the back of my mind for a couple of days. The conclusion I've reached is actually pretty simple: property values in the property sheet should appear the same way they do in the debugger.
>>
>>I think that's where we disagree; you seem to think values should display the way they do as the result of a ? in the Command Window.