Userform Code "Best Practice"

[jallum]

Afternoon.
I've written the standard progress bar simple macro but I've moved all of the code from the userform page into a module page and changed it from private to public, as I repeatedly call the progress bar from multiple macros. Within each macro I initialize the bar, update its display in various loops as I require and unload the form at the end of the macro. Is there anything wrong with doing this? In all instances on the web on 'how to create a progress bar' the code is always within the userform page and the modlue page macros are called from within the progress bar macro. I'm asking as users of my macro workbook have told me that after they update the workbook and click the appropriate macro button the workbook sometimes hangs or takes minutes to complete. I've also been told to beware of Follina vulnerability attacks that cause macro issues, but my problem has been occuring since mid April and Follina apparently surface in mid May, and I've run out of ideas.

 

[6StringJazzer]

I don't see anything wrong with this based on what you've said so far but I'm having trouble understanding your architecture. How are you displaying the progress bar? I'm unclear as to how you are calling it from multiple macros, and what is the relationship of the progress bar to the userform.

 

[jallum]

Here's a simplified version of what I'm doing. Macro1 and macro2 call the progressbar. The userform only contains the object of the progress bas I had designed.
Does this help? if not I can attach the complete worksheet, but it's fairly large.

 

[6StringJazzer]

OK, so your progress bar is a separate modeless UserForm. What you are doing is actually a best practice, abstracting the progress bar as a separate component, rather than tightly binding it to another UserForm. Coding best practices sometimes include robustness against hacking attacks; I am not familiar with Follina vulnerability attacks and I suspect that your design choice here won't matter.

 

[RoryA]

IMO all the code you have in module1 really belongs either in the userform or in a separate class (the latter only really if you plan to use interfaces so that you can swap different types of progress bar in and out).

 

[jallum]

Thanks for both answers. I'm glad to know that my current layout is not a hindrance and I understand the reasons for keeping the code separate.

 

[6StringJazzer]

IMO all the code you have in module1 really belongs either in the userform or in a separate class

I agree with this, and did not scrutinize the code as carefully as I should have. I did not notice that your code was in Module1. The first two subs should be in the module for the UserForm that has the progress bar. Generally you should couple code as closely as possible to the object it manages.

The second two subs are OK there since they are clients of the progress bar.

However, I do not see a security issue in any of these approaches.

 

[6StringJazzer]

Oh, one other note. When showing code, it is almost always better to paste your code directly into a post, rather than showing a screenshot of code. That allows us to copy it into our own modules and compile and test as needed. Most people aren't going to type in code from a screenshot.

I also recommend code tags. After pasting in code, select the code and click the VBA button in the edit controls. This preserves the original formatting of the code.

 

[jallum]

Thanks. I had to mock up my question as the actual xlsb code is spread over 5 module pages and contains about 2000 lines of code, plus I'd have to post two workbooks that get ingested by this macro in order for you to see what is going on. I'll modify what I have to bring the progress bar subs back info userforms and see if that makes a difference.