unexpected PrimaryWindowChanged event fired.

Docking/MDI for WPF Forum

Posted 5 years ago by Hejian Lin
Version: 14.1.0602
Environment: Windows 7 (64-bit)
Avatar

Hi actipro support:

I found one problem I am not sure it's caused by my mistake or actipro bug:

When I am using the following code to create the document window and the new created document window is the only document window, the PrimaryWindowChanged event fired (which was not fired in previous version):

DocumentWindow documentWindow = new DocumentWindow(_mainWindowDockSite, "documentwnd", "Document Wnd", null, null)
{
CanClose = true,
};

documentWindow.Open();

 

Actipro verion i am using is: WPF Studio 2014.1.0602

Comments (7)

Posted 5 years ago by Hejian Lin
Avatar

If required, I can send the test application I am using for proofing this problem.

Posted 5 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hello, that is probably an expected behavior since the DockSite.PrimaryWindow should be set if there is a document window present.  It is meant to indicate the current primary document in the MDI, even if it doesn't have focus at the time.  If that wasn't working properly before, it probably was a bug that was fixed.


Actipro Software Support

Posted 5 years ago by Hejian Lin
Avatar

Hi Actipro Software Support

Possibly it's your new design, but it destroy our application's logic. Our product relys on your old "Bug", and it stops us to update to the latest version.

In our product, we use the document window tab as the identifier for some working item. we need to tell the following status:

the primarywindow was changed by user behavior (specifically click or select the document window tab) or by application behavior (new document window opened when no opend document, like current, or closing other document).

When it's changed by user behavior, we need to do some very important things as response. But if it's application behaviro, we should ignore it, until the user explicitly select it. All these issues were solved by the old version perfectly.

Then what should we do to achieve our goal with your new "fix"?

Posted 5 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hello,

It sounds like you are already using some flag to know if an application behavior is occurring.  Can't you just wrap that original document creation/open logic with the same flag?  Then you'd be able to ignore it.


Actipro Software Support

Posted 5 years ago by Hejian Lin
Avatar

Hello support

I didn't use any flags before. And I think your old logic should be right. When the document was created with no other document window, it shouldn't be the primary, until the user click to selected. like what you've said "It is meant to indicate the current primary document in the MDI, even if it doesn't have focus at the time." then it's hard to understand that why the new created window is primary document even it's never been focused.

Also even I use the flag, this problem still cann't be fixed for me. I can ignore the first PrimaryWindowChanged event, but when the user click it, I want to response it. But it never fires again?

Or is there any property for use to set the behavior for PrimaryWindowChanged event? Alternately, do you have any way for me to know the document tab was clicked?

Thanks

Posted 5 years ago by Hejian Lin
Avatar

Hello

Our development team have disscussed about it. We think the current PrimaryWindowChanged event behavior should be alright.More robust, we should target on some event like "DocumentTabClicked". May I ask that whether this event ("DocumentTabClicked") is available for document winodw or not?

Posted 5 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hello,

The primary document is meant to indicate the document that is primary and that any document-related menu commands, etc. would work on it if executed.  Since it goes from null to a valid value when a document is opened (which is now correct for its intended purpose), the PrimaryWindowChanged event fires.  It only fires when it is changed, meaning you click on another document.

It seems like you might want to track the DockSite.WindowActivated event instead, and perhaps filter out your logic if the e.Window isn't in a document state at the time.  The WindowActivated event fires anytime a docking window gets focused/clicked.  So as long as you ignore event calls that apply to non-documents, it might serve better what you were originally trying to do.

We don't have a separate DocumentTabClicked event.  WindowActivated would be the closest thing to that.


Actipro Software Support

The latest build of this product (v2018.1 build 0675) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.