I am converting our NX11 NXOpen API User Functions to NX12. With the edition of multiple DisplayPart windows in NX12, I am finding that the users can click on another open window in the session and (thereby) change the DisplayPart. My fuction does not know this, so when the user tries to apply the changes made while in the NXOpen User function (placing a component part in an assembly) the function errors due the bad display part tag. This is frustrating.... and I need to "idiot-proof" these functions.
So my question is: Is there a way to prevent users from changing the DisplayPart while in the API function? It is not feasible to use UF_DISP_set_display(UF_DISP_SUPPRESS_DISPLAY) to lock the display because the user needs access to place the components.
Solved! Go to Solution.
Beetle, that was an initial thought, but the user, in this case, would already have multiple display windows open.
Thinking harder about this, and in the seeming absense of a specific API funtionality to prevent this, I may have to check into registering a custom callback (UF_add_callback_function) to detect if the display part get's changed and then alert the user and switch back to the inital displaypart.
Off to GTAC to research UF_add_callback_function .....
Beetle, not sure the user would want the function closing the other windows they have open... "Do no harm" as they say.
I have looked into the callbacks, but there is no "displayPartChanged" callback. However, there is one for "WorkPartChanged"
I found when the other open window is clicked, the workpart AND displayPart is changed, so I can use this.
Nicely done, the .NET API has AddWorkPartChangedHandler and RemoveWorkPartChangedHandler. So no need to go to the UF wrapper route either! Also, your C:\Program Files\Siemens\NX 12.0\UGOPEN\SampleNXOpenApplications\PartCallbacks has some nice example code to check out in whatever language you are coding in. In my case I am using vb.
I have wired up a test case and it seems to work fine. Here are snippets of registering and unregistering. I call the register when the form loads (not shown below) and unregister the callback when the user clicks Done or Cancel on the Form. I'll add a little tweaking to not only get the users attention but also switch it back.
' ' WORKPART CHANGED CALLBACK FUNCTIONS ' Register the Callback for changeWorkpart in case user clicks outside of window. Use only during fastener placement. ' Unregister when Done or Cancel is clicked. Sub WorkPartChanged1(ByVal p As BasePart) If debug Then lw.WriteLine(" Callback detected work part changed") If p Is Nothing Then lw.WriteLine(" Old Work Part: NULL") Else lw.WriteLine(" Old Work Part: " & p.FullPath) End If If theSession.Parts.Work Is Nothing Then lw.WriteLine(" New Work Part: NULL") Else lw.WriteLine(" New Work Part: " & theSession.Parts.Work.FullPath) End If End If End Sub Function registerCallback() As Integer If registered = 0 Then idWorkPartChanged1 = theSession.Parts.AddWorkPartChangedHandler(AddressOf WorkPartChanged1) registered = 1 If debug Then lw.WriteLine("Registered Callback") End If registerCallback = 0 End Function Function removeCallback() As Integer If registered = 1 Then theSession.Parts.RemoveWorkPartChangedHandler(idWorkPartChanged1) registered = 0 If debug Then lw.WriteLine("Removed Callback") End If removeCallback = 0 End Function
Note for anyone looking to do this:
According to NXOpen API Docs for WorkPartChangedHandler: "Do not change active display part, work part or work component in this method." ...Yup, it's problematic to say the least.
I have also found it problematic to check for which windows/parts the user is clicking into and trying not to flag the workpart change back to the original. Also, if something goes wrong and the callback cannot be unregistered properly or something get's out of sync, the user could get stuck with a loop that will lock the ugraf session and a save operation may be impossible.
So, while my answer above could technically work, I'm not sold on it. I think that Beetle's method of setting the Multi-Display option off (and thereby closing the other windows) might work better, but could annoy the users.
My choice now is to instruct them not to use multi-window display when in the UFUNCs.
I will gladly entertain other thoughts/options, but maybe this "prevent of displaypart-window change" is a good enhancement request that could be made of GTAC? (anyone have insight on doing that?)
but maybe this "prevent of displaypart-window change" is a good enhancement request that could be made of GTAC? (anyone have insight on doing that?)
I was not able to select anything when switching the displayed part window while a section dialog from SelectTaggedObject or from a Blockstyler block waits for inputs.
But I don't know your complete workflow so it might be a valid enhancement anyway.
To do so, you should contact GTAC or your Reseller (depends on where you are contracted with) to address this requirement with necessary details.