🚀 go-pugleaf

Chris Croughton wrote:

>On Thu, 29 Jul 2004 10:16:17 -0700, Bob Gonder 
>
>Because the application is already running, and can interpret its
>user input however it wants.

So? It's the same application! There's nothing to keep it from reading
the commandline and interpreting it exactly as it does the user input
from the address field.

>  For instance I have one browser which
>systematically tries adding www. to the front, .com, .org etc. to the
>end, until it finds something which works.  That sort of thing is up to
>a program to do (some may want to try opening as a file first, others as
>a web page first, or whatever).

And that affects what?  ShellExecute has alread determined that it is
a "web or html" thing. Now it's up to the browser to find it however
it can.

>Programming interfaces are dumb.   If I say fopen("fred", "r"), it won't
>look for fred.html, fred.htm, fred/index.html, http:/www.fred.com/ or
>anything else, it will look for a file called fred in its current
>directory.  If the programmer wants anything else, they can write it.

It's not the interface that's dumb, its the RTL. If you wrote a smart
RTL, it could do as you say.  In this case, the RTL is I.E. which is
hardly dumb.

>> Why should the programmer interface be dumber than the user interface?
>
>Because the programming interface needs to do what the programmer wants,
>and nothing more.
>  If I tell it to run "fred.com", it will assume that I
>mean the file of that name.  If the file doesn't exist (or isn't
>executable) then it will return an error, and the program can then
>decide what to do (it probably wants to give the user an indication of
>error, for most purposes;

Ahem.  The browser doesn't run "fred.com" (if it does, it should be
shot.)

> only a browser would assume that it meant an
>internet address, and that would probably assume web access as the first
>option).

And that's what this was about..The browser interface, not "fred.com"
This is about "Index.html"
ShellExecute looks at the file type, and decides that the browser
needs to handle it. So, it passes the command to I.E. It should pass
the parameter field, but it doesn't, it passes the filename. I.E.
receives the file name, but doesn't treat it the same as if a user
typed it in. It could if it wanted to.  Agravating all around.

>If I type "fred.com" into IE, it will look for a web site with that
>name.  If I mean that it should open a file of that name, I have to tell
>it explicitly (or use an editor or some other program).

Not if it is a full path.
C:\Fred\fred.com  Will only look to your HD.
While www.fred.com will only look on the web.
Ok, but how does it know that that isn't the name of an exe somewhere
on the path? You've got a point there, but...this is off topic...

The topic was the Browser. ShellExecute knows from the "html" that
this is a browser object, so the topic is the browser interface, and
not about what ShellExecute might do to other things. (Other than
perhaps, if it were to pass the parameter field to document handlers,
how that might mess up the handlers? It shouldn't.)

More to the original point:
C:\Fred\Index.html will only look to your HD
While www.fred.com\Index.html will only look to the web.

Since ShellExecute sees that they are html files, it knows to start
the browser and pass the command on. Here, 2 things go "wrong"
1) It doesn't pass the parameter field to the executable (I.E.)
2) I.E. doesn't parse the command line addresses in the same manner
that it parses user input addresses.
My opinion is Both should happen.
I don't see how doing either (or both) of those would cause problems.

ShellExecute(hWnd,"open","C:\\Html\\Index.htm","#Start",NULL,SW_SHOWNORMAL);
really _should_ work. As should
ShellExecute(hWnd,"open","//bob/c/Html/Index.htm","#Start",NULL,SW_SHOWNORMAL);
(It doesn't, but that's what this rant is all about)