OK maybe I did something wrong when I upgraded to 1.0.4 or maybe the moon is out of balance or the stars are falling or I'm just getting too stupid to be allowed infront of a computer anymore, but I seem to be unable to overwrite fields anymore.

in 1.0.3 I couldn't overwrite fields but could in 1.0 now in 1.0.4 if I try typing in a new value I need to type the X.0 then it gives me a message that it needs to change the x.0.y to x.0...

I guess I'm just trying to figure out if there is now something I need to turn on for overwriting or should I just uninstall Sesame and reinstall it back to 1.0  ??

well I myself am not trying to overwrite anything   
but our data entryperson needs to add and remove quantities of inventory as they are used up.  to do this in Q&A she just wrote right over the previous quantity, but in Sesame when she does this it does not autoerase the previous entry nor does it overwrite it...

Since she does not look at this and just types what she needs to our inventory has become way off in the last month, last month a particular item we stocked had 5 on hand, we sold them and ordered 4 more so the quantity suddenly showed 45, now it shows 13845 on hand.

Of course you would expect somebody to pay attention and notice when the numbers don't seem to match, but I was just doing the monthly checkup on the inventory costs, and I noticed that we had 13845 of an item worth $356.00 a piece...

I love the Sesame programming ease but I just can't seem to make the simple things like deleting the previous value for a field work... and can not get our data entryperson to stop and delete these numbers before entering the new ones...  I'm just trying to save myself a couple of the hundred headaches I already have   

You are right Kerinst, Sesame used to highlight the LE on entry if you used the Enter key (I think) to move from field to field. Effectively this allowed you to over-write the LE's contents simply by typing in the field. This was removed in the latest version because some people found it too easy to overwrite their LEs.

I take it that you are a vote in favor of its restoration?

Hi

Overwriting is standard in Microsoft Excel. As soon as you enter in a cell and start to type, the entire cell content disappear and is replaced by what you are typing. The cell is not even highlighted. Maybe the best solution would be to highlight on field entry with the possibility of: 1. type to erase and overwrite. 2. use right arrow to position the cursor at the end of the data and therefore allow "appending" to the data already there. 3. use left arrow to position the cursor to the left of the data therefore allow "prepending" to the data already there.

My 2 cents

Regards

Serge

If it were made an option, I would prefer it be an end user option rather than a designer option. As we have seen, it isn't the sort of thing that data entry would want coming and going on a LE level - but instead controlled by behavior on the part of data entry. That way, when someone wants to overwrite an LE (intentionally) there is always an action they can take to do so - that is easier than highlighting the LE contents by hand. Possible one of the LE navigation keys should auto-highlight.

Currently ctrl-K will delete the current line in a text field. And, of course, shift-End will highlight the contents. But neither is terrible efficient from a data entry standpoint. I am considering a keystroke that turns on highlight on entering a LE as a "mode" - such as ctrl-Insert or alt-Insert, or such like. It would need a mode indicator somewhere.

I was wrong, btw, it appears that the only navigation method that auto-highlights in any of the released versions, is movement between records, not movement between LEs. That may account for why it never appears in the change log. There are beta versions that highlight when moving using the Enter key, but it looks like this changed before the initial release. If someone out there has found a way in any of the released (non-beta) versions - please reply here!

We might. That was my original idea, but Erika pointed out that we might also want to implement true overwrite/insert functions and attach them to the insert key. Personally, I dislike overwrite mode. I much prefer highlight and replace.

The trend in GUIs is to replace overwrite mode with highlight and replace. With a few notable exceptions, most programs no longer support the toggle.

The "natural" behavior of the text widgets (the LEs) is to highlight the contents on entry. Because of the objections of some users (apparently during beta testing), we are preventing that natural behavior in all but a few cases. I think we have caught every case where focus actually does change. But when you move from form to form - the focus does not actually change from one LE to another. To force the the form to run SBasic on form to form navigation, we send the form a focus change event on the currently focused LE. But since it is not really changing focus - the code that "dehighlights" the LE's contents does not run.

Its on my "to do" list.

Thats why it on my "to do" list - and also why it is still on my "to do" list..

Consistency is an interesting concept in ease-of-use studies. On one hand it can make a program easier to use by true beginners through moderately experienced users. On the other, it causes the rule of thirds - in that any one third will dislike what you do consistently, and because you do it consistently they will dislike it intensely. One third, or so, will be indifferent. And one third will like it very much. You can, of course, shift these numbers around depending on context. But it is generally true.

As users grow in experience, consistency becomes a problem to overcome. More and more they want context sensitivity, flexibility, and begin to enjoy and take advantage of the qualifications that make a program rich. The power users begin to demand modes, exceptions, and qualified situations - all of which are the bane of consistency. The concept of consistency gives way to the concept of predictability. In other words, the users do not expect the program to act the same way in all circumstances, so much as they expect the program to act in a predictable way under increasingly complex circumstances.

Even further down the road, predictability begins to pale. Here we get into the extremes of ease-of-use, wherein a program does not act predictably, but rather anticipates surprisingly well. This is, of course, the "holy grail" of ease-of-use, where a program supercedes the expectations of the user. It is inherently dangerous to attempt this, in that the programmer must make "guesses" and assumptions about the user's intent and make the program act accordingly, without narrowing flexibility, or causing the program to become so unpredictable and inconsistent that it cannot operate if the "guess" in incorrect. Its a very delicate balance.

To better illustrate what I am describing, lets use as an example the current thread of this discussion: highlight upon entering an LE.

The most consistent thing to do would be to always highlight or alway not highlight, no matter what the circumstance. That is very easy for the beginner in that it is very predictable. But as we have seen in this thread, it is not always the right thing to do.

The next step is to make it somewhat inconsistent, by either providing a mode toggle, or commands in SBasic. If it is commands in SBasic that would cause it to become inconsistent across LEs - some would highlight for the end user and others would not, depending on whether the database designer predicted it would be useful for the data entry person. If it is a mode, there would need to be a mode indicator on the screen. The data entry person would have to be aware of that indicator. In either case, it is more flexible and powerful (which a kind of ease-of-use), but less consistent.

A step futher (and probably a step too far) would be to make the program so that it predicts the intent of the user without any particular modal action on their part. Does the user always highlight this LE? Do they never highlight this LE? Do they tend to highlight it? etc...

The highlight itself actually attempts a bit of prediction. In any program that does text highlighting, notice that if you highlight text and then press an alphanumeric key - the program (meaning the programmer) assumes that you intend to delete the highlighted portion of text and replace it with what you are currently typing. But if you hit a navigation key, like the cursor arrows, they assume that you only intend to insert text - not replace. For most of us, in most situations, they are mostly right - that would be a pretty good, though not perfect, indicator of intent. But, when working in the arena of high speed data entry, wherein the user's eyes rarely leave the source material they entering, are these assumptions still safe?

Modern program user interface design is full of examples like this, wherein the program must be a balance between consistency and flexibility, power and simplicity. There is a venerable (first appeared in the mid-1960s) text editor called Emacs. It is one of the most powerful programs ever built and also one of the most flexible. Right out of the box, it is actually pretty easy to use. The commands are simple and straight forward. But the program is completely configurable. Every command can be reassigned (and often is), and / or contained in a new macro, invoked by user assigned keystrokes. That means that you can apply for a job claiming to know Emacs backwards and forwards. But when you sit down to that Emacs installation, you cannot possibly predict with any certainty how that particular installation of Emacs will behave.