Network Permissions and API calls 1

[rocheey]

It wasnt long after our IT guy left that my old NT4 partition drew its last breath. Im now running SW03/SP3 on a Win2k/SP4 box.

Im now finding that none of my programs that attempt to read the geometry out of a dwgdoc.View are working. There is no error, it just returns happily and says the UBOUND of the geometry safearray is -1. (I would have thought the call to return an EMPTY variant instead, tho)

Im also finding that I cannot access the feature manager tree in a drawing, as well. I have not found similar problems (yet) in assemblies or part files.

I am supposedly set up with default POWERUSER rights, where this call fails. I isolated the offending code, and put a simple part/drawing/macro up on the company server where I ran it from a box with ADMIN rights. It worked flawlessly. I also had success on my home boxes, user Win2k, and WinME.

I was given a 'limited' admin account (for my own local box) and the call works, from the same box, same apps, etc) but this limited account does not give me any access to the company network. Needless to say, all the files are on the network. And I wouldnt trust copying them down locally, because many of the assemblies use parts files of the same name, but in different directories... copying the correctly-named part file from the wrong directory, and running locally, could cause a disaster.

My VAR says that Ive identified the problem alright, but cannot give me any specifics to WHAT network permissions might be causing this.

Any of you wizards out there wear an API hat and an IT hat ?

 

[Standing]

rocheey,
This maybe a work around for you.
I have written a Visual Basic 6 program that copies files we want copied onto our C:\ drive. For example: SolidWorks always need to have the macros in a macros directory on C:\ drive. Everyone gets a new executable in the Target: of his or her SolidWorks icon. \\Athena\Eng\Applications\SolidWorks\Executables\StartSolidWorks.exe
StartSolidWorks.exe is as follows:
‘ * * * * * * * * * * *
Private Sub Form_Load()
Dim CopySolidWorksMacros As String
CopySolidWorksMacros = Shell("\\Athena\Eng\Applications\SolidWorks\Executables\CopyFile.exe", 1)
Dim StartSolidWorks As String
StartSolidWorks = Shell("C:\Program Files\SolidWorks\sldworks.exe", 1) ' Run Copy Files program & SolidWorks.
Call cmdExit_Click
End Sub
‘ * * * * * * * * * * *

The main part of the CopyFile.exe is as follows:
‘ * * * * * * * * * * *
' Alt R - RevBox
FileCopy "\\Athena\Eng\Applications\SolidWorks\Macros_Programs\RevBox.swp", _
"C:\Program Files\SolidWorks\Macros\RevBox.swp" ' To:
‘ * * * * * * * * * * *

When I changed anything in the CopyFile.exe program it will run every time they double clicked on the SolidWorks icon. This program would also update any changes to the RevBox program.
To do this, takes no special software other than Visual Basic 6.0. One thing I do not advertise is the fact that I have control of what happens when they double click the SolidWorks icon. I could delete any file on their C:\ drive, but I would not.


Bradley

 

[MadMango]

I talked to our IT Guy, and here was his response...

***
I've seen more problems with permissions in AutoCAD than I have in SolidWorks. In Windows 2000, tighter permissions were implemented on the registry and file system. Typically, AutoCAD users must be in the Power Users group. If this isn't done, AutoCAD will still run, but users will get an error when they start it that it couldn't find something.

I've never had an issue with SolidWorks regarding permissions, but when it comes to macros and things, here's what to consider when programming one:

-Users have read only rights to the registry's HKEY_LOCAL_MACHINE hive, and read only rights to the Program Files and WINNT folders.
-Power Users are allowed to write in some parts of HKLM, and have modify rights to the folders I mentioned above.
-Administrators have everything, of course.

What I would typically do in such a situation, and just to keep me from losing my mind, or spending hours researching specific security settings, is just add the user to the Local Admins group of the work station, warning of course that if any policy breaches are found, that I'd kick his/her butt. With some software applications, they require Local Admin rights... so I've gotten a little more used to the idea of doing this.

Now, just because a Domain User has Local Admin rights doesn't necessarily mean that he/she still has full control, especially in a Windows 2000 domain (when ADS is in place). Domain Policies can be configured to restrict even what Local Admins can do to their workstations. For example, we have a few users here who needed Local Admin rights, but through domain policies, I can still keep them out of places where they can do lots of damage (e.g. regedit). Of course, if somebody with Local Admin rights is smart enough, they can get around Domain Policies, but it's usually way over the average user's head.

Otherwise, if you /must/ know exactly where your problem is, so that you can remain a Power User, here's what I would do:

-Does it only happen on this machine? If not, what's the difference between machines?
-Log in to your workstation as the Local Admin (the actual Administrator account, or some other account with Admin rights), rename your user profile (by this I mean the folder you would usually be dropped in to if you were logged on as the user with a problem, and clicked Start>Run, and typed %userprofile%). Just appending .bak is sufficient. Log back in as the 'problem' user. You have a clean slate now. No weirdness in your HKCU registry hive, no weird control files in your user profile. This alone may fix your issue, but remember that this user probably needs Power User access. If this doesn't work, log in as the Local Admin again, delete the new user profile that was just created, then strip the .bak from the old user profile. Now you have all your settings and stuff back.
-Read more. Search any related knowledge base, and the entire internet 6 ways to Sunday.
-Escalate your issue with the VAR. Make them talk to SolidWorks, or which ever publisher may be involved.
-Take matters into your own hands:
-Monitor what's happening in the registry when your failure occurs. RegMon is available from the Win98 Resource Kit, or you can download it.
-If you find write failures or read failures related to permissions, up the permissions with regedt32. If you don't see anything wrong with the registry, things just got a lot more difficult.
-You can enable failure accounting for object access. This may log so much it'll flush your logs. Increase your log size if you need to.
-

http://www.sysinternals.com

has a plethora of monitoring tools that are helpful in situations like this. RegMon is there, but also DiskMon or FileMon for monitoring file IO. Your netadmins would probably love this site. I certainly do.

Basically, Start at the top (your macro/SolidWorks), and work your way down (object IO monitoring). Just look for things that fail, and up permissions on those objects.
Don't get your hopes up, though. Sometimes you get lucky and find it, usually you don't. If you have to monitor things to this extent to troubleshoot an issue, you're looking for a needle in a haystack.

All this said, I know nothing of SolidWorks or macros for it. There may be more to your error message than I would understand. If it were me, I would use a combination of the things I've mentioned, and pearls of wisdom from more experienced SolidWorks users. This may not even be related to object permissions at all. *shrug*
***

I hope that can be of some assistance.

MadMango
"Probable impossibilities are to be preferred to improbable possibilities."
Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[rocheey]

> Log in to your workstation as the Local Admin (the actual >Administrator account, or some other account with Admin >rights), rename your user profile


y a h o O O O O O O !!!


Not sure why this worked, but it sure as hell did!
A Star for you, Mr Mango, and a h*ndjob with a rubber glove for your IT guy. (He'll have to take a rain check, natch)

 

[MadMango]

I'll let him know he should be expecting you.

Glad you solved your problem.

MadMango
"Probable impossibilities are to be preferred to improbable possibilities."
Have you read faq731-376 to make the best use of Eng-Tips Forums?