Hi Thierry,

I hope all is going well for you.
I am about to investigate why control focus behaviour in web mode is not the same as it is in lan mode and I have some initial questions so I know what to expect :

1. is control.SetFocus supported in web mode? (I think yes)
2. is control.Valid returning 0 or .F. supported in web mode, i.e. the focus should not change in the browser ?

Thanks
Paul

Paul,

Yes to both questions

Hi,

I am investigating some controls focus problems and here is an example of the tab order not being obeyed :

In this example the focus should go from textbox1 to textbox2 as that is the tab order in VFP and that is how it works in desktop mode. But in web mode it instead goes from 1 to 3 (the button bottom-right, which actually has the highest tab order, 11 !).

The problem seems to be related to the fact the textbox2 is inside a container, which I have drawn in red; the container is a separate class from a class library.
In desktop mode textbox2 has TabIndex = 1 inside the container and the container itself has TabIndex = 2 on the form; this works in desktop mode but not in web.

In the HTML, textbox1 has TabIndex = 1, the container does not have a TabIndex and textbox2 has TabIndex = 3 - this would seem to be ok, but the focus always goes from textbox1 to the highest TabIndex (the button bottom right).
As an experiment I placed a textbox outside of the container with TabIndex = 2 and this works fine in web mode, focus goes from 1 to 2.
I have tested with Firefox and Chrome.

So, it seems that the container upsets the tab order?

Paul

Hi Paul,

FoxInCloud (HTMLtabIndex*() in awHTML.prg) collects the .tabIndex across containers recursively and, while the tabindex attribute is 'flat' in HTML (ignoring containership), FoxInCloud clones the VFP behaviour by adjusting the generated HTML .tabIndex with respect to where controls are contained.

eg. http://foxincloud.com/tutotest/bs/Modal.tuto (MODIFY FORM home(1) + "tools\ab\aw\samples\fic\fictuto\progs\forms\modal.scx") works fine with several containers.

To find the reason why it does not behave OK in your case, please share a screenshot of your VFP form with 'view > tab order > assign interactively', and the corresponding generated HTML code.

Thanks in advance,

Hi,

I have identified two problems so far.

A form has textbox1 and textbox2 (TabOrder 1 and 2).
textbox2 starts with Visible = .F.
"classic mode" rendering, not BS

Scenario 1

1. textbox1.valid
2. this sets textbox2.Visible = .T. and exits the control textbox1
3. focus should be set to textbox2, but is set to the next visible control after this instead
   Cause : I assume textbox2 visible = .T. is being set in the browser during the same update as the focus is being set to it and because visible is not .t. prior to the update then the focus moves to another control instead. Ok, I have now changed the form to not do fancy things with visible and set Enabled instead. (hmm, even with Enabled = .F. I can still enter the control in the browser...still testing this...)

Scenario 2

1. textbox2.valid
2. opens a dialog form for input, maybe just a messagebox with Ok button (no callback) or maybe another form with a callback
3. textbox2.valid this returns .F. (do not leave the control)
4. focus should be set to textbox2, but is set to the next visible control after this instead
   Cause : I assume showing another form, with or without a callback, upsets the tab ordering when the original form becomes active again once the dialog form is closed.
   I could maybe put some code after each possible form or callback and set the focus back to textbox2, but this would be difficult as the dialog forms are generic and do not know anything about the original form.
   Can you think of an alternative approach to this problem?

Thanks
Paul

Scenario 1

You could use .readOnly instead.

Scenario 2

When opening a sub-form, FoxinCloud.js stores a reference to the 'originating' control (the control where source event occurred) in the sub-form; when closing the sub-form, if focuses back on this control. If you open a second sub-form and release the first, we may loose the reference to the 'originating' control (I need to double check).

Not sure about the exact form sequence in your case; if you open a single sub-form, of whatever type (message box or regular form, modal or not), focus should return to the 'originating' control.

To get a better grasp on your scenario, you can set LogRepData = On in xxxTest.ini, and share the AJAX request (in wwRequestLog.reqData) and responses (in wwRequestLog.repData) for the various events in the scenario.

Hi,

I tried .Enabled and found it had the same problem as .Visible - the focus shifted to the next control that was visible and enabled right from the start.
I tried .ReadOnly as you suggested - yay, that works. I see FiC also sets the BackColor on the control to make it look "disabled" - nice.

So, for the second scenario :

1. control1.valid
2. open one form, or sometimes two forms one after the other with a callback to the base form in between (just one form in the example request I will email)
3. control1.valid returns .F.
4. focus shifts to the next control, control2, instead of staying in control1
   
   (red rectangle is a container that those controls are inside, may or may not matter...)
   All forms involved, including the base form, are "sub forms".

I don't know exactly what diagnostic details you want to see, so I have emailed you separately the wwrequestlog. Start from record 4517 - valid -> show a form -> control2 gets the focus -- the last 5 records in the table. The last 20 or so records are me testing the scenario several times.

Thanks
Paul

I have emailed you separately the wwrequestlog. Start from record 4517 - valid -> show a form -> control2 gets the focus -- the last 5 records in the table.

stockcontrolcheckarea-barcodecontainer-barcode.valid() opens a sub-form of class mbfforegroundform with title Operations.

As stockcontrolcheckarea.barcodecontainer.barcode.valid() returns .F., the response ends with a script containing jQuery('#stockcontrolcheckarea-barcodecontainer-barcode').focus() so that it remains focused (not very useful in this case as focus should be transferred to a control of the sub-form).

As I explained earlier, when stockcontrolcheckarea-barcodecontainer-barcode.valid() opens the sub-form of class mbfforegroundform, the JavaScript object corresponding to the sub-form hold a reference to the element of ID stockcontrolcheckarea-barcodecontainer-barcode so that it can be focused back when sub-form is closed.

No idea why focusing back to stockcontrolcheckarea-barcodecontainer-barcode does not work in this case, a remote session would probably help understand.

Hmm, are you referring to the oSrce property of a js object belonging to the mbfforegroundform div?

If so, I see it points to the **next ** control in the tab order on the source form, stockcontrolcheckarea-passallbutton (what I called control2 in my simplified example). Not the control that called the form and returned .F.

So, if I am correct so far, what can I look at next to see why the wrong control has been passed to the sub-form?

Thanks

FoxInCloud.RequestSend() sets this.oControl to the element where event has occurred (.blur() in this case) just before sending the AJAX request, and sets this.lRequest = true.

If you use the TAB key to get out of #stockcontrolcheckarea-barcodecontainer-barcode, focus moves to #stockcontrolcheckarea-passallbutton and, as this element has the .focus() event implemented, it fires. However, as this.lRequest, this .focus() event gets stacked into this.aReqPend[] for later execution (after .blur() Ajax request completes), BEFORE this.oControl is set: this.oControl remains set on #stockcontrolcheckarea-barcodecontainer-barcode.

So, when .blur() Ajax request completes and opens the mbfforegroundform form, this.oControl should, in theory, still be set to #stockcontrolcheckarea-barcodecontainer-barcode.

Without a logical explanation why this.oControl is set on #stockcontrolcheckarea-passallbutton, we need to debug; here is what can be done:

• in FoxInCloud.DOMEvent, set a conditional break point on line 96 with eventType==='blur' and eventSrce.id==='stockcontrolcheckarea-barcodecontainer-barcode'
• set a watch expression on FoxInCloud.oControl
• set a breakpoint in FoxInCloud.AjaxSuccess()
• As you can't set a breakpoint on property changes, you need to step through the methods until you see FoxInCloud.oControl change, either before sending the AJAX request (which I strongly doubt as explained earlier), or during the Ajax response processing.

You could also set inputAlwaysBlurOnReturn: true in xxx.js and try to exit #stockcontrolcheckarea-barcodecontainer-barcode using the Enter key instead of the TAB key and see if focus gets back on #stockcontrolcheckarea-barcodecontainer-barcode after closing the mbfforegroundform form.

I've tried very had to make it as simple as possible, however FoxInCloud.js is a complex beast…