I think you can launch a grip program from a macro, but not the other way around. If this is the case (a quick look in the help docs didn't prove useful) maybe you can rework your macro so that it will call the grip program then continue to run with whatever other commands you need.
You may think that this won’t work because you cannot launch Macro from GRIP. You can make a macro that runs a grip then continue with the macro. Also you can create a User Tools, then have the macro launch the UTD and stop so the user can choose the next Macro or GRIP.
Try to use Journaling in place of the grip and macro. If journaling doesn't work then you can at least use it to generate your C++ code then you can add the missing code and compile it into an application.
First line defines a KF function called myLayerControl. The kf function takes an integer and a string, the next string sets the library attribute to the library compiled name "my_kf_layer", then the next string defines the function name in the library "MY_KF_set_layer".
Then the expression block calls the method UFunc with the first parameter of "UF_KF_invoke_user_function" and that it is a "libufun", and all this returns a Boolean.
So you now have a KF method or function that calls a ufunc with the library name of my_kf_layer that has a function name MY_KF_set_layer and passing it two parameters of type integer and string.
The CPP code prototype looks like:
void MY_KF_set_layer( UF_KF_value_t *data, int num,
UF_KF_value_t *returnValue )
{
You need to map the KF values to C types. Ufunc provides type to do this. UF_KF_ask_integer, and UF_KF_ask_string, plus others.
There shouldn't be any reason to create UTD files anymore. That is somewhat of a legacy way of creating dialogs before toolbars. The preferred method would be a tbr file or a mtx file for defining toolbars.
