Revision control app macro (release)
Re: Revision control app macro (release)
Hi guys, sorry for my absence, for some reason I was not getting notifications, and now like 5 of them arrived at once I am looking into this issue as we speak. If there is no NDA or anything, could you please share at least one file (and it's revision history files) that shows the "subscript out of range" error, or missing revisions in the list? I can't seem to replicate either of these issues. If I had some samples, I could finally nail this down.
P.S. I think the issue was the revision sorting algorithm, I rewrote it, but I still want to test it with some of problematic files to ensure I didn't miss something.
P.S. I think the issue was the revision sorting algorithm, I rewrote it, but I still want to test it with some of problematic files to ensure I didn't miss something.
Re: Revision control app macro (release)
I think the root problem will be that the filename doesn't have an underscore. Figuring out where, in all of that code, the filename is selected and fed to the function is a different question.
-
I may not have gone where I intended to go, but I think I have ended up where I needed to be. -Douglas Adams
I may not have gone where I intended to go, but I think I have ended up where I needed to be. -Douglas Adams
Re: Revision control app macro (release)
Here's a file and it's versions from the Repo folder. I don't know why there's no "A.1" version. To be sure it was not a cause to the problem I duplicated A.2 and renamed to A.1 but it changes nothing.laukejas wrote: ↑Tue Nov 05, 2024 2:07 pm Hi guys, sorry for my absence, for some reason I was not getting notifications, and now like 5 of them arrived at once I am looking into this issue as we speak. If there is no NDA or anything, could you please share at least one file (and it's revision history files) that shows the "subscript out of range" error, or missing revisions in the list? I can't seem to replicate either of these issues. If I had some samples, I could finally nail this down.
P.S. I think the issue was the revision sorting algorithm, I rewrote it, but I still want to test it with some of problematic files to ensure I didn't miss something.
When I run the macro on this file, "Phases" and "Revision" change results in the "subscript out of range" error. The drop-down shows nothing.
Re: Revision control app macro (release)
Thank you! I think the issue was indeed the sorting algorithm that I changed from v3 to v4 (if I remember right). I tested your files with updated version, and it seems to work correctly now, but please check yourself to make sure. Attaching the v5_beta. Changes I made, this is from my changelog in progress:mgibeault wrote: ↑Tue Nov 05, 2024 3:55 pm Here's a file and it's versions from the Repo folder. I don't know why there's no "A.1" version. To be sure it was not a cause to the problem I duplicated A.2 and renamed to A.1 but it changes nothing.
When I run the macro on this file, "Phases" and "Revision" change results in the "subscript out of range" error. The drop-down shows nothing.231130-416.zip
- Rewrote the sorting algorithm, added a few helper functions to Utilities. Should fix the "subscript out of range" issue.
- The application will no longer automatically lock Released documents (make them read-only, lock external references and enable freeze bar), but will prompt the user by default. If you prefer to always lock these references (old behavior), or to never lock, edit the value of Constants.LOCK_RELEASED_DOCS_OPTION. As a result of this change, SET_RELEASED_VERSIONS_FREEZEBAR and SET_RELEASED_VERSIONS_LOCK_REFS have been deprecated.
- Additional Actions -> "Delete version history" was renamed into "Set new tracking ID", and the prompt rewritten to make it less confusing. The actual functionality did not change, but it should be clearer what this function does: it starts a new tracking history to the current document starting with revision A.1. Intended usage is when you save a tracked part with SOLIDWORKS Save As, and want to have a separate tracking history for this new file without deleting the old one.
- Eliminated the confusing "the key is already associated with this collection" error. It happens when you save a tracked part with SOLIDWORKS Save As, but do not assign a new tracking number. The application will now recognize this, and warn the user.
- Renamed some constants and functions.
- Some refactoring.
EDIT: I see lots of people are downloading it already, so please tell me of any issues that you find. I would like this V5 to be the final version, free of any remaining bugs, because I got lots of other projects going on, and I don't think I will have much time in the future to maintain this Besides, it has already grown past what a macro is meant for, and should be better-off re-written as an add-in... Nevertheless, if anyone wants to take over the development afterwards, feel free. Macro is open source project by definition anyway
- Attachments
-
- Version control app V5_beta.swp
- (590.5 KiB) Downloaded 51 times
Re: Revision control app macro (release)
Thanks to you!
I'll do extensive testing in the next couple of days and report.
Are you using only SolidWorks' macro editor to edit your macros?
Re: Revision control app macro (release)
Thank you, I'll be waiting And yes, I am using SolidWorks macro editor. I thought there aren't any other IDE options, or are there..?
Re: Revision control app macro (release)
Ok, I still get this "Subscript out of range" error.
Here's a video: -Nothing happens if I just use "Tools->Macro->Run..." or use the button "Run Macro". The MainForm shows up when I assign the macro to a button. Is it because there's a field for the method (Core.main) that cannot be specified otherwise? I lost a lot of time trying to find why the macro would do nothing as I was testing with a "Run Macro" button.
-When I "Step into" and then F8 repeatedly, I get in a loop here: -Where is defined the sentence "This will assign a new ID to the document xxxx.sldprt and reset version back to A.1. Versions associated with the old ID will remain in the repository. Are you sure to proceed?"
Here's a video: -Nothing happens if I just use "Tools->Macro->Run..." or use the button "Run Macro". The MainForm shows up when I assign the macro to a button. Is it because there's a field for the method (Core.main) that cannot be specified otherwise? I lost a lot of time trying to find why the macro would do nothing as I was testing with a "Run Macro" button.
-When I "Step into" and then F8 repeatedly, I get in a loop here: -Where is defined the sentence "This will assign a new ID to the document xxxx.sldprt and reset version back to A.1. Versions associated with the old ID will remain in the repository. Are you sure to proceed?"
Re: Revision control app macro (release)
Sorry you lost a lot of time with this. We will find a way to fix this issue, I promise Okay, reviewing your video, I strongly suspect that the issue is that you have some foreign files in your Repo directory with names that do not match the convention expected by the macro: [trackingId]_[Version]_[FileName.SLDPRT]. I will add a check function to disregard such files so they don't cause this error. But just to make sure that this is the case, can you please do the following:
1. Edit the macro, and in Constants, change the line:
To
2. Run the macro again from the Core.main method, and try to create a new version or anything else that causes the "Subscript out of range" error. The macro editor should pop up with an error box. Click "debug".
3. Macro editor should pop into the function IsCurrentDocumentAlreadyInRepoWithDifferentFilename. Hower your mouse over the "fileName" variable, and it should show you the value of that variable, like in this screenshot:
If it does not match the [trackingId]_[Version]_[FileName.SLDPRT] convention... Then it means this is indeed the issue. Like I said, I can easily fix this, but I want to be 100% sure that this is what is causing the error for you
For future reference, since you're making quite a few changes to this macro, you can find things easier if you do a global search with Ctrl+F and set the search scope to "Current project":
Let me know the results of that first test. And thanks!
1. Edit the macro, and in Constants, change the line:
Code: Select all
Public Const DEBUG_ENABLED As Boolean = False
Code: Select all
Public Const DEBUG_ENABLED As Boolean = True
3. Macro editor should pop into the function IsCurrentDocumentAlreadyInRepoWithDifferentFilename. Hower your mouse over the "fileName" variable, and it should show you the value of that variable, like in this screenshot:
If it does not match the [trackingId]_[Version]_[FileName.SLDPRT] convention... Then it means this is indeed the issue. Like I said, I can easily fix this, but I want to be 100% sure that this is what is causing the error for you
Yeah, Tools->Run does not allow you to choose which method to run the macro from... Sometimes the macro "loses" the reference to which method is the default (entry) one, and I honestly don't know how to specify that. I can try to re-create the macro from scratch (copy over the code), maybe that will fix it. But for now, use a macro button, or run the macro from the macro editor by pressing F5 and then choosing the correct entry method (Core.main).mgibeault wrote: ↑Wed Nov 06, 2024 3:32 pm -Nothing happens if I just use "Tools->Macro->Run..." or use the button "Run Macro". The MainForm shows up when I assign the macro to a button. Is it because there's a field for the method (Core.main) that cannot be specified otherwise? I lost a lot of time trying to find why the macro would do nothing as I was testing with a "Run Macro" button.
This is a loop that traverses through all of your files in the repo directory, you probably have quite a lot of them, that is why it appears to get stuck. You can add a breakpoint after the loop and press F5 to run the macro until that breakpoint, it will save you a lot of time.
This is from AdditionalActionsForm:
For future reference, since you're making quite a few changes to this macro, you can find things easier if you do a global search with Ctrl+F and set the search scope to "Current project":
Let me know the results of that first test. And thanks!
Re: Revision control app macro (release)
Well, thanks to you!!!
That's certainly the problem, when I hover over "filename" it shows "231130-450.sldprt". So it's a file that was copied there without the macro.
I can enforce a "do not touch directly" policy to the Repo folder but I cannot guarantee it will be followed in the long term.
Edit: I cleaned-up the Repo folder and it works!!!
For the problem of the "Run macro", don't spend time on this. It's a problem with SolidWorks' implementation.
For editing the macro I copy the text into Notepad++. I can have 2 files side-by-side with synchronized scrolling. And it has VB code highlighting.
That's certainly the problem, when I hover over "filename" it shows "231130-450.sldprt". So it's a file that was copied there without the macro.
I can enforce a "do not touch directly" policy to the Repo folder but I cannot guarantee it will be followed in the long term.
Edit: I cleaned-up the Repo folder and it works!!!
For the problem of the "Run macro", don't spend time on this. It's a problem with SolidWorks' implementation.
For editing the macro I copy the text into Notepad++. I can have 2 files side-by-side with synchronized scrolling. And it has VB code highlighting.
Re: Revision control app macro (release)
Thank you for confirming, I thought that was it I added a check to disregard such files so you don't have to enforce that policy, but I suspect there is still plenty of ways to break my macro, I didn't include a lot of error checking because of how limited VBA is and how annoying it soon becomes to maintain a project of such complexity in that macro editor. I too sometimes use Notepad++ for refactoring, but still have to copy the code back over to the VBA editor afterwards... Visual Studio is such a relief to work in compared to this. Sad that we can't use it for writing and debugging macros.mgibeault wrote: ↑Thu Nov 07, 2024 9:20 am Well, thanks to you!!!
That's certainly the problem, when I hover over "filename" it shows "231130-450.sldprt". So it's a file that was copied there without the macro.
I can enforce a "do not touch directly" policy to the Repo folder but I cannot guarantee it will be followed in the long term.
Edit: I cleaned-up the Repo folder and it works!!!
For the problem of the "Run macro", don't spend time on this. It's a problem with SolidWorks' implementation.
For editing the macro I copy the text into Notepad++. I can have 2 files side-by-side with synchronized scrolling. And it has VB code highlighting.
Anyway, I will test that macro further for a few more days, maybe do some clean up and further refactoring, and then I will post it here.
Re: Revision control app macro (release)
Very much appreciated, it's very good work. It makes me doubt it would be really valuable to implement a PDM for our small team, your macro answer so many common problems in a very straightforward way.laukejas wrote: ↑Thu Nov 07, 2024 11:55 am Thank you for confirming, I thought that was it I added a check to disregard such files so you don't have to enforce that policy, but I suspect there is still plenty of ways to break my macro, I didn't include a lot of error checking because of how limited VBA is and how annoying it soon becomes to maintain a project of such complexity in that macro editor. I too sometimes use Notepad++ for refactoring, but still have to copy the code back over to the VBA editor afterwards... Visual Studio is such a relief to work in compared to this. Sad that we can't use it for writing and debugging macros.
Anyway, I will test that macro further for a few more days, maybe do some clean up and further refactoring, and then I will post it here.
Re: Revision control app macro (release)
No problem I never expected this little tool to gain so much popularity, after all, it does maybe 1% of what PDM does, if that. But I'm glad you find it so useful. I will post the v5 in just a moment.
Re: Revision control app macro (release)
If this had been available a few years ago I likely would have never purchased PDM. It appears to do most, if not all, of what our tiny engineering department needs from a PDM.
-
I may not have gone where I intended to go, but I think I have ended up where I needed to be. -Douglas Adams
I may not have gone where I intended to go, but I think I have ended up where I needed to be. -Douglas Adams
Re: Revision control app macro (release)
Okay, so after some extensive testing, I think V5 is stable, so here it is.
Release V5
Changes:
-The application will no longer automatically lock Released documents (make them read-only, lock external references and enable freeze bar), but will prompt the user by default. If you prefer to always lock these references (old behavior), or to never lock, edit the value of Constants.LOCK_RELEASED_DOCS_OPTION. As a result of this change, SET_RELEASED_VERSIONS_FREEZEBAR and SET_RELEASED_VERSIONS_LOCK_REFS have been deprecated.
-Additional Actions -> "Delete version history" was renamed into "Set new tracking ID", and the prompt rewritten to make it less confusing. The actual functionality did not change, but it should be clearer what this function does: it starts a new tracking history to the current document starting with revision A.1. Intended usage is when you save a tracked part with SOLIDWORKS Save As, and want to have a separate tracking history for this new file without deleting the old one.
-Renamed some variables, constants and functions.
-Some refactoring.
Bug fixes:
-Rewrote the sorting algorithm, added a few helper functions to Utilities. Should fix the "subscript out of range" issue.
-Added a check for the macro to ignore files in the repo that do not follow the [DocumentId]_[Version]_[FileName.SLDPRT] convention. Should now provide a proper error message rather than behaving unpredictably.
-Eliminated the confusing "the key is already associated with this collection" error. It happens when you save a tracked part with SOLIDWORKS Save As, but do not assign a new tracking number. The application will now recognize this, and warn the user.
-Fixed a bug where setting a new document tracking number (former "Delete version history" button) would not update the "Available versions" list, and it would still show the old file versions.
Hopefully I didn't miss anything serious. But nevertheless, if you find any issues, let me know, and I'll try to find some time among other projects to fix it And like I said before, if anyone wants to take on developing this further, feel free, I'm not holding any rights.
Release V5
Changes:
-The application will no longer automatically lock Released documents (make them read-only, lock external references and enable freeze bar), but will prompt the user by default. If you prefer to always lock these references (old behavior), or to never lock, edit the value of Constants.LOCK_RELEASED_DOCS_OPTION. As a result of this change, SET_RELEASED_VERSIONS_FREEZEBAR and SET_RELEASED_VERSIONS_LOCK_REFS have been deprecated.
-Additional Actions -> "Delete version history" was renamed into "Set new tracking ID", and the prompt rewritten to make it less confusing. The actual functionality did not change, but it should be clearer what this function does: it starts a new tracking history to the current document starting with revision A.1. Intended usage is when you save a tracked part with SOLIDWORKS Save As, and want to have a separate tracking history for this new file without deleting the old one.
-Renamed some variables, constants and functions.
-Some refactoring.
Bug fixes:
-Rewrote the sorting algorithm, added a few helper functions to Utilities. Should fix the "subscript out of range" issue.
-Added a check for the macro to ignore files in the repo that do not follow the [DocumentId]_[Version]_[FileName.SLDPRT] convention. Should now provide a proper error message rather than behaving unpredictably.
-Eliminated the confusing "the key is already associated with this collection" error. It happens when you save a tracked part with SOLIDWORKS Save As, but do not assign a new tracking number. The application will now recognize this, and warn the user.
-Fixed a bug where setting a new document tracking number (former "Delete version history" button) would not update the "Available versions" list, and it would still show the old file versions.
Hopefully I didn't miss anything serious. But nevertheless, if you find any issues, let me know, and I'll try to find some time among other projects to fix it And like I said before, if anyone wants to take on developing this further, feel free, I'm not holding any rights.
- Attachments
-
- Version control app V5.swp
- (590.5 KiB) Downloaded 42 times
Re: Revision control app macro (release)
Hey, be careful with such comments, DS might come after me for hurting their sales
Re: Revision control app macro (release)
I think it's because you constructed it with a module that is very easy to personalize and can be made to follow existing workflows.
One could hide a button or two and use it as a simple archiving/backup tool by saving versions into the repository as they go. Or go the opposite way and use the 3 levels of document control you offer, always with the choice of using wording that speaks to your team.