INKEY() on the internet

[sdocker]

Hi,

I have an app where the user goes to a website to enter information.

= ExecuteShell('[URL unfurl="true"]http://pprextensions.dat.maryland.gov/',[/URL] "Open", "", "")

The code works fine. My issue is, the area where the user has to enter the data is near the bottom of the page, and I would like to scroll there, or at least close to it.

INKEY(x) 
KEYBOARD "{END}"

doesn't work.

Any other suggestions?

Thanks,
Sam

 

[Olaf Doschke]

Sam,

this won't work via ShellExecute, you open a new Window of which you know nothing, neither HWND nor ProcessID. To send keyboard input to other applications you can't use VFP Keyboard, thits limited to send to the active VFP window, same process. Maybe look here: thread184-1673207

oWsh = CREATEOBJECT("wscript.shell")

* Run the URL
oWsh.Run("[URL unfurl="true"]http://pprextensions.dat.maryland.gov/")[/URL]

* Give the browser a moment to load
WAIT TIMEOUT 1.0

* Scroll via END key
oWsh.Sendkeys("{END}")

This works for me, but it is not a serious basis for automating browsers.

Bye, Olaf.

 

[sdocker]

Thanks Olaf.

A big help.

Sam

 

[Olaf Doschke]

Just by the way: Just because you send keys to your browser, that doesn't send your key input to the internet.

The pages displayed in browsers come from the internet, some sites might have javascript code processing your input, but surely not every keystroke is sent back to servers and processed there, You have javascript to be able to execute locally and not need to overload your server with every detail of your website usage. In the end the browser is a local process like any other application, it's not the only type of application being able to make web requests or post data. but those two things are making most traffic to webservers, HTTP GET and POST requests. They don't happen with every keypress, in web forms for example the typical point of posting form data is the submit.

A more elegant way to let a browser window scroll to a certain point on a webpage would be introducing an anchor (a tag) with name and/or id set to some name you then can move to by adding this name to a URL after #. That would be possible using a webbrowser control, loading the webpage and then acting on the DOM as aftermath. If you're at it, you could also use several javascript ways to scroll to somewhere, eg look into

https://css-tricks.com/snippets/jquery/smooth-scrolling/

That said it's not that simple to add in the missing anchor right at the form begin, such things are easier to introduce by the site owners, obviously.

Bye, Olaf.

 

[sdocker]

Olaf,

You lost me on your last post. But, thanks anyway.

I tried the CRFEATEOBJECT code.

It does the job, but also sounds a chime and displays a "NUM LOCK ON" message. This is probably a setting on my machine, but it may also be on a user's machine and I would like to avoid it, if possible.

Sam

 

[Olaf Doschke]

You lost me on your last post

Mainly I was pointing out how wrong the idea is you have to "INKEY() on the internet". You sendkey to the locally started browser application.

The usual way to get more grip on a webpage you load is to load it inside your app, the webbrowser control is just under OLE controls and would be a browser canvas embedded in a VFP form. You can navigate to the URL in there and when that's done can act on the DOM (document object model) If you even don't know that term forget about going that root, it has a steep learning curve. In the end, what do you think is inside a browser behind the scenes, just the html text? A browser "executes" that and creates an object tree hierarchy called the DOM.

sounds a chime and displays a "NUM LOCK ON" message

No idea where that would come from and could be prevented.

In the situation you are the best solution might be very simple advising the user to scroll down on the new browser window appearing by running the URL. Is it that bad? If I'd give you the link here in the forum I would also simply tell that in a text rather than trying to modify the link to scroll down for you automatically (if that was possible at all). What's so bad about that? It's not your fault the site has such a long bureaucratic explanation before the form.

Bye, Olaf.

 

[sdocker]

Thanks, Olaf

Notifying them is a workable solution, as I inform the use that the information they need is in the clipboard ready to be "PASTED".

The chime comes from a keyboard setting. (See attached). The user can adjust his machine as required.

Sam

 

[Olaf Doschke]

Well, if you go that route no problem with the keyboard setting, is there?

Others would try to automate the whole process - loading the page, setting the input and submitting the form - all automatically.

In this simple case I wouldn't automate this, because it is a simple webform users can fill in and if it changes your webpage automation may easily break leaving users with nothing, while they now can act with whatever in clipboard and seeing the (then changed) form. They also get a better impression what you do instead of doing it silently and secretly.

If there was an official API from the government site, than this would be a preferred solution for electronical data interchange. The nature of an API is not only better targetted for automatic use, it is a contract and promise to accept data the API way unless an API deprecates and is replaced with a new version (faster, more secure, with other data schema, whatever necessities lead to v1.1 or 2.0...). Pardon me, it can't be pointed out too often for a better IT integration and flow of informations sites should offer APIs or other interfacing for software vendors and software vendors should also make use of them.

Bye, Olaf.