Macro - last user retains control

I have this macro that I wrote not long ago, and it appears to work mostly
fine. What I have found, though, is that it appears that the last person to
run it from the network retains control of it. The reason I say this is
because I found that I couldn't rename it, overwrite it, delete it, etc.
Upon checking the server, we identified the person that it said it belonged
to, and upon further testing, found that the person with the control was the
last person to run it. At the end of it I cleared my variables to release
the memory, so that's not it. Any thoughts as to why this is happening?

WT

'
******************************************************************************
' CreateNewConfig
' Created by Wayne Tiffany, 2/17/07
' This macro will create a new configuration in the part file based on
' the current configuration. It will add an "A" to the end of the name,
' & optionally add a "0" to the beginning of the name.
'
******************************************************************************
Dim swApp As SldWorks.SldWorks
Dim Model As SldWorks.ModelDoc2
Dim StartConfig As Configuration
Dim configMgr As ConfigurationManager
Dim StartName As String
Dim CParent As Configuration

Sub main()

Set swApp = Application.SldWorks
Set Model = swApp.ActiveDoc
Set configMgr = Model.ConfigurationManager

Set StartConfig = Model.GetActiveConfiguration
StartName = StartConfig.Name

Debug.Print StartName
Debug.Print StartConfig.IsDerived

' Message box section
Dim Quest, Style, Title, MsgBoxResponse, NewName
Quest = "Do you want to add a 0 to the name?" ' Define question
Style = vbYesNo + vbQuestion + vbDefaultButton1 ' Define buttons
Title = "Add 0 - Y/N" ' Define title.
MsgBoxResponse = MsgBox(Quest, Style, Title, "", 1)
If MsgBoxResponse = vbYes Then ' User chose Yes
NewName = "0 " & StartName & " A" ' Add the 0 & the suffix
Else ' User chose No.
NewName = StartName & " A" ' Add only the suffix
End If

Model.ShowConfiguration2 (StartName) ' Need this to force the focus to
the current config
configMgr.AddConfiguration NewName, "", "", 0, "", ""

Set CurrentDoc = Nothing 'Clean up variables
Set swApp = Nothing

End Sub

 

Wayne,
Not sure if it is the same issue, but I have several macros
written that exihibit the same or at least similar behavior. The
first user to run the macro retains control until they close their
session of SW. Until then, no one, not even an admin, can rename,
overwrite, etc. One nasty side effect of this is that while working
on the macro, if you run it and then try to debug, you cannot save
without shutting down SW and restarting. Not even a save as. And the
messages from SW are ambiguous so you don't get a clear picture of
what happened. Not sure if this is what you are seeing. SW2006
(various SPs).

 

Wayne,

If I understand you correctly, it seems to be a Windows function and
not directly related to SolidWorks at all. When VB (or many other MS
software like Excel, Word, etc) opens a file, it claims control of
that file. No one else can edit it while one person has it open.
Others can access it and use it, but cannot save to it. There is
nothing you can do about this at all. Its a file management issue
with the Windows OS.

However, if you find that no one has the file open, and it still shows
a user with ownership, then this utility may help you:
http://sw.fcsuper.com/index.php?name=UpDownload&req=viewdownloaddetails&lid=45
However, if the issue is cronic, there may be a network issue that
also needs to be addressed.

A secondary temporary fix is to simple rename the folder in which the
macro lays. Then copy that whole folder and rename it to its original
name. The locked file will remain in the old folder that now has a
different name, and the new unlocked file will be in the folder with
the correct name. I use this trick once in awhile to fool Windows
into giving me control of a file that has been incorrectly locked.

Matt
http://sw.fcsuper.com
Co-moderator of http://groups.yahoo.com/group/solidworks/

 

I believe this is what I am seeing, and it's not limited to just this one
file. I tried the Unlocker program also mentioned here and it comes back
with "No Locking handle found." I tried to rename it, but it couldn't.
Hmmm.

WT

 

Wayne,

This has been the behavior of SolidWorks macros for years. Whenever a
User runs a macro, that macro remains open in SolidWorks memory (kind
of like opening an assembly file, and even tho you only opened that
one file you actually have ownership of all of the component files
[and they're open] in the background). Below is the macro behavior
I've observerd, and the method I use to make and distribute macro
updates for macros shared across a network.

During an SW secession, run a few macros and then go into the Macro
Editor. You will *all* the macros you've run listed in the Project
Window. Go up to the Run menu and choose 'Reset'. Now close the
Editor, then go back into the editor (you'll have to choose a macro to
edit, choose any one that you want). Now in the Macro Editor you will
only see that one macro listed in the Project Window. Hence you have
released ownership of all the other macro files (or at maybe better
stated...closed all the macros SW had open in the background). So
during a SolidWorks secession, if you never go into the Macro Editor
and hit the 'Reset' button, which I would *not* expect Users to do
(and they shouldn't have to), then that macro (and *all* others) will
remain open in their SolidWorks secession until they close SolidWorks.
In the macro code itself, I have tried clearing out all variables and
objects at the end of the macro, but no matter what I tried...that
macro remains in SW memory until I either 'Reset' in the Macro Editor,
or close SW. The only advantage I've seen from this behavior is that
macros already open in the SW background do initialze/load faster
(maybe a couple tenth's of a second faster but for the most part
hardly even noticable unless you are paying attention and comparing).
Try it for yourself, it is noticable even without a stopwatch. )

To continue, so what happens is that the first User to run the macro
gets Write-Access to the file. Any subsequent users that run the macro
get Read-Only Access. Note that if the owning User changes that macro
code and saves the changes, none of the Users that have the macro open
Read-Only will see the changes until they either 'Reset' or restart SW
(because they still have the Read-Only version open in the background
and will continuse using that version until it gets dumped from
memory). Also, once the owning User has hit Save in the Macro Editor
and closes that macro, SW releases ownership the macro (and the macro
will *not* be open in your SW secession any more, same as hitting
'Reset'). The next user to run that macro that does not already have
the Read-Only version open, will then get ownership (i.e. Write-
Access) of that file.

The work-around I use for editing/updating macros shared across a
network is:
1) Make a "User Macros" directory (for instqance the one you're Users
are all already looking at), and make all macros in that directory
Read-Only from Windows Explorer. Even better would be to store that
directory in a location that only Administrators have write-access
rights too.
2) Copy that folder and all the macros to a different location on the
network. Remove the Read-Only setting on the files. Consider this your
*Master Macros* file location. Put this somewhere that only you (or
Administrators) have access to. This is were you will edit macros, and
even run macros from when debugging. Do not consider this a production
usage location for macros. Personally, I always make a backup copy
first so I don't have to bother the IT guys if I screw the macro up
and want to restore it and start over.
3) Now what happens is that all Users will run macros from the "User
Macros" location and will get Read-Only access to the files when
running them, therefore the files will not be locked. What you will do
is Edit a macro from the "Master Macros" directory, and once you're
happy with it copy it over the file in the "User Macros" directory.
a) If a User is in an urgent need of this update, tell them to
close down and re-start SolidWorks (which is easier than explaining
the whole 'Reset' thing in the Macro Editor, but doing the 'Reset'
thing will allow them to keep SW and any files open and running, so
your choice). Otherwise (if it's not urgent to distribute the update),
you know that the macro file is updated, and that the next time they
re-start SW they will see the update (this is what I usually do).
b) You may be wondering why I don't just store the "User Macros" in
an location with Admin Rights only and just edit the macros there
(since I'm the only SW User with Admin Rights)...I tried this, but it
seemed inconsistent in saving my changes. Even tho other Users had the
file open Read-Only, I still had times where the Macro Editor did not
save my changes. I know this sounds like a User (i.e. myself) error,
but editing the macros there and getting them to save was not reliable
for me. Editing the macros in a separate (Master) directory meant that
my changes were *always* saved. Even if some how an error happened
when trying to copy the Master Macro over the User Macro, I know that
the Master Macro is right *and more importantly* I don't loose my
changes.

Later,
Ken





Make a "User Macros" directory (like the one you're Users are all
already looking at), and make all macros in that directory Read-Only
from Windows Explorer.

 

Very interesting discussion. Why not just run the macros from local
directories and then update those directories as you revise the
macros? We only have 3 users here, and I'm the only one writing
macros, so it doesn't take much work to update; but I suppose with a
lot of users this could be a hassle.

Diego

 

This isn't the behavior that I've seen. If any user runs the macro,
they get read only access. The first person to open the macro for
editing gets write access. For example, if I have a macro on my local
drive (that's where I write/debug them), and I run it, I cannot then
edit the macro and save the edits (without closing SW, of course -
I've never tried the 'reset' trick, but I will now). Not even 'Save
As' works (there is no such option). If I edit first, then I can save
the edits and run the macro as many times as I'd like. Kind of odd
behavior.

 

I think what I am seeing here is probably not unique to us, it seems. Most
of the macros are being accessed from local folders, but once in a while I
will tell someone to go run one off the network, and that's where I found
that I couldn't do anything with it after that. The network folder is read
only for everyone but me, so it's not a case of anyone having write rights,
it's the fact that SW appears to keep the file open.

I like the idea of the reset as I too have run into the situation of testing
my own macro and not being able to save it. I guess those times I must have
test run it before I opened it in the editor. I have also seen times when I
see many macros open in the editor and I didn't understand why they
sometimes show up. Now I do. Thanks guys.

WT