DockablePanes hide on Document switch in Revit 2019

DockablePanes hide on Document switch in Revit 2019

cwaluga
Advocate Advocate
1,636 Views
9 Replies
Message 1 of 10

DockablePanes hide on Document switch in Revit 2019

cwaluga
Advocate
Advocate

Did anyone else notice that third-party dockable panes hide after closing one document and opening another within the same Revit instance? If I instead close and reopen Revit, the pane is still there. I did not have any issues with dockable panes in previous versions and the same code still performs well on Revit <= 2018.

 

I have two related questions:

  1. is this possibly a bug in Revit or the API? Can anyone confirm this issue?
  2. if this is indeed a Revit problem is there any way to work around this? I thought of storing the visibility
    state and restoring it at some point. A first experiment that aims to do this in DocumentOpening/Closing
    did not seem to work. I suspect that I don't have access to the dockable pane at this point. Which event would be right to save/load Dockable Pane state?

My issue can be reproduced with the Dockable Dialogs example from the 2019 SDK.

0 Likes
1,637 Views
9 Replies
Replies (9)
Message 2 of 10

Anonymous
Not applicable

Capture.PNG

 

The issue I'm having is that the original "page" isn't even registering. If I click on Show/Hide page, I get the error:Capture.PNG

 

0 Likes
Message 3 of 10

cwaluga
Advocate
Advocate

Did you register the page before you opened any document? Took me a while to figure out how the sample was supposed to be used, but it worked for me this way.

0 Likes
Message 4 of 10

cwaluga
Advocate
Advocate

I now worked around this by storing and restoring the state. As I hate workarounds as much as any programmer, I would however appreciate any comment on whether this behavior is intended or not and if a fix will be provided for this Smiley Happy.

0 Likes
Message 5 of 10

JimJia
Alumni
Alumni

We already submitted similar issue item REVIT-133305 [Dockable Panes Duplicating in 2019 ] on issue found, as this issue requires exploration and possibly a modification to our software. Please make a note of this number for future reference.


You are welcome to request an update on the status of this issue or to provide us with additional information at any time quoting this wish list item number.
This issue is important to me. What can I do to help?
This issue needs to be assessed by our engineering team, and prioritized against all of the other change requests that are outstanding. As a result any information that you can provide to influence this assessment will help. Please provide the following where possible:
• Impact on your application and/or your development. 
• The number of users affected. 
• The potential revenue impact to you. 
• The potential revenue impact to Autodesk. 
• Realistic timescale over which a fix would help you. 
• In the case of a request for a new feature or a feature enhancement, please also provide detailed Use Cases for the workflows that this change would address.


This information is extremely important. Our engineering team have limited resources, and so must focus their efforts on the highest impact Change Requests. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.


Jim Jia
Autodesk Forge Evangelist
https://forge.autodesk.com
Developer Technical Services
Autodesk Developer Network
Email: Jim.Jia@autodesk.com
0 Likes
Message 6 of 10

Anonymous
Not applicable

Hi,

I was wondering if you could post your workaround so other people can learn from it.

I ran into the same problem but couldn't find a solution.

 

Anyways thanks for your post.

0 Likes
Message 7 of 10

cwaluga
Advocate
Advocate

I never thought this bug would live for years to come, so I did not elaborate on my workaround.

 

What I did was simply save the state of dp.IsShown() in a DocumentClosing handler and restore it in a ViewActivating handler. You can do some debugging to check the order in which these events are called during a Revit session to fix some fringe cases (like ViewActivating being called after DocumentClosing if you close a project with multiple open views).

 

This is part of an extremely large closed-source project. Isolating this particular thing into a minimal running example will take some time and thus always fall behind my other tasks. I hope you can easily build an own solution with the hints given above.

0 Likes
Message 8 of 10

Anonymous
Not applicable

Thanks for the quick reply!

I think this will be enough to figure it out.

Thanks a lot, you saved me a lot of time.

0 Likes
Message 9 of 10

Sean_Page
Collaborator
Collaborator

I have several different DP for various things and I never have an issue with them persisting across document opens or closing. This has been from 19-21 without any changes. If you are using Doc Open and Close events it may be worth checking your not unregistering or hiding it unintentionally. 

Sean Page, AIA, NCARB, LEED AP
Partner, Computational Designer, Architect
0 Likes
Message 10 of 10

cwaluga
Advocate
Advocate

No, pretty sure it is no unintentional behavior on our side. Either it is some undocumented API „feature“ or simply a bug which never gained attention. Why would I want to close my own pane in event handlers anyway? The hide API is never even called.

 

I was able to reproduce this behavior even in the DP SDK sample provided by Autodesk and we never had this problem before Revit 2019. It doesn’t happen in any case, but given the fact that we have hundreds of thousands of LOC to maintain I went on to solve other issues. I never checked if it persists in newer Revit versions than 2019.0 though.

0 Likes