Better User Login


Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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??

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.