VBA in Excel
-
Good Tips '489 ! Writing add-ins seems to be the only way to automate Office 365. It is becoming the corporate office platform in a lot of places so indeed MS has done a Ripley on us corporate software developers. If you do have to work in VBA -there are many toolsets to help write and maintain good code - MZ tools is my preference but Rubberduck · GitHub[^] looks good too. Its an old but stable IDE -little Intellisense, no autocompletion - but that only helps the coding - not the thinking! Export all your code modules, forms, spreadsheet content, formulae, formats to text files. Then you can do version control in mercurial, and inspection in Npp Merging is an issue but you can see what changed and revert or branch.
-
In the Microsoft Tech community, there is a feature request to add support for Python as an Excel scripting language : python for excel application scripting - Microsoft Tech Community - 66113[^]
:doh:
cheers Chris Maunder
-
I decided that, instead of manually categorising a bunch of values in a spreadsheet I'd write a simple VBA method that would do the hard work for me. After all, doing it manually would take about an hour. Writing a bit of VBA couldn't take more than... well, I think I'm on hour 5 at this point. It's been a long time since I've done VBScript, but even VBScript was generally fairly sensible. VBA? I can't believe it's 2020 and VBA is pretty much the only scripting option available in Excel. Sure, you can write add-ins using Javascript and in-cell formula using Javscript, but no Javascript scripting. No constructor, serious hassles passing user defined types between methods, a limit to the number of times you can use line continuation in a row, the awful experience overall. I can't believe how much of the world lives and breathes this stuff. (but of course I'm going to bash my way through it instead of just getting the job done the old fashioned way)
cheers Chris Maunder
Why not generalize it and write a plugin? Then you can play DLL-Hell with every machine that needs it. Of course, if it only modifies and fixes the cells for you, then one machine is all it will take. Pity me, I once opened the xlsx file and looked at modifying the cells directly. I backed down, and did it the old fashioned way!
-
I decided that, instead of manually categorising a bunch of values in a spreadsheet I'd write a simple VBA method that would do the hard work for me. After all, doing it manually would take about an hour. Writing a bit of VBA couldn't take more than... well, I think I'm on hour 5 at this point. It's been a long time since I've done VBScript, but even VBScript was generally fairly sensible. VBA? I can't believe it's 2020 and VBA is pretty much the only scripting option available in Excel. Sure, you can write add-ins using Javascript and in-cell formula using Javscript, but no Javascript scripting. No constructor, serious hassles passing user defined types between methods, a limit to the number of times you can use line continuation in a row, the awful experience overall. I can't believe how much of the world lives and breathes this stuff. (but of course I'm going to bash my way through it instead of just getting the job done the old fashioned way)
cheers Chris Maunder
As a fairly serious Access programmer, I feel your pain! The one complaint that I don't endorse, though, is about the limit on consecutive line continuations, which I must say I have never run into. On the whole, I feel that if you have to continue a logical line over more than a couple of printed lines, you should break up the logic, since it is likely to be difficult to understand if/when you come back to it later, let alone by anyone else!
-
As a fairly serious Access programmer, I feel your pain! The one complaint that I don't endorse, though, is about the limit on consecutive line continuations, which I must say I have never run into. On the whole, I feel that if you have to continue a logical line over more than a couple of printed lines, you should break up the logic, since it is likely to be difficult to understand if/when you come back to it later, let alone by anyone else!
With regards to the line continuation issues, what I'm trying to do is create a an array (an ever growing array!) of terms that can be used to categorise an item. eg
items = Array("item1", _
"item2", _... "itemN")N, for me, has grown beyond the limits of what VBA likes. What I probably should do is just enter the terms in the spreadsheet somewhere and have the method reference the values in those cells rather than hard coding. I've well and truly burned through the 1hr I budgeted on this one
cheers Chris Maunder
-
With regards to the line continuation issues, what I'm trying to do is create a an array (an ever growing array!) of terms that can be used to categorise an item. eg
items = Array("item1", _
"item2", _... "itemN")N, for me, has grown beyond the limits of what VBA likes. What I probably should do is just enter the terms in the spreadsheet somewhere and have the method reference the values in those cells rather than hard coding. I've well and truly burned through the 1hr I budgeted on this one
cheers Chris Maunder
Understandability isn't an issue, then, but I think you are right about what you should do. When I have the same sort of issue in Access VBA, I generally create a new Table (if the 'array' is likely to be needed again) or Recordset (if it isn't), which is pretty much the Access equivalent of entering the terms on the spreadsheet in Excel.
-
With regards to the line continuation issues, what I'm trying to do is create a an array (an ever growing array!) of terms that can be used to categorise an item. eg
items = Array("item1", _
"item2", _... "itemN")N, for me, has grown beyond the limits of what VBA likes. What I probably should do is just enter the terms in the spreadsheet somewhere and have the method reference the values in those cells rather than hard coding. I've well and truly burned through the 1hr I budgeted on this one
cheers Chris Maunder
Yet another case of someone using excel as a quasi database. It should have just been done in Access in the first place. I, too, have done a lot in Access VBA - easy when you know how. The problem I've found in Excel VBA is that they named most 'things' differently. I haven't done any VBA for Winword, but the same issues probably arise. No doubt that different teams did the initial design for each program.
-
Understandability isn't an issue, then, but I think you are right about what you should do. When I have the same sort of issue in Access VBA, I generally create a new Table (if the 'array' is likely to be needed again) or Recordset (if it isn't), which is pretty much the Access equivalent of entering the terms on the spreadsheet in Excel.
-
Yet another case of someone using excel as a quasi database. It should have just been done in Access in the first place. I, too, have done a lot in Access VBA - easy when you know how. The problem I've found in Excel VBA is that they named most 'things' differently. I haven't done any VBA for Winword, but the same issues probably arise. No doubt that different teams did the initial design for each program.
Sorry, but it shouldn't have been done in Access in the first place. This is a spreadsheet I'm working on, and it includes text, formatting, multiple worksheets and it needs to be approachable and usable by a non-developer. The categorisation part is a minor, minor part of this. I'm not a fan of changing the problem to suit the tools. I choose the tools to suit the problem.
cheers Chris Maunder
-
Sorry, but it shouldn't have been done in Access in the first place. This is a spreadsheet I'm working on, and it includes text, formatting, multiple worksheets and it needs to be approachable and usable by a non-developer. The categorisation part is a minor, minor part of this. I'm not a fan of changing the problem to suit the tools. I choose the tools to suit the problem.
cheers Chris Maunder
-
Then I apologise for my assumption. I agree with your statement - choose the right tool for the job.
I think the hardest thing for us is realising that sometimes we shouldn't write an app or dive into the technology 'just because we can'. What I should have done is looked for an online service that does this and just used that instead. I'd be done 4 days ago. We had a big meeting this afternoon about this: balance the ease and fun - and fairly hefty price tag - of writing solutions ourselves, vs paying the money and using something pre built that, if you actually do the suns, will be way way WAY cheaper in the long run. But coding is a drug.
cheers Chris Maunder
-
I decided that, instead of manually categorising a bunch of values in a spreadsheet I'd write a simple VBA method that would do the hard work for me. After all, doing it manually would take about an hour. Writing a bit of VBA couldn't take more than... well, I think I'm on hour 5 at this point. It's been a long time since I've done VBScript, but even VBScript was generally fairly sensible. VBA? I can't believe it's 2020 and VBA is pretty much the only scripting option available in Excel. Sure, you can write add-ins using Javascript and in-cell formula using Javscript, but no Javascript scripting. No constructor, serious hassles passing user defined types between methods, a limit to the number of times you can use line continuation in a row, the awful experience overall. I can't believe how much of the world lives and breathes this stuff. (but of course I'm going to bash my way through it instead of just getting the job done the old fashioned way)
cheers Chris Maunder
Yeah, I've just written VBA code to validate "date ranges" in Excel, i.e. a range with year, month, and day cells. It also has to identify date ranges based on the year cell containing a validation list. It's an unholy, un-OOP, mess, and working in that bloody VBA IDE is really a big step down from VS 2019.
"'Do what thou wilt...' is to bid Stars to shine, Vines to bear grapes, Water to seek its level; man is the only being in Nature that has striven to set himself at odds with himself." —Aleister Crowley