Chaining Macros A - B - C vs A - B - A

Hey folks,

I’ve been moving away from my initial unwieldy, single-use-case macros built with zero planning or process mapping and completely unrecognizable in the morning toward more interchangeable parts.

I now notice many of my macros are like this: MACRO A serves a pretty specific use case and includes quite a few action steps. Then it passes a parameter to the much smaller, more generalized macro B, which does a thing with that parameter, and then, since there is more to do, I tend to pass the baton back to A for more use-case-specific actions.

So, it’s kind of like A->B->A but really it’s
Part of A->
All of B->
The rest of A.

This strikes me as potentially problematic for some reasons I can’t quite get my finger on. I’m wondering if more experienced folks here take more of this approach:

all of A ->
all of B ->
all of C.

Because If I’m using A --> B --> A, it feels like I’m actually using AX --> B – AY. My Macro A is actually Macro AX and Macro AY smashed together and depending in weird ways on B for completion.

run AX ->
run B ->
run AY

That seems inferior to A->B->C to me, intuitively, but I don’t have real basis for thinking that.

Part of my concern and interest in doing this in the most effective way probably stems from a prior startup role I held where our youngest engineer was pushing hard for refactoring toward modularization and our old guard of .net developers were very sensitive about the code base, which could only be described as a rat’s nest (as is normal for a fast growing startup with no technical founder). I tend to prize flexibility and don’t know what I’ll be doing or what the customer will want in a few months, which means modularization is a better investment of time – I think. But I’m curious as to other views on this.

Some theoretical point exists where there are diminishing returns in modularization regardless of the question of how valuable they are. I’m curious what the folks in this forum who have the most experience with KM aim for.

Also curious to understand how KM relates to other programming approaches, as using KM has brought me into a certain comfort level with programming very quickly, and resulted in my using the BASH and loving it, when I didn’t have any idea what a command line was even theoretically good for a couple months ago, and also have been actually interacting with APIs directly for the first time ever. I think this product is enormously valuable as a tool for teaching programming. I’ve personally spent a lot of energy trying to “learn to program” with flashy online services, most of which focus on things that have no utility; KM is the thing I’ve learned the most from, along with Google sheets (due to their constant just-in-time help prompts) and Zapier (api connector tool) – all programs that don’t, ostensibly, teach people to program (:

Love it! So well stated. We've all been there (some are probably still there).

The method you describe as A->B->A Is actually pretty good, for the most part. "B" is a subroutine (or Sub-Macro as we've taken to calling them around here).

What you want to do is break apart chunks of code that are reusable, and place them in sub-macros. You pass parameters to them somehow (if needed), and get results back (if needed). Here's an extremely complex example from what I'm currently working on:

By the way, I don't necessarily recommend my naming scheme here. I'm trying it out. The point is that I have multiple sub-macros. Most of them get called more than once, but a couple of them are there just because I thought I might want to use them again.

You can pass parameters in and out of sub-macros in many ways. My preferred method, when possible, is to use the "with parameter" option of the "Execute Macro" action. If the sub-macro only requires one input parameter, I put it there (you access it via %TriggerValue%). If, on the other hand, the sub-macro only returns one parameter, I'll pass the NAME of the result variable, and return the result like this:

This effectively places the result in the variable whose name was passed as the parameter.

I've also been known to pass multiple parameters, separated by tabs ("backslash-t"), and parse them out in the sub-macro, but I think that's me over-engineering things.

I could go on forever, so I'll stop here.

Ask questions. Disagree. Whatever - now's the time to figure out what works best for you. I look forward to hearing (reading) your comments.

Well, I would start with by saying that the advice given to you by @DanThomas is some of the best you can get.

To directly answer your question, I would say that KM is actually quite different from other programming languages.
Peter has described it as "a visual programming language", and I would agree with him.

I think the intent, for most users, is a point, click, drag and drop approach to building some simple steps to help you automate some aspect of your environment.

If you find the need to automate a more complex workflow, then I would probably suggest the following:

  • Build separate macros for each major block of your workflow.
  • test each of these macros until you are confident that they work as you desire
  • then you can combine each of the macros, either by creating a new macro, which calls each of these macros, or copy and paste each of the macros into one large macro.
  • this will make it much easier to test and debug each part of your workflow.
  • The other case for building a separate macro, is if you have a separate small workflow that will be repeated often by This macro/workflow or by other macros

If you are a programmer, like Dan, and myself, then you'll have a tendency to separate out each separate functionality into a separate macro. This can be a distraction, and may or may not be necessary.

This is a great discussion, and please feel free to ask any further questions, or challenge any assertions that I may have made.

LOL. To say the least.

Yes, KM is not the same as "normal" development, and I've discovered that I'm changing some of my usual ways of doing things.

For example, I'm actually breaking things into sub-macros LESS often than I would with regular development. Normally I would break things apart for clarity's purpose. But with KM's groups, colorings, and the ability to collapse or expand things as needed, I'm creating some macros that I would run away from in a normal development environment.

Bottom line is, I agree with what @JMichaelTX said: The main purpose of KM is to tackle specific tasks, not necessarily to build extensive libraries. Use sub-macros when they're needed, not when you think you should use them.

With that said, there's nothing wrong with building extensive libraries, right? What else am I going to do with my time? :stuck_out_tongue:

1 Like

I just had a similar question this week too, some great people on this forum!

Great, thanks for the response folks. Helpful thoughts and sorry I’m always going to be in and out of the forum less than regularly (if I’m here more than that maybe somebody can tell me to get back to what I should be doing…).

For whatever reason, after a lot of effort to understand programming via online programs like CodeAcademy, KM taught me programming concepts so quickly and so easily it just causes me to be really interested in where the ideas underlying this program sit relative to others in computer science.

I had this realization using KM that computers are basically like the wild inventions I used to chain together as a kid to get my light to turn on when [sister snuck into my room / mom opened basement door to tell me I was late waking up / etc] and I just never understood that before. This realization somehow lead me to the command line and nnow I’m finally, finally! actually writing scripts that successfully connect to the services I have been using online to do the same sorts of daisey-chaining things (Zapier, IfTTT, and the myriad applications with really great documentation and APIs like Slack, Trello, Twilio).

This all adds up to being able to actually build prototypes, finally, that I don’t have to hit a button to trigger manually.

It’s been a good investment of $36 or whatever it was.

1 Like

LOL. Glad you’re having fun. For some people (myself included), development work is the most fascinating thing in the world.

I’m 59, and I’ve been programming since around 1972. I’m retired now (yay me!), and I’m spending more time in front of my computer, programming KM stuff, than I ever have. Well, that may be hyperbole, but you know what I mean.

Several observations come to mind as I have learned more about scripting and macros. First I was trying to figure out a way to scan my documents into Filemaker. I figured it out but along the way I discovered that I could get things into Neats database and it would automagically OCR items and also provided additional ways to export my data. This ended up replacing ShoeBoxed as my paperless office strategy. To me it made more sense and was more efficient to use a tool already created. Especially since it was superior in a couple of ways and for me to match it I would have had to do a lot of programming in Filemaker Pro.

Then I started working on my bank statements macros project. Not too long after I started this second leg of the journey, I soon discovered that Mint could download all statements for me. The tradeoff would be their being able to see all my statements or someone else might. So I continue to work on download scripts not so much because I want to use them but because of what they teach me.

Getting to the 'observations' part. As time passes many of the things I have wanted to do start showing up in services that are offered, such as IFTTT. Banks are finally offering choices they long ago should have offered. (For example why can't you request that your bank send you all your statements without you having to ask for them? Or why can't they automatically put them on a storage server of your choosing, such as dropbox or your own SFTP Server?) We are living in the Jetson's era and they are operating like the Flintstones. Primitive. Why do we sit on a phone waiting for support when we already have technology that would allow us to notify them we need help and the call would be returned by an automated system at a time of our choosing that was during a reps scheduled shift?

My observation is that often the solutions we seek are getting handled by someone else somewhere and it's happening exponentially faster and faster every day. Often when I search for information or solutions on Google, I may return a week, a month, a quarter later to perform the search again to find hundreds of new solutions that weren't available before. We are in the "Wild, Wild, West" era of information yet it's coming together in ways we haven't even conceived of yet and some ideas immediately kill others. (Imagine what self driving cars will do to insurance?)

And @skillet you are right. There are some excellent people in this forum. Much, much different than other forums but I have learned that coding forums tend to be that way. It's truly amazing the way coders share code, or how they arrived at solutions.

It is, isn't it. Hadn't really thought about it that way, before.

I mean, where else would you see something like the Open Source movement become so popular?

Got point.