> I don't think that naming local variables as interfaces is a good
> idea...
Why not? As long as there are no local variable collisions (and their
usually won't be) the the code is auto-documenting, anyone reading then
immediately knows what interface the variable represents. Same when
QI'ing the interface.
> (and note that this example assumes you have a URI for the file,
> and that you have the file protocol handler already in a variable
> called nsIFileProtocolHandler)
Exactly, and the naming convention ensures you know exactly what
interfaces I was taking about ;-)
Actually, in JS we have now started using the Components.Constructor
which enforces a slightly different mechanism with "ns" rather than "nsI":
var nsIProtocolHandler = new
Components.Constructor("@mozilla.org/network/io-service;1",
"nsIIOService", "getProtocolHandler");
var nsFileProtocolHandler = new nsIProtocolHandler("file");
Is there some scope collision you think would affect this?
N
Christian Biesinger wrote:
Neil Stansbury wrote:
var nsIFile = nsIFileProtocolHandler.getFileFromURLSpec( uri );
if ( nsIFile.exists() ) {
nsIFile.QueryInterface(Components.interfaces.nsILocalFile);
nsIFile.launch();
}
I don't think that naming local variables as interfaces is a good
idea... (and note that this example assumes you have a URI for the file,
and that you have the file protocol handler already in a variable called
nsIFileProtocolHandler)
If you want to pass arguments to the executable, you can use nsIProcess.
_______________________________________________
Mozilla-xpcom mailing list
Mozilla-xpcom@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-xpcom
