custom touch functions

[John Robin Dove]

Hi Clifton,
Thanks very much for your efforts. I should have told you that I have moved on from the version I sent you which used an excessively complicated set of objects as you rightly point out. Your version may not trigger password saving in Firefox but it certainly does in Chrome. I opened it once and entered some letters in the password field. No password saving was triggered. I then navigated elsewhwere and then back to this page on the forum and immediately Chrome asked if the new password should be saved as you can see in the screenshot. New password for what? I suspect it would have changed my password for the forum if I had let it. Furthermore the suggested password of two letters was not the last one I entered. This is exactly what it does in my program. Nothing happens while the password is entered or even immediately after that. However password saving is always triggered when the user navigates to a different part of the program in an iframe on the main page (the main page stays open all the time).

So the only solution I have come up with is to create some kind of 'fake password field' which does the job but never triggers password saving. The fact that the annoying prompt dropdown showed up was, in my opinion, also down to the fact that in the past the 'response' field had been a bona fide password input like yours and somewhere in Chrome's memory the name bloggs was associated with it. Now it's a textarea and if a different name is used there is no problem. I'll send you an example of my latest "fake password field' system this morning if I have time.

Another huge problem I have is that, on my Android tablet, as soon as a video or audio file is played on the Powerpac media player, the virtual keyboard pops up. Why, I wonder? I have not found ways to prevent this happening but have found that showing, focusing and then hiding a textarea will make it go away. Not ideal but maybe better than nothing. I don't like tablets. I can never make them do what they're supposed to do with my fingers. In fact I hate the things! However everyone else seems to love them so I must find ways to make the program compatible with them.

[Clifton]

The keyboard pops up because textarea is being focused. This is a default behavior with tablets. To keep this from happening on tablets, you have to restrain your application from allowing focus to take place on the textarea unless the user clicks, or touches, it.

[John Robin Dove]

OK but what textarea? I make sure there are no textareas visible before starting the media player.

Re password problem. I have made an example of my latest technique to avoid using a regular password input. Sorry to have messed up some of your elegant programming. Your programming is undoubtedly much more concise than mine. Regarding the requestGroup object, I don't think I made it clear what it's for. It is the equivalent of the msgBox window in VS or the request/ask system in TB so it has to be moveable, the text field must adapt its height to the size of the text displayed and the buttons, of which there are three in the final version, must adapt their width to their caption and arrange themselves accordingly. This is why I use fields instead of buttons.

In the example here https://www.mediacours.com/tb_examples/requestPwd.zip, do you think the alternative password system is adequate and could you suggest any improvements please? I have another system for desktop use which relies on keypress. I have not included it. In the desktop version the letters typed are never visible. In requestPwd they are visible for a fraction of a second but this is normal behavior on a tablet anyway. I have not been able to use keypress with a touchscreen.

[Clifton]

You really should not use keypress events because they are not widely supported across devices. Use keyup for keypress (works everywhere)—keydown works like keypress as it will repeatedly fire as long as the key is pressed. If you use mousedown, mouseup, etc. along with the PowerPac event system function pgAddEvent() these will be converted to touch-related actions when a touch device/event is detected.

pgAddEvent( [obj], [event], [function] ): (undocumented in PowerPac API)

• [obj] = DOM object to add the event listener to. Can also be window, or body if those need listeners.
• [event] = string as event type. (e.g., "mousedown", "mouseup", "keyup", "keydown", "click", "mousemove", etc.)
• [function] = function object. It is preferred to make the function a property of [obj] if you need to remove it using pgRemoveEvent() at some point in your application. Otherwise, this can be an anonymouse function (not tied to any object).

I've not had much trouble supporting touch devices as long as I use the events described above. My NEW LearnToType Today program is an example. Although, it is not very practical to use a learn to type program with a touch device as it kind of defeats the purpose.

I'll see if I get time to look at your example.

[John Robin Dove]

Keyup and keydown don't tell you what the user has written. You can of course retrieve this afterwards as in the example I have just sent but if you use keypress like this:

Code: Select all

<function name="myKeyPress" event="keypress" params="e">
  <![CDATA[
    if (sharedActions.isPwd == true)
    {
      if (sharedActions.mouse == 1) // mouse is being used
      {
      e.preventDefault();
        if (e.keyCode == 13)
        {
        sharedActions.getResult();
        }
        else
        { 
        sharedActions.holdCode = sharedActions.holdCode + String.fromCharCode(e.keyCode); //This is exactly what the user would have typed into the field including é ç ñ etc
        var charNo = sharedActions.holdCode.length;
        sharedActions.showDots(charNo);
        }
      }
    }
  ]]>
  </function>

the letters are never visible. This works well on a pc but I don't know about a Mac. If you think it's too risky I can always use the keydown system I reserve for touchscreen use at the moment. Do I need to use pgAddEvent then? I had supposed from your earlier reply that this was taken care of by the Powerpac.

Re media player, you did not explain what textarea your were referring to. Sorry to mix subjects but at the moment the unwanted appearance of the virtual keyboard on the tablet seems to me to be the biggest obstacle I must overcome if this program is ever to be finished. Thanks for your time.
John

[Clifton]

pgAddEvent() is a PowerPac function which effectively replaces [obj].addEventListener(). The purpose behind was to be backward compatible to older browsers and more recently to handle touch events on devices that support them. Using pgAddEvent() makes using another js API unnecessary.

Regarding keyDown, keyUp, etc. you can always find out what was typed by using this code: (cannot set useTB="true" in this case as ToolBook does not have such flexible support)

//Handles every situation, but you need to check which event is being sent! (use e.type to get the event)
<function name="myKeyboard" event="keydown,keyup,keypress" params="e">
    <![CDATA[
        /*  CLIFTON:  Handle all keyboard events ... ***/
        var keyCode = e.keyCode || e.which, //ASCII code
            key = e['char'] || e.key, //Actual key pressed
            shift = e.shiftKey, //Get state of shift key when event occurs
            ctrl = e.ctrlKey, //Get state of control (Ctrl) key when event occurs

        ... (do some stuff based on the vars set from the event)
    ]]>
</function>

[John Robin Dove]

Re e.keyCode and e.which. Sorry but I disagree. When you use them with keydown or keyup you get the code of the key on the keyboard. So it returns 65 for A but it also returns 65 for a. If only English is being used this is not a problem because you can use e.shiftKey to know which is which. Unfortunately this does not work in other languages which use hundreds of different codes for accented letters and special characters etc. When you combine e.keycode with keypress you get an entirely different result. You get nothing for keys like Alt and Shift but you get the exact code of the character to be typed. For example if you type é on a French keyboard you get 233 which is the number for é. Using keydown or keyup you get 50 because it's the same key as the 2 on an American keyboard. You can use code like this to test this.

Code: Select all

 <function name="myKeyPress" event="keypress" params="e">
  <![CDATA[
   var myKeyCode = e.keyCode || e.which //More than just ASCII code :-)
   var myTxt = tbfunction_pgTBObjGet("result", "text");
   tbfunction_pgTBObjSet("iresult", "text", myTxt + myKeyCode);
  ]]>
  </function>

Hold down the Alt key on a pc keyboard and then type 0233 on the number pad. When you relase the Alt key the code 233 will be displayed. I then use codes like 233 with e.preventDefault() and String.fromCharCode(e.keyCode) to convert it to {hidden) text.

On a positive note I find that the autofill prompt problems no longer exist now that I am using a wordwrap field / textarea. I was confused because I had forgotten to upload the latest exported tbk to my site.

I'm afraid I still don't understand what I must do with pgAddEvent What should I use it on?
I am also very worried about the keyboard popping up. It seems to happen randomly in some parts of the program and even incessantly in others. I can't figure out why.

[Clifton]

Any object which can receive focus will cause the keyboard to show. Even buttons that receive focus. When a page loads, it is best to set body.focus() to prevent any element from stealing the focus and causing unexpected keyboard popping.

UPDATE: pgAddEvent() is the default event listener that is used when writing functions in PowerPac's XML system. So it is being automatically invoked unless you write your own code that needs to setup other special event listeners.

[John Robin Dove]

Many thanks. I'll try again tomorrow.

[John Robin Dove]

LATEST UPDATE ON PROBLEMS ABOVE

I have been able to handle the virtual keyboard problem by using document.activeElement.blur(); The problem is not related to the media player as I initially thought. In fact just clicking anywhere on the page causes the keyboard to pop up! This occurs on certain pages displayed in an iframe by pgGotoURL but not others. If document.activeElement.blur(); is used as soon as the page is loaded, there is no problem. So thus far, this is the solution I am using. I used alert(document.activeElement.id) to try to get a better understanding of what goes on and it returned sysPageFrame. I wonder if this is for the exported tbk in the iframe or for the main page?

After further investigating the keydown e.keyCode system, I decided to follow your advice and use keydown instead of keypress. I had thought this was impossible because the French keyboard has so many differences. It's called AZERTY because for example the A is where the Q is on most other keyboards and the Z is where the W is etc etc. However I then discovered that this has been taken care of in keydown. You still get 65 for A even though the key is in a different place and the same is true of all other letters. So if the user is not allowed to use accents etc. there is no problem. I made a system to allow only English letters to be entered. I have now discovered that this useless for Chrome on Android because it doesn't handle keycode correctly. It always sends 229! https://stackoverflow.com/questions/36753548/keycode-on-android-is-always-229 Furthermore e.prevent default does not function either! https://stackoverflow.com/questions/42011740/event-preventdefault-not-working-for-android-chrome Although these bugs are four or five years old, they have never been fixed. I shall have to continue using my previous system it seems, unless I find something better.