Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Loading Http vs HttpS with ShellExecute

Loading Http vs HttpS with ShellExecute

Loading Http vs HttpS with ShellExecute


I need to load the "https" version instead of "http" using the ShellExecute routine below. Any idea how this can modified? Thanks, Stanley

CODE -->

Declare Integer ShellExecute In shell32.Dll ;
        INTEGER hndWin, ;
	STRING cAction, ;
	STRING cFileName, ;
	STRING cParams, ;
	STRING cDir, ;

cFileName = 'www.' + Alltrim(Thisform.txtSldnTldn.Value)
cAction = "open"
ShellExecute(0, cAction, cFileName, "", "", 1) 

RE: Loading Http vs HttpS with ShellExecute



cFileName = 'https://www.' + Alltrim(Thisform.txtSldnTldn.Value)

Is the answer...

Thanks, Stanley

RE: Loading Http vs HttpS with ShellExecute

Nothing to see here, move on...

Sorry, couldn't resist. But I can totally get how this evolved from a habit that started by having the "www." prefix to simplify the entry of URLs by removing the need to enter that common prefix.
If you get strict on anything in that way, it becomes harder to free yourself from your own restrictions. Even though the "www." was never meant as restriction.

One "notice" comment I'll make to this:
A Browser will automatically extend an incomplete URL without www, so you did never need this.

Here's a screenshot of Chrome's Dev Tools, Network tab:

The network tab shows all requests the browser does. Starting with just tek-tips.com, neither prefixed by www nor http:// or https://, the browser makes its request to http://tek-tips.com. You already get to the server, which redirects to http://www.tek-tips.com, and then the server reacts with another redirect to https://www.tek-tips.com.

Depending on which Webserver software is used and how redirection rules are defined, this could also be done in one step. But never mind it takes tek-tips.com two steps to get there, tek-tips is not the only server doing such things automatically. Browsers also automatically follow redirects, so the user experience of it is an automatic fix of the URL address.

What will not work is starting with "tek-tips" without the ".com" TLD, because then Chrome (and most other browsers) will handle this as a search term and request a google search (or whatever you make your default search engine.

Well, and first of all in your usage of ShellExecute, "tek-tips" alone wouldn't even trigger opening the standard browser, but look for a file named "tek-tips". So before these 301 redirects happen, you'll need to ensure the ShellExecute addresses the default browser and interprets the cFileName parameter as a URL in the first place.

Regarding ShellExecute, the minimum requirement for it to interpret something as a URL is a www. prefix, but more to the point is a http:// prefix, that'll then find https:// automatically, unless a server is configured weirdly.

So what you could have done instead of the "www." prefix is use the "http://" prefix to navigate to sites with/without www and also with http or https.

You can't use the same strategy with a HttpRequest object, which would only return the status 301 and the redirect URL but won't automatically go there.

The conclusion is, you could change your code to:


cFileName = 'http://' + Alltrim(Thisform.txtSldnTldn.Value) 

That will a) open a browser and b) the browser will change to www. or not and to https:// or not automatically.


RE: Loading Http vs HttpS with ShellExecute

And then one further adjustment you could make is accept the txtSldnTldn.Value as is without any prefix, if it already contains "://".


RE: Loading Http vs HttpS with ShellExecute

Thanks Chriss for not resisting, as I have learned even more from your post. This whole ShellExecute script was grabbed from some site long ago. I'll test some of your suggestions to see if the automatic stuff will help in my situation, or do I need to do it manually.

Why the need, you ask? The domain whois lookups are returning values indicating whether or not the domain is taken, however it does not tell me whether it is in use, parked, or going nowhere. I haven't done much work in this area yet, but now the apps operator can select any of the selectable domains (com, net, org.....) and click one button where it iterates them in both http and https versions. I will probably look to automate this in the future and auto save the http get request to the url table. More on this later.

Anyway, thanks again,

RE: Loading Http vs HttpS with ShellExecute


This whole ShellExecute script was grabbed from some site long ago.

That might have this article on my own site: Introducing ShellExecute()

If you glance at that article, you will see that there are many uses for ShellExecute() beyond navigating to web pages. The main point to keep in mind is that calling ShellExecute() is the programmatic equivalent of invoking an object from the Windows UI (the Windows shell). For example, calling ShellExecute() for a document file is equivalent to double-clicking on the document on the desktop or right-clicking on it in a folder window and selecting Open. Either way, the action will be to open the document in whatever application the relevant file belongs to.

By the same token, calling ShellExecute() for a URL will open it thee URL the user's preferred browser. The browser will accept the URL with or without the http:// or https:// prefix, which explains why your code works the way it does.


Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: Loading Http vs HttpS with ShellExecute

Hi Mike,

I think that is where I got the code... (from your site). I have been using it for a long time doing other stuff instead of using the run command. Been very happy with it as it is stable and predictable. So, thanks a million...

Chriss made several points that I was unaware of, mainly of how the browser's automaticness works.

In the past, I also had to do IIS bindings and router redirects to deal with http://name.com, https://name.com, http://www.name.com, and https://www.name.com, representing ports 80, 443 and with or without sub-domain names.

So next time I'm in the router, I will test some of his suggestions to see how far the browser's automatic stuff works.

Thanks, Stanley

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close