I’m interested in having a macro available in a palette, but only during certain periods. Is this possible with a built-in, or should I be looking to some variable condition. Is it even possible?
So… A palette pops up when a certain window is visible, but only some of the macros in the group are available weekdays, and some on weekends, etc.
I’ll second this idea.
There is no particularly good way to do this and probably not much chance that I’ll add direct support for time limited groups or macros.
The most obvious way to do this would be to have a macro in the Global Macro Group triggered at say 6am (or at system wake) that enables/disables the appropriate macros in the macro group based on the DOW() function.
Alternatively, have two macro groups one for weekdays and one for weekends, and have that same macro above enable/disable those macro groups.
Interestingly, because Sunday is 1, and Saturday is 7, I cannot trivially recognize the weekend. I cannot do DOW() < 6.
I could do it with a switch, and have a separate case for each day, but then there would be tons of duplicate code.
Question: Other than the code looking a trifle cleaner, which is more efficient in KM, a variable match from the time (RegEx), or a numeric/integer comparison from DOW(NOW)). See below.
Here are some ideas:
(1) Just use the one action "If All Conditions Met...", and test for weekdays, then put the weekend actions in the "otherwise..." block.
(2) If you want to explicitly test for weekend, the use a similar RegEx:
Sat|Sun
Note that the use of NOW() could lead to unexpected results since it returns the date/time in GMT. I don't use it for that reason.
HTH.
DOW() MOD 7 <= 1
Very clever, Peter! 
And, DOW() is LOCAL time, right?
Yes, DOW() is local time.
So, you could do:
IF (DOW() MOD 7) <= 1
THEN do weekend stuff
OTHERWISE
Do weekday stuff
Nifty… But is that more efficient than the RegEx. I’m guessing we’re close now.
Anyway… I’m leaning towards RegEx and a Switch. When I used Morning Coffee itself certain sites weren’t updated more than a few times a week, and some weren’t useful on the weekends, and some were only useful on the weekends, so I need at least three cases, and Match Mon|Wed|Fri is pretty flexible, cost aside.
The approach I’m using is to use a Macro that triggers on ‘activation’ of Safari, and enables/disables Macros as necessary, then the Morning Coffee Palette shows what’s in the Morning Coffee group, and is enabled.
Testing proceeds.
They are both so fast it is irrelevant which you choose.
But it seems to the most efficient is IF ELSE rather than switch.
But again, both very fast, so choose what you prefer.
Absolutely. If you executed this macro a thousand times, the difference wouldn't be close to the time taken to write this response.
Don't waste much time wondering which one is faster. Instead, much better to choose the one that is either quicker to create, or more understandable (so easier to reuse and modify later).
I couldn't agree more. I have used this philosophy for decades.
I still remember the programmers who wanted to use assembly language rather than Fortran. There were a few rare cases where it was necessary, but most often it was not. I quickly learned that no one but the original programmer could maintain the assembly language routine, and even then it was doubtful after a few months. Sorry for the historical throwback.
I hear you, but leading programming teams today you see a lot of sloppy code. Guys counting on the compiler to make up for poor reasoning.
I remember the days when programmers were paid by how many lines of code they wrote in a day. Guess what kind of code you get with that methodology?
Anyway… It still concerns me, and I still try to do things the ‘right’ way, or one right way.
I’m actually going a completely different way on this macro. Now I’m looking at something that automatically cycles through the link list based on a keystroke.
Compilers cannot correct for faulty logic, but they can optimize the code far better than most programmers. Or put another way, it's usually not cost-effective to have a programmer spend hours and hours optimizing the code to make it run faster and required less memory when the compiler can usually accomplish most, if not all, of that.
Of course, if you're designing a procedure that will be in tight loop with thousands, even millions, of iterations, like reading everyone's email, then that probably changes things. 
The one thing compilers are no help on is catching/correcting bugs.
IMO, this is the great failing of many, many of today's programmers/designers -- pushing out public production releases that are far too buggy because of sloppy code, poor discipline, and failure to test properly.
BTW, I am very impressed with how fast and unobtrusively KM runs, given the scope of events it has to watch and process. And it does it all with very, very few bugs. Well done, @peternlewis.
Got something going. Works reasonably well.
Any comments, or ideas?