The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,917 other followers

Archive for October 19th, 2017

Mikrotik Router OS 6.37.1 – scripts and schedules – what policies they need to run

Posted by jpluimers on 2017/10/19

minimum schedule and script policies: read/write/policy/test

minimum schedule and script policies: read/write/policy/test

A year later, Mikrotik still needs to update their documentation, so from my question at [WayBack] [Mikrotik follow-up needed] Router OS 6.37.1 Рscheduled script cannot execute script РMikroTik RouterOS.


  • use the same policies for scripts and schedules
  • use these policies as a minimum for scripts and schedules:
    • read
    • write
    • policy
    • test

Forum post:

I found out two things:

  1. the testFunctionScript needs at least these policies to call a function: read, write, policy, test
  2. a schedule needs at least the same permissions as a script in order to run the script at all

This is how the various permissions affect the testFunctionScript script:

  • no policies only allow :log info "testFunctionScript";¬†.
  • read allows the above and :local testFunctionJobs [/system script job print as-value detail]; which then is be logged with :log info "testFunctionJobs=$testFunctionJobs";
  • only write seems equivalent to no policies as it will only allow :log info "testFunctionScript";
  • read and write is equivalent to read
  • a lone policy or test policy (talk about confusion!) do not add functionality, so any combinations of just policy or testwith read and/or write get the same functionality as above
  • policy and test without any other seem equivalent to no policies as they result in only :log info "testFunctionScript"; to execute
  • the combined policies read, write, policy, test allow full script functionality including the function call and using the function call result

The above findings show that more logging is needed: the scheduler should log when (and why!) it does not have enough permissions to run a script. Right now you’re in the dark on when (and why!) a script isn’t ran by the scheduler.

The above findings show that these parts of the documentation need updating: … repository (update with info about the above policy combinations) … Properties (update with info about the above policy combinations) (does not document anything about policies at all)

The various scripts (apply your mix of policies that you need)

## logon as user jeroenp

/system script environment remove [ /system script environment find where name="testFunction" ];
:global testFunction do={
  :local result [/system resource get uptime];
  :return $result;

/system script environment print detail where name=testFunction
# 0 name="testFunction" value=";(eval /system scheduler  (eval /localname=$result;value=(eval (eval /system resource getvalue-name=uptime))) (eval /returnvalue=$result))" 

:log info "direct execution of testFunction"

:global testFunction;
:local testFunctionType [:typeof testFunction];
:local testFunctionResult [$testFunction];
:log info "testFunctionScript";
:log info "testFunctionType=$testFunctionType";
:log info "testFunctionResult=$testFunctionResult";
:log info "testFunction=$testFunction";

/log print where buffer=memory && (message~"testFunction" || topics~"info")

/system script remove [ /system script find where name="testFunctionScript" ];
/system script add name=testFunctionScript owner=jeroenp policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source=":global testFunction;\r\
    \n:log info \"testFunctionScript\";\r\
    \n:local testFunctionType [:typeof testFunction];\r\
    \n:local testFunctionResult [\$testFunction];\r\
    \n:log info \"testFunctionType=\$testFunctionType\";\r\
    \n:log info \"testFunctionResult=\$testFunctionResult\";\r\
    \n:log info \"testFunction=\$testFunction\";\r\

:log info "execution of testFunction via testFunctionScript"

/system script run testFunctionScript

/log print where buffer=memory && (message~"testFunction" || topics~"info")

/system scheduler remove [ /system scheduler find where name="testFunctionScriptSchedule" ];
/system scheduler add interval=10s name=testFunctionScriptSchedule on-event=testFunctionScript policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=sep/22/2015 start-time=12:02:37

:log info "execution of testFunction via testFunctionScriptSchedule calling testFunctionScript"
:delay 20s
/system scheduler disable testFunctionScriptSchedule

/log print where buffer=memory && (message~"testFunction" || topics~"info")

/system scheduler print detail where name="testFunctionScriptSchedule"


Posted in Development, Internet, MikroTik, Power User, RouterOS, routers, Scripting, Software Development | Leave a Comment »

delphi – VCL events with anonymous methods – what do you think about this implementation? – Stack Overflow

Posted by jpluimers on 2017/10/19

A long time ago, Pablo Vizcay a.k.a. [WayBack] pragmatic_programmer wrote some cool code at [WayBack] delphi РVCL events with anonymous methods Рwhat do you think about this implementation? РStack Overflow.

I still think it’s a very neat solution to bind method references to events.

  TNotifyEventDispatcher = class(TComponent)
    FClosure: TProc<TObject>;

    procedure OnNotifyEvent(Sender: TObject);
    class function Create(Owner: TComponent; Closure: TProc<TObject>): TNotifyEvent; overload;

    function Attach(Closure: TProc<TObject>): TNotifyEvent;


class function TNotifyEventDispatcher.Create(Owner: TComponent; Closure: TProc<TObject>): TNotifyEvent;
  Result := TNotifyEventDispatcher.Create(Owner).Attach(Closure)

function TNotifyEventDispatcher.Attach(Closure: TProc<TObject>): TNotifyEvent;
  FClosure := Closure;
  Result := Self.OnNotifyEvent

procedure TNotifyEventDispatcher.OnNotifyEvent(Sender: TObject);
  if Assigned(FClosure) then


And this is how it’s used for example:

procedure TForm1.FormCreate(Sender: TObject);
  Button1.OnClick := TNotifyEventDispatcher.Create(Self,
    procedure (Sender: TObject)
      Self.Caption := 'DONE!'


Posted in Delphi, Delphi 10 Seattle, Delphi 10.1 Berlin (BigBen), Delphi XE, Delphi XE2, Delphi XE3, Delphi XE4, Delphi XE5, Delphi XE6, Delphi XE7, Delphi XE8, Development, Software Development | 1 Comment »

%d bloggers like this: