How to change the active element on the form.

[Сергей Александрович]

There is a desire to press the Enter key to go to the next information input field.
The option with event processing does not work.

procedure TfmPayTovarEd.edKOLAsyncKeyPress(Sender: TObject;
  EventParams: TStringList);
var
mValue  : String;
begin
  mValue := EventParams.Values['which'];
  if EventParams.Values['which'] = '13' then
  begin
    ActiveControl := edEDIZM;
    Self.Refresh;
  end;
end;


In Delphi, I constantly use the "ActiveControl := edEDIZM;" And for some reason it doesn't work in IW. Can you tell me how to do this?

[Rolphy Reyes]

There is a desire to press the Enter key to go to the next information input field.
The option with event processing does not work.

procedure TfmPayTovarEd.edKOLAsyncKeyPress(Sender: TObject;
  EventParams: TStringList);
var
mValue  : String;
begin
  mValue := EventParams.Values['which'];
  if EventParams.Values['which'] = '13' then
  begin
    ActiveControl := edEDIZM;
    Self.Refresh;
  end;
end;


In Delphi, I constantly use the "ActiveControl := edEDIZM;" And for some reason it doesn't work in IW. Can you tell me how to do this?

Hi.

I think you could use the SetFocus method of the control.

Like this:

procedure TfmPayTovarEd.edKOLAsyncKeyPress(Sender: TObject;
  EventParams: TStringList);
var
mValue  : String;
begin
  mValue := EventParams.Values['which'];
  if EventParams.Values['which'] = '13' then
  begin
    [b]edEDIZM.SetFocus;[/b]
  end;
end;

I personally would like to find a way that Intraweb Form can jump to control in the TabOrder sequence using the Enter Key.

[Сергей Александрович]

Thank you, it works!

[Сергей Александрович]

Thanks again for the hint...

And here is a solution to your desire:

procedure EnterNextOrder(Sender: TObject; EventParams: TStringList);
var
mTabOrder : Integer;
i : Integer;
begin
if EventParams.Values['which'] = '13' then
begin
mTabOrder := (Sender as TIWEdit).TabOrder + 1;
if mTabOrder > Self.ComponentCount then mTabOrder := 0;
for i := 0 to Self.ComponentCount-1 do
begin
if Self.Components[i].ClassName = 'TIWEdit' then
begin
if (Self.Components[i] as TIWEdit).TabOrder = mTabOrder then
begin
(Self.Components[i] as TIWEdit).SetFocus;
break;
end;
end;
end;
end;
end;

In the event handler, we call this procedure.

procedure TfmPayTovarEd.edPRICEAsyncKeyDown(Sender: TObject;
EventParams: TStringList);
begin
EnterNextOrder(Sender,EventParams);
end;

[Alexandre Machado]

The forum messed up my response... so I lost everything.

Let's try again:

I think that using ENTER as TAB is a bad idea. Very bad idea.

There are 2 problems here:

1) The de facto standard is:

TAB ->  move to the next focusable control
ENTER -> submit current form

I know that hundred of years ago   ENTER was used to do that. I've been asked thousands of times to implement this behavior in Windows/GUI applications over the years (and the web too). But this time is long gone. Not a single main stream web site/application will work like that.
Unless the end-users are limited to this single web application, they should be used to the TAB key by now.

I wish we could configure our browsers to map the ENTER key to TAB, so everybody would have it working as they wanted, but that's not possible.

2) Once browsers don't support the ENTER key, JavaScript code is required everywhere (in every single page or IFRAME in the page). This causes several problems: 

You need to decide at runtime if the control can or cannot receive keyboard focus. This is straightforward for controls like inputs (e.g. IWEdits) but not so simple for complex controls composed of several other elements like a Grid, accordion, page control, etc.

Also, it is very hard to get the same behavior using both the ENTER and the TAB (this is what any customer would expect, right?). Remember that the TAB key moves the focus out of your page as well (e.g. to the browser address bar). So, if one user decides to use the TAB, the application would behave in one way, and for another user who is using the ENTER key, the application would behave differently. 

That's why I insist on this every time: It is a very bad idea to implement this.

It is better to show your users that the web is not their old and beloved DOS 6.1. It's better to get used to it.

[Сергей Александрович]

Good afternoon! Yes, I also talked to my customers many times about using the TAB and Enter keys... And to this day, the question remains open. There are several reasons for this. And the fact that users are used to DOS keys is not the main reason...

Remember that the TAB key moves the focus out of your page as well (e.g. to the browser address bar) - This does not help the user in any way, but on the contrary hinders !

And in one of my applications, the key assignment is used in this way: To go to a new input field, the Enter key is used, and to close the Tab form. That is, "Everything is the opposite" ! But it is CONVENIENT for the user and not just convenient, but increases the speed of the operator. And very significantly! This is due to the fact that accounting data is entered, that is, figures. The input takes place on a small digital keyboard and pressing the Enter key is not only very familiar, but also more convenient and faster than pressing Tab to switch to another field... In addition, pressing Tab is implied with the left hand, and the employee is often busy with it... I absolutely agree with you that it is impossible to shift the function of the Tab key to Enter. But at the same time, specific tasks require the developer to use non-standard solutions to increase the speed of the operator. In these cases, I use this (old) key assignment. And I also use F4-change F5-add F9-print.... well, everything that was in the old , NortonCommander.

[Сергей Александрович]

I will continue my thought a little more. I am fundamentally against using a mouse where you can perform an operation on the keyboard. It is clear that many operations can be performed only with the mouse, ... but there are operations that can and should be performed on the keyboard. If everything is done only with the mouse. this increases the operator's fatigue, as a result, the speed of work slows down and the number of input errors increases. ... One example of such work is the work of a cashier for accepting payments. We took measurements and definitely found out that working with the mouse is much slower and more tedious than the same work on the same program, but using only the keyboard keys. Therefore, there is a strict instruction for cashiers to use the mouse only when the operation cannot be performed using the keyboard.
Although theoretically everything can be done using the keyboard, but in this case it is assumed that one key (or one key combination) must be pressed on the keyboard.

[DanBarclay]

It is better to show your users that the web is not their old and beloved DOS 6.1. It's better to get used to it.

A very sad truth <g>.

Years ago I even implemented "auto skip", the cursor would move to the next field when you typed the last character in a field.   Many (most) terminals could be programmed that way and "professional" keyboarders (aka keypunch operators) loved it and would scream if it wasn't there.

But, that would drive normal people nuts.  If you typed enough characters in a field it would move, if you didn't it wouldn't.  (as designed!)   Initially computers were operated by keypunch operators that were displaced from their old jobs... but that didn't last long.  You had to serve real people.

In the argument of pure keyboard vs mouse, I agree it's more efficient.   Or would be, it really isn't.  What's efficient is allowing people to use their muscle memory and reflexes rather than kicking that movement farther upstream to the brain.  When you make them do something "different" than they do for another window on the screen it is far more "work" for them.

It is far better to just submit to the centerline of "expected behavior", even if it isn't "the best", as you point out.   It's a moving target so we'd best be expecting to change again.  

That said, I still often use <ctrl><key> for cursor movements... worked in Wordstar for CP/M and they still live!

Dan

[Сергей Александрович]

Yes, I agree with what was said here and in no way deny the use of Tab. My programs work so that you can move both Tab and Enter (where necessary). I use the Enter transition only where it is justified for any reason... :-) . We have such a saying "There are no rules without exception!" ... Probably this also applies to the use of the Enter key... Thank you for the exchange of views.

[Сергей Александрович]

There are 2 questions about the virtual keyboard of a smartphone:
1 Where is the Tab key located ?
2 Can someone tell me if it is possible to control this keyboard? Well, for example, to enable the digital information input mode in advance (so that the user does not switch every time).