Macro 3.7
Karoline Oum
You have the option to run only the currently selected code (Run > Run selected code in the Script Editor). However, depending on how complex your macro is, this will not work with for loops and/or with any declared variables.
In general, the solution to this dilemma is robust error checking. Where the macro gives an error and stops, you would add some if statement on the line before checking for the condition proactively, and then prompting the user to redraw their region again until they draw a usable one.
I have a Excel macro that copies a specific sheet from the source workbook to a destination workbook, both are on SharePoint. The macro resides on the destination workbook. I wanted to create a scheduled flow to run the macro every business day but I'm having some issues.
My Power Automate version does not have "Run Excel Macro" action, so I am trying to use "Run Script" action which appears like it can be used to trigger a macro and not just a Office Script, and in the script field I tried a few things but it keeps giving the error that it's a Bad Request - unable to parse script reference.
I tried the following naming conventions for the script field:
Daily Orders!Module1CopySheet (without the dot)
I even tried copying/pasting my entire macro to the script field but to no avail.
Can someone please advise on how I make this happen or if there is alternative method to run this routine job?
@coolbeans23
I've had all sorts of suggestions from AI - its still hit and miss. I'm not an expert on macros so someone else might be able to help re coding scheduled macros or Windows Task Scheduler. Or have a google.
Hmm....two different AI's said you can run Excel macros from Power Automate on cloud (they could possibly be wrong) using "Run Excel Macro" or "Run Script" action (which I only have the latter in my version). I don't have Office Scripts.
Perhaps I can fill you in on more detail, the source workbook has a specific sheet that is connected to a database and displays data where some needs to be corrected, a user remediates any incorrect data in the database then refreshes the Excel sheet to see their changes reflected. My goal is to capture changes to the data for each day of the month to see what has been corrected (if any). My destination workbook has a macro that makes a static copy version of the sheet from the source workbook and creates a new tab with the current date i.e. Orders 4.20.2024, Orders 4.21.2024, Orders 4.22.2024, etc. I just need an automated way for the macro to run every business day at 11pm (even if my computer is shut down), so I thought Power Automate could help accomplish this.
I guess this is about the SPM distributed version? There is a bundled with the XCode's toolchain prebuilt version: /Applications/Xcode15.0b5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/host/
The SPM-distributed version is what Xcode 15's macro template uses, and there's no way to simply import SwiftSyntax from Swift right now otherwise. One of my questions above less directly asks if this is to change by release.
Huh, I guess you're right. I've found this in the example repo, but it seems like this approach has been abandoned, according to this commit.
Also I've found out that the toolchain for linux doesn't contain prebuilt SwiftSyntax for some reason.
Sorry for misleading.
On #2) It would be great to see it standard practice to import the package corresponding to targeted Swift language version. If you are targeting Swift 5.9 then use the 5.9 branch of swift-syntax. There is nothing stopping that now, but SPM isn't great at detecting updates to a branch.
I think it would be great to include the recommended version for each Swift language mode as a shared library with Xcode to speed up compilation. Just don't include it as a dependency if you want to use the Swift built-in version. I think a shared library would only be available to macros or build plugins and not other uses of swift-syntax.
Seems like auto importing the version corresponding to the Swift version in the package would be a good first step. Then allow an override of that auto import with some sort of manual version so people can track development versions.
Yes, that is cost of building a macro at the moment and unfortunately I don't have any suggestion of how to improve this situation at the moment. Installing swift-syntax into the toolchain will only work in cases where that installed version happens to match the one that SwiftPM resolved, which won't match if we need to create a patch release of swift-syntax or the Swift 5.10 compiler is used with swift-syntax 509.
I have just composed an article that describes how macros should adjust their versions when updating to a new major swift-syntax version: Add an article that describes how macros should be versioned when updating their swift-syntax dependency by ahoppen Pull Request #2024 apple/swift-syntax GitHub. Let me know if that answers your questions. The TL;DR is: Update the minor version of a macro when updating its swift-syntax version dependency.
swift-syntax has matured significantly over the last few months, the main driver being the drastic increase in our user base from macro authors. This has involved a significant number of rapid changes, with the goal of delivering a solid release alongside Swift 5.9. The latest changes you comment on are due to Significant changes in the latest swift-syntax 509 prerelease, which we decided to land now to reduce the churn of the Swift 5.10-aligned release of swift-syntax.
We are anticipating that swift-syntax's API will become a lot more stable after its Swift 5.9-aligned release, though there will always be some API breakages in swift-syntax as the swift language itself evolves. We will do our best to mitigate these changes through API deprecations, which we have already been doing between the latest snapshot releases.
The swift-syntax repository contains a couple of examples that are guaranteed to always be up-to-date by a CI job. We'll also incorporate @Douglas_Gregor's list of example macros into there as well (#2026). Similarly swift-format is a sizable client of swift-syntax that's always compatible with the latest swift-syntax release. Beyond these, are there any particular examples you think are missing?
With the two WWDC presentations on macros, Expand on Swift macros and Write Swift macros I think we have two good ways of getting started with macro development. swiftpackageindex.com allows browsing the swift-syntax API and swift-ast-explorer.com allows interactive exploration of the syntax tree. I agree that it would always be good to have more documentation, but I think we aren't in a terribly bad spot at the moment. If there's anything you feel is missing, pull requests and/or issues are always welcome.
I have just composed an article that describes how macros should adjust their versions when updating to a new major swift-syntax version: Add an article that describes how macros should be versioned when updating their swift-syntax dependency by ahoppen Pull Request #2024 apple/swift-syntax GitHub . Let me know if that answers your questions. The TL;DR is: Update the minor version of a macro when updating its swift-syntax version dependency.
It sounds like the answer to "how do you support multiple versions of Swift at once?" is "you don't". Updating to 510 requires dropping support for 509, and failing to upgrade means you block updating other packages which have upgraded. This isn't a problem in the short run since of course only 5.9 will be the only version of Swift with macros for a while, but it really isn't a viable long-term answer.
@tgoyne already responded with my main unanswered question, which this guidance unfortunately doesn't help with. It's impossible to version a library by minor release this way and support multiple versions of Swift at the same time. Major versioning by Swift release (508.x, 509.x, 510.x, etc.) is a more flexible solution, and certainly works for executables like swift-format, and macro libraries that simply ship a macro and do nothing else, but this doesn't seem to be a feasible option for more general libraries that happen to ship macro-based APIs. More general libraries have the goal of supporting multiple versions of Swift at the same time while also iterating on their own features and APIs, and these libraries need to be able to introduce major, minor, and patch versions outside of Swift releases and swift-syntax versions, so I think we still lack guidance on how to handle this common use case.
This is precisely why an example library would be nice. While it won't be possible to show a macro that supports multiple versions of Swift concurrently till 5.10 is available, we could have a demo that shows how a more general library can use SwiftSyntax and ship versions that are compatible with several versions of Swift.
I have a workflow that calls a batch macro to run through multiple store locations and exports an excel file with a sheet for each store (The sheet name is also controlled by the control paramter that is being fed in).
I think the issue is that your macro has an output that isn't going anywhere. As such, it stops running because it doesn't think the data is needed anywhere else.
If you try removing the Macro Output, what happens?
Can you help me understand tho, as to how how come when I ran it as a workflow, I can leave the output icon there and it will be fine, but once I run it as an analytic app, I have to remove the output button?
Since Alteryx has an engine that focuses on optimizing workflows, it builds out an execution plan each time it runs the workflow. In doing so, it tries to improve performance wherever possible, cutting out things that aren't needed. Another example of this is if you use a Sample tool immediately after an Input data tool and bring in only the first record, Alteryx will stop reading in records after that point, saving you from loading a bunch of extra data you weren't going to use anyway.