-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ViewState should participate in Viewport's zoomToElements/zoomToElementProps #6416
Comments
Link to your relevant code please. |
@pmconne I cut a lot of corners coming up with a working sandbox example, but the idea is I've added a small button that calls |
Would you agree that subclassing SpatialViewState to achieve this is a pretty clumsy solution (albeit, potentially necessary due to what the current API offers)? |
Yeah, I fully agree. Any ETA as to when this new API will become available? In the meantime, is there any working document about ir or alpha APIs? |
I have outlined the proposal verbally with Caleb and Joe. Actual implementation only just started yesterday. I want to tinker with the code for a bit before producing and sharing some more formal documentation - within the next week or two. We aim to have a beta API and prototype by the end of March. I will keep you in the loop as things progress. |
Problem:
There is no easy way to override
Viewport.zoomToElements
andViewport.zoomToElementProps
to supply custom ranges to zoom to.Context:
I have specialized views (eg. subclasses of
SpatialViewState
) in which I display alternate geometry for some elements using Decorators. By that, I mean thepickId
that passed to theGraphicBuilder
is a persistedelementId
.I'd like to be able to supply range of the alternate geometry instead of the one that comes from the imodel.
The approach used in Viewport's
zoomToElements
andzoomToElementProps
always fetch the placement properties from the iModel to compute a range. It assumes the element will be displayed "as persisted" in the iModel which is incorrect for my use-case.The whole UI system makes it difficult to subclass
ScreenViewport
and override thezoomTo
methods for my needs. It seems like that would be easier if the function was moved inside the ViewState. I could easily override the logic in a subclass and use the right range to perform the zoomTo operation.Thoughts?
Thank you!
Alex
The text was updated successfully, but these errors were encountered: