Create Folders and Write To Hard Disk Other than C:
in [Visual Basic]
|
From: Karl E. Peterson on 9 Mar 2010 14:30 Paul Clement wrote: > � You're supposed to be an expert in VB. I don't > � see how you can prefer shelling to a utility or > � calling a specialized COM DLL over simple, concise > � API code. Both of the methods you're suggesting > � provide VBS samples for a good reason: They're aimed > � at system admins who don't have access, knowledge, > � or tools to use the API. What could be more of a hack > � in compiled software than shelling out to a command > � line utility designed for system admins? > > I didn't state a preference, simply a couple of alternatives. There's that intellectual dishonesty again. Patient: "Doctor, I have a really bad headache!" Doctor: "Well, you could take a couple of aspirin, hit your head against a wall until you knock yourself out, or just take these prescription painkillers along with a pint of whiskey. The choice is up to you! They're just a few possible alternatives!" > � > Kind of ironic that the solution chosen by the OP > � > at the Experts Exchange link you posted > � > implemented the scripting solution from my first link. ;-) > � > � Ironic? Yes, the OP decided to call xcacls via > � WScript.Shell. You think that makes your case? > � The link is a discussion between scripters using > � VBS under the WSH! > > It's not about making a case. What I choose to implement may be different > than what you or someone else may choose, based upon knowledge, experience, > requirements and other factors. Coward. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Paul Clement on 9 Mar 2010 15:29 On Tue, 09 Mar 2010 11:30:33 -0800, Karl E. Peterson <karl(a)exmvps.org> wrote: � Paul Clement wrote: � > � You're supposed to be an expert in VB. I don't � > � see how you can prefer shelling to a utility or � > � calling a specialized COM DLL over simple, concise � > � API code. Both of the methods you're suggesting � > � provide VBS samples for a good reason: They're aimed � > � at system admins who don't have access, knowledge, � > � or tools to use the API. What could be more of a hack � > � in compiled software than shelling out to a command � > � line utility designed for system admins? � > � > I didn't state a preference, simply a couple of alternatives. � � There's that intellectual dishonesty again. � � Patient: "Doctor, I have a really bad headache!" � Doctor: "Well, you could take a couple of aspirin, hit your head � against a wall until you knock yourself out, or just take these � prescription painkillers along with a pint of whiskey. The choice is � up to you! They're just a few possible alternatives!" Or you can just take a couple of aspirin or Tylenol or Advil, whichever works for you. Lets be intellectually honest and suggest something reasonable. OK? � � > � > Kind of ironic that the solution chosen by the OP � > � > at the Experts Exchange link you posted � > � > implemented the scripting solution from my first link. ;-) � > � � > � Ironic? Yes, the OP decided to call xcacls via � > � WScript.Shell. You think that makes your case? � > � The link is a discussion between scripters using � > � VBS under the WSH! � > � > It's not about making a case. What I choose to implement may be different � > than what you or someone else may choose, based upon knowledge, experience, � > requirements and other factors. � � Coward. Yeah I know, only your way is *the* right way. Paul ~~~~ Microsoft MVP (Visual Basic)
From: mayayana on 9 Mar 2010 16:44 > > I didn't state a preference, simply a couple of alternatives. > > There's that intellectual dishonesty again. > On the other hand, there's something to be said for different approaches. Bee could switch to .Net and get the benefit of that 300MB wrapper. Then he could use the famous Interop to wrap wshom.ocx (wscript.shell), which wraps the call to ShellExecute, to call xcacls, which wraps the call to the permissions APIs. That way he'd have a "modern, up-to-date and supported solution". :)
From: Karl E. Peterson on 9 Mar 2010 18:30 mayayana wrote: >>> I didn't state a preference, simply a couple of alternatives. >> >> There's that intellectual dishonesty again. > > On the other hand, there's something to be said > for different approaches. Bee could switch to .Net > and get the benefit of that 300MB wrapper. Then he > could use the famous Interop to wrap wshom.ocx > (wscript.shell), which wraps the call to ShellExecute, > to call xcacls, which wraps the call to the permissions > APIs. That way he'd have a "modern, up-to-date and > supported solution". :) I think the barbituates and whiskey combo sounds preferable! -- ..NET: It's About Trust! http://vfred.mvps.org
From: Dee Earley on 10 Mar 2010 07:36
On 07/03/2010 05:20, Nobody wrote: > "Bee"<Bee(a)discussions.microsoft.com> wrote in message > news:F43267B0-46BA-40CB-ACC2-D7FE7AC86748(a)microsoft.com... >> (3) when I reopen the app, do I need to do anything if I find the folder >> previously created? e.g. set permissions again? etc. > > Setting the permissions will not work unless the user has enough privileges, > so if user can't do it with Windows Explorer, your application can't, it > would get access denied errors. One solution is at install time, install an > ActiceX EXE and configure it to run as SYSTEM, then talk to it using your > app. This AX EXE would change the permissions for you. Or just configure it to ask for elevation: http://hashvb.earlsoft.co.uk/Vista_UAC_and_Elevation#COM_elevation -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems |