I have a use case for opening large workbooks and needing to calculate all formulas. From what I can tell, using the workbook Calculate function only executes in a single thread. I recognize the complexity with calculation dependencies, but for simple cases (many independent formulas), this means calculation will be much slower than in Excel itself.
Am I missing something here? I couldn't find any other references to this question; the closest match I could find was some enhancements to allow multi-threaded writing of workbooks via the packaging API, but nothing about calculations.
Related
I've been applying VBA at work for a number of purposes. I have noted the more 'clicks' a user has to do for a form (with a number of macros), the higher the rate of error. I was wondering rather than having 3 separate functions requiring 3 separate clicks - should I bunch all these functions together into the one sub module for ease of use?
Clinical staff have indicated that this would work best with them, but in terms of code optimization and keeping different functions separate - wouldn't it make things very messy? As I'm still in the process of learning VBA, I thought I'd turn to the expert community which has helped me out a lot so far.
I'd appreciate any and all comments regarding your thoughts on this and how I can create best-practice VBA standards to adhere towards.
An example of this would be the static copy function I have created and the monthly Calculation function. For the monthly calculation to be completed it pulls data from a summary tab and compares this against the static data. However for the static data to first be captured - the user needs to click the static data macro. I've separated the static snap-shot function and the monthly-report function but was wondering if I could instead combine both of these into one function. Readability wise it's not problematic (as I have the comments explaining each section) - but standard wise, would it be unwise?
I apologize if this question is somewhat broad in nature.
After reading around a few forums I've picked up the following information:
Do not use global variables unless you have a specific reason to do so
Don't forget to initialize variables else you may run into sub-script errors
Keep your code simple (iPhone Approach - one click approach)
If modules are similar consider grouping the functions together into one
Macro recorder is your friend
Thanks for the tips everyone!
I want to understand how the interdependent excel formulas are calculated specially I am interested in the order and process
Simple example
e.g. I have two formulas in excel spreadsheet,
cell A4 contains =SUM(A1:A3)
cell A5 contains =Round(A4)
I am assuming A5 Waits until A4 is calculated and that's somehow tracked and implemented by excel internally.
Is my assumption right?
I wanted to get a better understanding of this "somehow"
May be excel uses some dependency graph , is threading involved? etc. anything that helps me understand!
The motive behind the question is, I have an Excel-Addin from some third-party software and the formulas I used in the sheet makes me suspect that each cell is waiting for other to execute first hence going into a lock state.
Excel builds a dependency tree and walks through it calculating each cell in the order you would expect. However, since there can be circular references it may do multiple passes until nothing changes (or the change is very small). The max passes is controlled by the "Iteration" setting.
In Excel 2007 and greater, there is support for multi-threaded calculation.
For your simple case where there are no circular references, most likely the third-party addin is doing something funky if Excel is freezing. Here is an MSDN article describing the calculation process in detail: http://msdn.microsoft.com/en-us/library/office/bb687891(v=office.15).aspx
Why excel? Well excel is what is used to import the player salaries.
Now I need the spreadsheet to do the following.
Create teams within salary cap.
Include/exclude specific player function
Build multiple lineups from a selected list of players within the cap
Can I do all of this with excel? or do I need to know excel vba as well?
Also which parts of excel or if necessary excel vba must I need to know to code such a thing? Also if someone could give me a short summary of the steps needed to hypothetically make such a thing it would be great. Thanks.
I'm posting this as a reply because it is too long for a comment window.
Just because Excel has a grid doesn't mean that it is fit for data storage and data handling, on the contrary.
What you typically want to do is create a transparent structure that guarantees the integrity of your data and that allows dynamic portability when needed one day.
Excel is meant to be a spreadsheet, people forget this all the time or they just avoid the topic: although Excel has a grid, doesn't mean that it is a good fit for reliable data storage. It is not even the least complex way of storing data, depending on the amount of VBA that you need to manage all these data and the gates that you unnecessarily open towards potential bugs.
This is why an RDBMS is what will fit your needs, in this case Access would be a good option as it preserves your data integrity if you get the table structure right and it executes a lot of tasks for you that you should otherwise need to program yourself to protect the integrity of your data.
Although you can perform SQL on spreadsheets too, note that Excel does NOT cover related tables (what you typically seem to need for building your teams and salary limits), so what many Excel programmers will typically do is to create their own code to make this cross-table data storage thing work.
Don't do this if the alternative is available and much more reliable and future-proof.
At first sight, it seems that you won't even need any VBA; I'm not sure of all the things you want to do, but my first impression is that you can manage everything with SQL syntax and stored queries in MS Access. You can import Excel sheets into Access if you get their format right so that should not be a problem.
Once your data is stored there, rest assured that you have made your life a lot easier.
Suppose you have an Excel workbook and you need to write a macro that takes inputs from many different cell references, and updates values at many different cell references, how do you keep the code neat and maintainable?
It would be helpful to know:
best practices
useful tricks
unavoidable difficulties
necessary trade offs
If there are links to existing guides or discussions that would be helpful too. I haven't been able to find any.
Edit: I found http://www.eusprig.org/best-practice.htm very useful - from the European Spreadsheet Risk Interest Group (EuSPRIG).
It slightly depends om what the macro is going to do, but I use 'calculation' sheets, where I gather together the data I need for the macro, and output the results there.
I tend to do this do in defined ranges.
The result data can then be referenced from elsewhere.
Tricks: One thing I do is to create a visual 'check off' for each piece of input data as it's used. This just enables me to make sure that all the data I thought I was going to use, I have used.
Following Naming criteria is better solution , irrespictve of language.
in_name_range, out_name_range
in_num_range, out_num_range
Check points and adding watch , would surely help.
If you are going for modularity, Take care about updated ranges
(As you can't return more than one value at a time better write ranges in some predefined order in some sheet. This works for me.)
While implementing a macro via Visual Basic Editor, i got an error "Compile Error: Procedure Too Long".........i wanted to know why is there a limit to the size of the macro and is there any way to increase the allowed size. My macro is pretty big (based on around 150 different cases) and because of this error i will have to divide the task among 8 macros approximately. Is there anyway around it?
Will appreciate your help.
You can speculate on the logic for limiting the text size of a subroutine - maybe they don't think it is necessary to have subs that long - maybe they gain some slight performance boost by doing it - maybe it is just a purposeful limitation to prevent people from recording ridiculously long macros. But in any case it is probably better from a scripting/programming perspective to not have monstrous subs anyways. And with loops you shouldn't need to have subs with that much text in them. So my hypothesis is that they wanted to prevent people from relying on recorded macros when it would be better and more efficient to use loops. But it's just a hypothesis. Good Luck.