Showing results for 
Search instead for 
Do you mean 
Reply

Menuscript - varying the main action depending on a pre-action

I'm trying to find a workaround to a particular problem I have with some NXOpen code.

It has been compiled for NX10 and I want to make sure it doesn't accidently get run in NX8.5 as it crashes NX Smiley Surprised(

I can't add a check to see which version of NX is running to the current  NXOpen code as it will just crash out so I was trying to figure out if I could create a pre-action to the button to see what version of NX was running.  Then dependant on which version is running, either continue or stop running the main action.

 

Is this possible?

 

Thanks in advance,

 

Mark

3 REPLIES

Re: Menuscript - varying the main action depending on a pre-action

I'm not entirely sure that I see the problem. If you have code specific to NX 10 it would go in the NX10 startup/application folder structure. NX 8.5 code would go in the NX 8.5 folder structure. Never the twain shall meet.

 

Perhaps I am oversimplifying...

Re: Menuscript - varying the main action depending on a pre-action

Thanks Cowski.
If only life were so simple.
I have to make my custom code sit alongside any current customisation in any conceivable setup.
As such I'm creating a separate customisation structure. There is still the risk that someone installs an older version of NX after adding the customisation which leaves me the scenario in my OP.
So the question still stands can pre, main and post actions in menuscript interact in such a way that it decides if the main action is triggered?

Re: Menuscript - varying the main action depending on a pre-action

Yes, a "pre" action can cause the "main" action to run (or not)

 

Here's a bit of C/C++ code, so you'll have to translate.

static UF_MB_cb_status_t check_version_cb(UF_MB_widget_t widget,
    UF_MB_data_t client_data, UF_MB_activated_button_p_t call_button )
{
    bool AllowRun = false;

    if (UF_CALL(UF_initialize())) 
		return UF_MB_CB_ERROR;

// logic here
         AllowRun = true;


    if (!AllowRun)
	{
        // error message here
	}
     UF_terminate();

    if (AllowRun)
        return UF_MB_CB_CONTINUE;
    else
        return UF_MB_CB_CANCEL;
}

/*****************************************************************************
**  Activation Methods
*****************************************************************************/
/*  Unigraphics Startup
**      This entry point activates the application at Unigraphics startup */
extern DllExport void ufsta( char *param, int *returnCode, int rlen )
{
   UF_MB_action_t
        actionTable[] = {{ "check_version_callback", check_version_cb, NULL },
                         { NULL, NULL, NULL }};

    if (UF_CALL(UF_initialize())) return;

    UF_CALL(UF_MB_add_actions(actionTable));

    UF_terminate();

}

/*****************************************************************************
**  Utilities
*****************************************************************************/

/* Unload Handler
**     This function specifies when to unload your application from Unigraphics.
**     If your application registers a callback (from a MenuScript item or a
**     User Defined Object for example), this function MUST return
**     "UF_UNLOAD_UG_TERMINATE". */
extern int ufusr_ask_unload( void )
{
    return( UF_UNLOAD_UG_TERMINATE );
}

If you search the solutions database for UF_MB_CB_CONTINUE you might find code in your language of choice.

 

If it will work (I don't think it will) an un-compiled journal would be your best bet.

Another option (again, I'm not sure if this is supported) if you run the DLL from a journal, the journal can check version before it runs the DLL (or not).

Ken Akerboom Sr CAx Systems Engr, Moog, Inc.
Production: NX10.0.3.5 MP5 + patch/TC11.2
I'd rather be e-steemed than e-diseaseled