Posting macros with sub-macros: Organization and Conventions?

So I’m starting to use sub-macros more and more. Which means:

  1. I’m building a toolbox of routines.
  2. Which means if I want to post a macro example to the forum, and it uses sub-macros, I have to include them.
  3. Which means probably at least 2 macro groups will get imported into the user’s KM.

So my question is, is it possible for us to come up with some conventions for how to name macro groups that may get imported into other people’s KM?

Or is this not worth the effort? Or not even useful?

1 Like

Sure. Everyone use “Submacros”.

Easy. I’m not sure anyone actually will though, but one can dream.

1 Like

I’m already using “Sub-Macros” as both a Group Name, and as a suffix to all sub-macro names, as in:

[KM] DELETE List of KM Variables [SUB-MACRO]

That’s cool with me.

What about the [KM]? What qualifies for that prefix?

For macros that aren’t sub-macros or aren’t KM (depending on your answer to the above), is there a general macro group they should go in, unless they warrant their own group?

“[KM]” denotes the macro is used for working with the KM engine and/or editor.

I’m not proposing that that be used as a standard by all – it’s just my own naming convention. I generally do this. For example, my Evernote macros start with “[EN]”. These prefixes let me know at a glance what the main app/function is of the macro.

Perhaps the “[SUB-MACRO]” suffix is a bit “loud”. Maybe it should just be:
"[Sub-Macro]"

How’s this look:
DELETE List of KM Variables [Sub-Macro]

Some might object to my all-caps of “DELETE”. It’s just a personal pref. Change it to suit your needs/prefs.

I’m good with all that.

Initially I didn’t like the [KM] prefix, but it seriously grew on me to where I prefer it now. Don’t know that it’s needed for other groups of macros, but for the KM manipulation ones, I likey.

I personally wouldn’t use all caps for DELETE, but I get where you’re coming from and as you said, it’s easily changed if someone doesn’t like it.

You didn’t comment on other macro group names. Any thoughts?

PS: I like standards. If they develop because someone initially chose something, and it doesn’t totally suck, I’m cool.

I haven’t given this a lot of thought or organization, but generally, the Macro Groups are named:

  1. For the app in which it is available, like “Outlook”, or “Evernote”
  2. Special Function/Use Groups:
  • Test
  • Examples
  • Browsers
  • Palettes (one group per palette)
  • OLD (don’t use, but don’t want to delete yet)
  • Sub-Macros
  • Templates (disabled)

Nothing super-special about any of that. It generally works for me (although the list is getting too long), and may or may not work for others.

I do wish KM Editor would support sub groups, at least to one level. But I realise that is not a trivial matter to implement.

If anyone has a better approach, I’m all “ears”!

OK. I’ve got a new set of macros that I will hopefully be ready to upload today or tomorrow. When I get them organized, I’ll hit you up and see what you think. And yes, I realize your word is not law, but two brains are (sometimes) better than one.

Right there with you. On both counts.

1 Like

Hey Guys,

I actually like it when I import something and it loads up in a group that is different than any of mine. That makes it easier to identify what’s been imported and to get rid of same when I’m done with it.

If I export a mess of things to be imported to someone else’s system I will usually add a .ccs suffix to any not very unique group names to prevent pollution of their macro hierarchy.

-Chris

That’s an interesting idea. If everyone would (temporarily) add their iniitals (or ID) as a suffix to the Macro Group prior to export/upload, that would help everyone identify the Macro Group & Macros when they imported it to their system. This would retain the Macro Group criteria. After the upload, then we could remove the suffix from our system.

So, for me, that might be:
Outlook.JMTX

Then the user would know that any macro group with a suffix of “.JMTX” came from me.

Hey, I like this idea! Let’s do it!

@JMichaelTX and @ccstone - How about a prefix of initials rather than a suffix? That way, when someone imports something of yours, it all sorts together in KM. It can be difficult to find things in KM, sometimes.

What do you think?

I prefer the suffix. The user can search on the suffix to find those groups.

By using a suffix, I can actually just leave the suffix in place in my system without any adverse effects.

What kind of adverse affect would using a prefix have?

Changes the sort order of macro groups.
Puts info first that I generally don’t care about.

Got it.

Here’s a related topic I just posted that some of you might be interested in:

1 Like

I prefer prefixes because:

  1. I would prefer not to have to distinguish groups with a common prefix, because that’s not so easy to do at a glance,
  2. I would not want the group inserted into my own sequence of macro groups

Personally, I have defensively preceded all my own macro groups with special, sometimes funky, characters both to separate out imported groups (or macros into existing groups (such as Global Macros Group) and to impose a logical grouping of groups — for example,all application-specific groups begin with the two characters "□ ". But few people will do that, so groups with sufficed names will be interleaved with their own groups.

Me too, my list is getting a bit long and takes some scrolling. Even just a folder to put them in if possible.

I was just about to post the same thing, I too like it when they go into a group name I don’t already have. I feel the same way about the Variables and clipboards and recently purged several clipboards from other macros I had imported to learn from.

That is very kind of you though I rarely ever find myself deleting anything you post.

I will try to do that too.

I am probably reading this wrong but it sounds like you would prefer a suffix. I am down with a prefix just so it purposefully doesn’t get mixed up with macro names I have but suffix is just fine too since I can always search if I know I have imported macros from someone. Plus that is already being implemented by Chris.

I wish I had more time to spend on the forum learning from you guys (so I could save time automating tasks LOL).