I would like to request, if possible, that there be only one element at time to hold focus. When using subforms, it is possible to have two elements holding focus; one in the main form and one in the subform.

Even though an element on the main form shows a focus box around it, the last element I was in within the subform also has focus, but it doesn't display a box around it.

The problem I am having with this is that On Element Entry programming for the subform is executing each time I advance the main record, even though I have clicked on the main form before advancing.

If I have put focus on an element in the main form, shouldn't focus be there ONLY, and not in any of the subform fields?

Quote:

What I mean by both having focus is, if I place focus in a subform element, the main form still has a dotted-line box around one element (the one that the cursor was in before I moved to the subform). And if I have the cursor in the main form, the subform On Element Entry programming executes when I advance to the next main record, indicating that focus must be in the subform as well at the same time.

BTW, the subform only leaves the dotted-line box around the element if the cursor was in the element as I moved to the main form. If it was just highlighted in gray, there is no indication that the subform element has any focus.

Quote:

Yes, if it is the programming for the first element in the subform. If it is for another element, then it only executes if I was in that other element last, just before moving back to the main form.

Quote:

The programming that is executing is in "[ElementName] :: On Element Entry".
There is no other programming. I made a copy of the original application, and removed all other code from both the main form and the subform. The only code resides in the first subform element and the third subform element. It is as follows:

Date1 :: On Element Entry
Amount = "1"

Notes :: On Element Entry
if Notes = "" then
     Notes = @userselect( @XListValues(@fn,"DBS Notes Form!Notes") )

Mark, if you need me to, I can send you a copy of the test application.

Quote:


The role of events and subforms has been the subject of a lot of debate around these parts. I've even met those that want it to work one way in one application and an entirely different way in another.

I am aiming for consistency (a difficult goal while some want us like their favorite Windows app and others want us *just like Q&A*). I want the subform to act as though not different from a parent form - so it never needs to know it isn't "just another form". This is especially trying in a table view form, in that each row has the same "data status" as an entire form - yet from a GUI perspective the entire thing is a single widget.

Quote:


No, I want the subform to act as though it is a parent. The cleanest, most supportable code, would never "know" that it is a subform - just that is a form. To an extent, we've managed this. The form view subforms not only share the same code with main forms, but are the same code as main forms. There are a handful of exceptions, where a form has to ask itself if it is "parented" - but only a few.

The table view subforms - on the other hand, are not so consistent. This is due to the relationship between a table and a record. Each row represents a record. That means that even very simple navigation in a table view subform can and must generate a large number of events - and communicate with the engine (on the server).

What is important to understand, though, is that this is not a case of dual focus. It is a case of "enter" events running or not.. When a main form is advanced, that qualifies as a "form enter" - little debate. That the focus goes to the appropriate LE when the form advances and causes an LE enter, again - is not widely debated. Because it is the same code as a main form, the subforms also get an enter event while Sesame recursively updates the main and its subs. If we then prevented the LE enter in the subform, we would be inconsistent and the main forms would act different;ly from the subform. This may be convenient, but it is also less predictable - in that same form at different "levels" acts differently depending on that level.

That is really the issue of debate, and has been hotly debated among the developers (and even within this developer). For example - if the main form view form runs form event on advance, then to be consistent, shouldn't each row of the table (as they are the data equal of a single form: one record) also run form enter?

I originally set up the system so that enter and exit event were driven entirely by true focus. But the Q&A community found this to be insufficient. For example - there are several ways to advance a form that don't involve entering the form - such as using the record counter or the command tree. That would allow a form to advance without the form enter event running. The beautiful simple rule - that an enter (real actual, user goes in a form/LE) causes an enter event - did not please the Q&A event advocates. On the other hand, that kind of simplicity has a great deal of appeal in the clarity and predictability of its statement.

But, again for example, using a strict focus model - would also cause the form enter to run if you moused to another application and back into Sesame - on the same form.

So I ended up asking myself a lot of questions: what should happen if the user moves from the command tree to a form they have already been on? What happens if they move from a main form to a subform on that main form? What happens if they move back to the main form from the subform? What happens if they advance the main form, and thereby advance the sub-sub-sub-form? Etc.. Then I looked at the events coming in from the actual GUI, the windows and widgets, and tried to reconcile the several hundred possible events with the several thousand possible navigational cases.

I am not trying to offer excuses, and we will do what we can to remedy any anomalies found - but, I would recommend that whenever programming in any GUI environment (not just Sesame), that you adopt the practice of "state programming". That means you check and maintain the state of your data - as opposed to reacting to the user or events.

The reasoning behind this is obvious if you have an especially "twitchy" user, who, without regard, clicks on fields repetitively and unpredicatbly with the mouse, or taps on PgUp / PgDn nervously. Or, worse, presses F9 / F10 over and over again - for fun.

In any GUI environment, the user has a random access device - the mouse. Even in Q&A, you can use a "goto" and attempt to lock the user into a field - but the mouse will always let them out. And the more extreme the attempt to control the user, the further they will go to extremes to do what they think they want to do, even if it is not the right thing to do. The more extreme the actions of the user, the more likely they are to make extreme mistakes. One of the most common examples of this is the "strict phone number" template. If a designer deploys the usual ten digit template (###) ###-####, it is only a matter of time before extensions and international numbers start showing up in other fields.

In "state programming" the designer attempts to react to changes in the data, as opposed to the actions of the user. Lets say for example that you want to increment a value when the user enters a particular LE. But, you know that the user may and will enter that field repetively. If you simply put the increment in the LE enter event, the number will increment without control. But if you protect that increment with a global static variable that indicates that the number has been incremented already (its "state" transitions from unincremented to incremented), then no harm done. You can also then "protect" that LE by saving that number from edits after it has been incremented. That state flag, typically gets cleared when the number is used in calculation. Again, typically, the number, nor the flag are retained.

In state programming the form or forms and each LE (the data as a whole) maintains its "state". It then can transition from any single state to another state - but only after a minimum set of conditions have been met in the data. The designer can make clear the "state" of the data to the user through visual cueing (color, label, position, size, messages, etc...). Each state then enables or allows particular actions to take place, which - in turn, allow the next change of state.

I'm not sure if I've explained this well and I guess I should apologise for blathering on, but it is actually always much simpler than it sounds when explained, and is one of those things that is easier done than said.

Actually unrelated. The engine (server) side does all the locking and unlocking. It has no knowlege of the user interface or focus. It may be that the server is sending the "lock" message and any form that has that record is locking. The table may have failed to send the engine the "unlock" when it lost focus.

The only condition that would be "dual focus" is if you type and the character typed appears simultaneously in two places.

It doesn't matter if you are networked or not. There is still always a client and a server. Networking just determines how they talk to each other. When standalone, the client talks to a "pipe", the server reads from that pipe and responds to the client through a similar pipe. When client/server, the client talks to a pipe. A "server proxy" reads that pipe and tells the network (a "socket"). A "client proxy" reads that socket and talks to a pipe. The server then reads that pipe.

So a message going from the client to the server follows these paths:

Standalone:
client->pipe->server

Client/Server:
client->pipe->server_proxy->||socket||->client_proxy->pipe->server

That way the client, nor the server, have to act any differently because they are standalone, or client/server. They always "think" they are talking to each other through the pipe.

Quote:


Your above quote gives me impression that something is not right .... something failed to send engine "Unlock" ... 

Is this normal or aberrant?

Quote:


I believe that is the case. If you need me to send you the application, I will do that for you to see what I am talking about.

Quote:


Carl,
Is the on form exit event  sending "current LE" status to an element that has absolutely no programming in it in  the subform or parent?


Quote:


I will second your comments on this!