I have 2 viewports in our application and previous posts resolved the issue of synchronizing the rotations & translations of the two.
I am having an issue if user changes the view rotation center in 1 viewport I can't set it in the other;
I see the command uil_toolbar.rotation_center() calls gm_point_on_screen_init, then ga_view_rotation_center_set.
I tried ga_view_rotation_center_get() but it doesn't exist. Also, I tried to extract the screen pick from gm_point_on_screen_init(astring) but it stays empty.
So question is how to determine the new rotation center just set, then I can apply it to the other viewport.
PS. Note that I used the view_to_get to get the center point of the view but did not use the view_to_set. This is because to use view_to_set and keep other perceived settings the same you would need to change the "from_point" and the centre_x/y as well; to keep the image in the same place on the screen (center get/set) and the screen z vector(to->from) the same .
The ga_view_rotation_center_set is doing all this for you.
Thanks Arthur. That is useful background, and seems to be what I need.... except...
We have an icon on the Ribbon, "set rotation center". In .def file was calling uil_toolbar.rotation_center(). Changed this to csrs_toolbar.rotation_center():
FUNCTION rotation_center()
uil_toolbar.rotation_center()
dump "done waiting"
myclass.sync_views() /* added new view parameter based on your answer */
END FUNCTION
I'm sure you see the issue.. the "done waiting" comes right away without waiting for user to pick a center. I know the function gm_point_on_screen_init() gets triggered but I don't know how to wait for it... I've implemented forms that wait, but to pause execution until a point is picked without a form; any help would be great.
I've attached something I wrote that I think illustrates the type of thing you are wanting to do. (it is compiled plb stuff) but I'm happy to discuss in detail.
If you have the patience to look at it, it makes a good to talk about. It's my take on a better viewing definition. It expands the standard view logic by having similar views to the default but you apply them with respect to any coordinate system. So "front", rather than looking down global z could be looking down coord2 z, or down a surface normal or element normal or along a beam orientation etc. You define this "local coordinate" system using an icon (either on a form or a toolbar) maybe "surface" and then pick the surface in the viewport (surface or face of solid etc), after you do the pick various viewing operation happen. This type of behavior seems to be what you are trying to set up.
To set my "Local View" pcl up, unzip the attachment and put the folder patran_custom in your home folder. Copy the p3midilog.pcl to your home folder. If you want see the tool bar interface then also copy the p3toolbar.def to you home folder. Start Patran, open a db and then you can call up my Local View utility with the command "ajh_view()"
The main part of the gui you never see, it is a form ajh_view_local but it's display function actually hides itself. To see the form you can type:
ui_exec_function ("ajh_view_local","display2")
the form just contains an autoexecute select databox.
My toolbar icon call backs go to a function that sets the select widget data type of this databox to that specified by the icon callback text. So it changes to, grid, coordinate, fem,surface etc depending on the icon you pick. It then sets the input focus to this databox. The trick is that this databox is not visible because the form is not visible so the user does not see this. calling up my ajh_view_local.display2 function will show the form. The hidden forms autoexecute databox callback function knows the select dataype (a classwide string) and passes that and the selected item to the main viewing function to process.
So rather than call the uil_toolbarxxx you have to make your own function to capture a point and then call ga_view_rotation_center_set to use the xyz location of this point. and then do the other things you want.
In my case the one pick sets the point as the origin of a coordinate system it uses for the views , sets this to the middle of the screen, defines it as the rotation centre and sets a predetermined view. The cog wheel option allows the adjustment of these things.
I've rambled a bit on this one, it's easier to say try my local view stuff and then ask questions. I think that having a form with a select databox that you never see but that you use is the solution to your dilemma, my pcl is just an example of this working.
Thanks again. I was thinking of a hidden select databox. Can't remember why I didn't think more about that... I can implement the same logic as my pop-up message box that uses em_wait() and em_return(). The change event of the data box can trigger a return value for the contents of the select data box. I'll have to make sure things flow right, but sounds good.