Better User Login

[burt4munger]

I'm trying to have a fairly easy user login page that will take a user name and password and validate against the SQL server. The issue I'm having is that I would like to have a tab or CR function that would use the new setfocus() to move the cursor to the next field. I also want to use a password edit box to hide the password, so I can't really use system.entrydialog(). In browsing through the help file, I see a property for the edit box component DoOnCR, but no explanation of the syntax to use. That would probably do the trick for me, since then: the user presses a button, it changes the current page and sets focus to the username field, and displays the onscreen keyboard (it's a touch system). They type their name, hit enter, and setfocus moves to the password edit box. They type their password (*** echo), hit enter, and that triggers the function calls that hit the database, set the user parameters and display the proper starting page.

So how does component.xx.DoOnCR work?

[burt4munger]

So, after more reading, I found the setfocus.ctl in the DAQfactory samples folder, and used that to accomplish the scenario above. There is still no help info on DoOnCR though, and it might prove useful for something in the future.

[AzeoTech]

DoOnCR is just a boolean value. If true, the set channel is updated with the value entered into the edit box when the Enter key is pressed. If not, its not and presumably you have one or more of the other options set so the value does get set at sometime.

[SteveMyres]

I have a similar application which has been run on a desktop PC but is being ported to a touchscreen, so the users will need the Onscreen keyboard now. For variable entry it's working fine.

The user login isn't, though. In my case the first login input is the password (no user names per se, just access levels). I can't seem to get the Onscreen keyboard to send keystrokes to the password edit field. The Onscreen keyboard is not visible most of the time. When they want to log in, the users press a button, which turns on the Onscreen keyboard and opens the login popup. Is the problem that I'm activating the login as a popup and I need to be fully switching to it as a page?

[AzeoTech]

Depends. How are you enabling the keyboard? Maybe post a simple app that shows what you are doing?

[SteveMyres]

Generally, System.OnScreenKeyboard == 2. When I want to open the login popup, I set System.OnScreenKeyboard = 3, clear the password string, call UpdateEdits(), pop up the login dialog, and SetFocus() on the password entry. The screen keyboard appears, but whatever you type on it doesn't send to the password entry box. When they close the popup, System.OnScreenKeyboard is set back to 2.

[AzeoTech]

Right, you are popping up a user screen. I'm not completely sure the keyboard will direct to a user popup. Have you considered just adding a keypad of your own to the popup?

[SteveMyres]

How do you add your own keyboard? Just make a bunch of individual buttons that each add a character to the string?

[AzeoTech]

Yup. The string would be the variable in the edit box.

[SteveMyres]

By the time you add a semi-fullish keyboard, the popup will probably be most of the screen anyway (touchscreen is only 15" 1024x768), so I'll probably just make the login fullscreen and use the built-in keyboard.

I couldn't figure out what I was doing different from the original poster and his apparently worked in this respect, but I went back and read it and he doesn't say he's using a popup, so that must make the difference.

So WRT onscreen keyboards working with popups, now you know!

[burt4munger]

I used a full page login form for the reason that you can't send the onscreen keyboard to the popup. For other popups, I made (or found) a number pad keyboard.

[SteveMyres]

It's strange -- I can't get the onscreen keyboard to feed an edit box (password OR regular) even FULL PAGE, regardless of what System.OnScreenKeyboard is set to.

[AzeoTech]

Hmm. Works fine for me. I just created a blank document, added a regular and password edit box, went to the command/alert and typed: system.onscreenkeyboard = 3, then clicked on either of the edit boxes and when I clicked on keys on the onscreen keyboard, it worked.

[SteveMyres]

Bizarro. I create a new CTL, create regular and password edit boxes, set onscreenkeyboard = 3 via C/A window, click in the box (either type), cursor appears for typing, click a key on the onscreen keyboard, cursor disappears from the edit box and no characters (or stars) appear.

Still testing this using a mouse on a desktop PC (as I assume you are).

DF Pro, v5/87a build 2022, working on a runtime-licensed system using a USB dongle.

[AzeoTech]

OK, figured out what you are doing different: is your keyboard docked to DAQFactory or is it a floating window? It works correctly if docked (because its part of the main frame of DAQFactory, but does not work if it is floating because then it is its own window.

[SteveMyres]

Yup, you called it -- floating! I'll try it tomorrow docked, but obviously that's the issue.

[SteveMyres]

So what exactly does floating mode do? What's the scenario where it works? Or is it a built-in Windows thing only one of whose modes is useful to us in DAQ Factory? Even then, how and when does it work?

[AzeoTech]

Floating is useful for all the other windows, like Workspace, Command / Alert, etc. Its obviously not so useful for the keyboard, except as a mode that the window exists between docking. Basically in order to make it so you can dock the keyboard at various spots on your window (say at the top instead of bottom), we had to allow it to be floating because the whole float / dock feature is built into the windows UI. For Workspace and all, it is sometimes useful to have it float. For example, if you had multiple monitors, you could float the workspace on a separate monitor.

[SteveMyres]

OK, so it's something Windows offers and which is obviously useful in the case of the other windows, and that one has to be allowed to float in order to allow the others to do so. Makes sense.

[AzeoTech]

Yes and no. It wasn't allowed to float because of the others. There's a flag we can set to keep it from floating. Its allowed to float to allow you to dock it on another part of the window. You can't move a window without allowing it to float. Unlike the others, it was never intended to remain floating, only to float when moving between two docking locations.

[SteveMyres]

The weirdness continues. The keyboard does indeed work when docked, in development mode. If I switch to Runtime mode while in the login screen or call the login screen while already in runtime, the keyboard disappears. If I switch back to development mode while still on that page, the keyboard reappears.

I'm sure whatever I'm doing wrong must be simple. Do you have any idea what it might be??

[AzeoTech]

a) go to the runtime menu (top left icon) and select On Screen Keyboard

make sure you have script somewhere on startup that enables the keyboard: system.OnScreenKeyboard = 3

[SteveMyres]

Cool, thanks!