From: Karl E. Peterson on
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
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
> > 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
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
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Filling an excel range from a vb function
Next: 1.0e to VB6