Detecting Addin Visibility

612
5
10-01-2012 02:44 PM
BrianKowalski
New Contributor III
I have an Extension that needs to handle MapClick Events if (and only if) one or more of its associated Addins are Visible.

The problem is the DockWindow.Visible Property ALWAYS indicates Visible even when the Addin window is Closed.

Is there a reliable way to detect when a DockWindow is simply Visible?

Thanks much,
0 Kudos
5 Replies
BrianKowalski
New Contributor III
If there is no way to reliably detect "Visible" there are ways to use a couple of Events to infer Visibility.

//Is true when the Addin is Created
private bool _isVisible = true;
//Fires when the Addin is Hidden - But ONLY when it is hidden
private void SilcObjectBrowser_VisibleChanged(object sender, EventArgs e)
{
//Even though the Addin is now hidden, this.Visible == true!!!
_isVisible = false;
}
//Will only fire when the Addin is Visible
private void SilcObjectBrowser_Paint(object sender, PaintEventArgs e)
{
_isVisible = true;
}
//Return the current state of _isVisible
public bool IsVisible { get { return _isVisible; } }


This is a start. BUT I would actually like to be able to reliably detect when an Addin is *Active*. Example:

I have an Addin. I click the Button to create and show it: it's now Visible AND *Active*. I Dock it with the Content Window as a tab. So now I have my Addin and the Contents Window on the same Dock Control each having a separate tab. If I click the Contents Window tab, my Addin is not Visible (and the above code will detect this). BUT, it is *Active* and I need to know that.

Is there a straight forward way to detect *Active*? If not, is there a not so straight forward way, like using Events such as above?

Thanks much,
0 Kudos
ErinBrimhall
Occasional Contributor II
Brian,

It sounds like you're trying to accomplish more complex functionality involving cross-form/window behavior and dependencies.

While the ArcGIS Explorer API is powerful and has a lot of wonderful features, we found it difficult (if not impossible) to implement some very simple functional requirements with Dock Windows.  For example, there is no apparent way to programmatically open a Dock Window.  This led to a tradeoff in our own project where we eventually decided to go with Button add-ins that opened plain Win Forms.  We lost the benefits of Dock Windows, but many of our key workflows were simply not possible if programmatically opening our custom windows/forms was not an option.

So, all of that to say that you may have to consider either:

    1) Using Button add-ins that open win forms instead of using the Dock Window add-ins for your custom UIs.

    or

    2) Stick with Dock Windows but rethink your functional requirements to get around the limitations of the API.

We have a pretty robust implementation using Win Forms in ArcGIS Explorer, so I can offer more specific technical advice if you decide to go with this same approach.
0 Kudos
BrianKowalski
New Contributor III
Erin,

Thanks for that info. It's the answer I expected but not the answer I wanted and hoped for.

Thanks much!
0 Kudos
AndreiIvanov
New Contributor III
That's the limitation of the current framework that AGX is built upon. We'll listen to all your feedback when we start designing new AGX.
0 Kudos
BrianKowalski
New Contributor III
Andriy,

Thanks for the info. I would love to see more access and control over DockWindows in future releases.
It sounds like other companies would like to see it as well.


Thanks much,
0 Kudos