get reference to a dockable window controls

[WaelSoltan]

Hi all

i have a little problem I need to access a chart control in a dockable window from within another dockable window how can i get reference to this chart control.

Keep in mind i ve tried docwindow.userdata as in the following example http://resources.esri.com/help/9.3/A...b51a546ac6.htm
and it did not help.

Thanks in advance

[JohnHauck]

I'm sure you could go about this in many different ways. However, here are a couple of suggestions that may help.

My simple test contains a dockable window named DockableWindow1 that contains a single child control named button1. It also contains a seperate button that's used to find the dockable window and access its child controls.

For a dockable window AddIn:

1) In the implementation class of the dockable window (AddinImpl) expose a property

public DockableWindow1 MyDockWin { get {return m_windowUI;} }

2) When accessing the dockable window from the separate button:

string dockWinId = ThisAddIn.IDs.DockableWindow1;
IDockableWindow dockWin = getDockWin(dockWinId);
DockableWindow1.AddinImpl addiN = AddIn.FromID<DockableWindow1.AddinImpl>(dockWinId);
DockableWindow1 myDocWin = addiN.MyDockWin;
UserControl uc = (UserControl)myDocWin;
System.Windows.Forms.Button myChildControl = (System.Windows.Forms.Button)uc.Controls[0];

For a COM based dockable window (using the Dockable Window item template in a standard class library)

1) You could expose a separate property or leverage the UserData property of your dockable window:

object IDockableWindowDef.UserData
{
     get { return (object)this; }
}

2) When accessing the dockable window from the separate button:

IDockableWindow COMDockWin = getDockWin("{10039c9d-ac61-4dbe-8bec-bba52b6f5fc0}");
UserControl COMuc = (UserControl)COMDockWin.UserData;
System.Windows.Forms.Button myCOMChildControl = (System.Windows.Forms.Button)COMuc.Controls[0];

Hope this helps!

[Gerg_Gyula]

Just a tip in case someone has difficulties with data exchange between dockable windows within one project: you can use timer objects on each window, while you're passing values in global variables. With the timers on both side, the event effects can be handled from one to the other in almost real time. This way you can pass any data between the windows as well. Use global variables for data exchange, and use timers for event effect handling when you have to code in a hurry.

[AlexanderGray]

I have always made my dockable windows with two controls.  One custom control with all the gui and the other implementing IDockableWindow with just one control on it (my custom one.)  I make the user data control return the sub control and expose any methods on the sub-control to change values.  Be careful when changing values because you are doing so from a different thread and will run into problems.  You will need to use begininvoke to change the text value.
http://msdn.microsoft.com/en-us/library/a06c0dc2%28v=vs.90%29.aspx

The timer will have a similar effect of raising an event on the control's thread and change the control value but then the timer has to run all the time and raise events continuously to change the value once in a while.  BeginInvoke will raise an event on the control's thread once when there is a change.

[Gerg_Gyula]

Yes, you're totally right, yours is a very good solution.
Or, another bit messy but working triggering is:

1. you get the DW1 via the DockableWindowManager on DW2
2. then you hide and show DW1 from DW2 (surprisingly, it won't blink),
3. and then on DW1 you catch the Paint event and can go on with global variables (and change the controls, run methods etc).

With this you can avoid the threading problems. This is for triggering between the two windows, not so professional, but it works.

[BradWind]

To ESRI Support or anybody with any insight to this specific question,

We are having a terrible time all of a sudden with a new OpenGL window we are attempting to introduce as part of our C# extension to ArcMap.  Whenever the window is created moved or resized, the image either doesn't appear at all or flickers badly.  Outside of Arc we had solved this difficult problem previously by using a panel instead of a picturebox as the control to put underneath our opengl viewport in the custom control we made.  That is to say, if we are just making a simple Windows Forms project in VS2010 for instance, the recipe of using the panel control as the same screen region as the GLViewport allowed the contents of the OpenGL viewport never to disappear on loading it up, nor flicker nor disappear on window moves, resizes, or maximizes/restores.

However, inside of ArcMap we are trying to put the control we made (that uses the panel instead of the picture box) onto one of these "dockable windows" as described in this thread and here
http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#//00010000014w000000
and now all of a sudden we are seeing the same issue as before with the OpenGL drawing (code that was reasonably well tested outside of Arc wrt this issue).

The undrawn, or partially-undrawn, window really is unacceptable for would-be users of our extension.  Often nothing draws at all, you just see the flat background window or control color where the normally good-looking interactive OpenGL stuff is supposed to be. 

Long story short, within these new constraints of using the Arc dockable window we can't seem to figure out how to ensure that the drawing always happens as it's supposed to and avoid whatever hDc, windows messaging, and/or other race condition(s) are making our opengl screen region disappear intermittently as a result of dropping it into the dockable window control.

This is an opengl issue, but also related to the dockable window.  How do we make a control with an opengl viewport draw correctly in this dockable window, or better yet, regardless of whatever windows forms container it is placed into?

Before anyone questions hardware, drivers, environment, etc, also know that this 64bit test machine has all of the latest opengl drivers, 4Gb of memory, tao for namespace in C#, pretty much top of the line.  And, like I say, we tested the opengl example outside of ArcMap and it worked fine, no flicker no redraw issues.

We obviously didn't fully understand any of these limitations when we first started adapting the dockable windows for our Arc extension.  It's a bit surprising that such subtle distinctions as whatever this is (native form versus dockable window or whatever) would prevent the opengl display from functioning properly.  There must be some easy solution.  The panel thing took a long time to figure out but somebody had made a good post about it here which is how we learned that trick.

http://www.opengl.org/discussion_boards/archive/index.php/t-160945.html

For this dockable window piece, we�??re just fast running out of ideas after spending a day racking our brains, and any help would be really appreciated.

Thanks much,
Brad W
Senior Systems Engineer

[AlexanderGray]

Hi Brad,
This posting kind of stears away from the original topic of the thread and probably merits its own thread.  This being said I am not surprised you are having trouble drawing OpenGL on a control within the ArcMap framework.  Controls often have paint issue and problems  forwarding events from ArcMap to the windows control instance hosted by ArcMap.  Keep in mind that ArcMap still runs in 32 bit so any customization will be loaded in 32 bit.

[PamCowher]

I'm sure you could go about this in many different ways. However, here are a couple of suggestions that may help.

My simple test contains a dockable window named DockableWindow1 that contains a single child control named button1. It also contains a seperate button that's used to find the dockable window and access its child controls.

For a dockable window AddIn:

1) In the implementation class of the dockable window (AddinImpl) expose a property

public DockableWindow1 MyDockWin { get {return m_windowUI;} }

2) When accessing the dockable window from the separate button:

string dockWinId = ThisAddIn.IDs.DockableWindow1;
IDockableWindow dockWin = getDockWin(dockWinId);
DockableWindow1.AddinImpl addiN = AddIn.FromID<DockableWindow1.AddinImpl>(dockWinId);
DockableWindow1 myDocWin = addiN.MyDockWin;
UserControl uc = (UserControl)myDocWin;
System.Windows.Forms.Button myChildControl = (System.Windows.Forms.Button)uc.Controls[0];

For a COM based dockable window (using the Dockable Window item template in a standard class library)

1) You could expose a separate property or leverage the UserData property of your dockable window:

object IDockableWindowDef.UserData
{
     get { return (object)this; }
}

2) When accessing the dockable window from the separate button:

IDockableWindow COMDockWin = getDockWin("{10039c9d-ac61-4dbe-8bec-bba52b6f5fc0}");
UserControl COMuc = (UserControl)COMDockWin.UserData;
System.Windows.Forms.Button myCOMChildControl = (System.Windows.Forms.Button)COMuc.Controls[0];

Hope this helps!

Can this same thing be done in VB.NET? I have a custom tool that allows the user to draw a polygon on the map and return an area as a string. I then need the tool to be able to populate a text box on my dockable window. I've tried getting a reference to the dockable window the same way you would to open it like this.

Dim dockWindowSW As ESRI.ArcGIS.Framework.IDockableWindow
Dim dockWinSWID As UID = New UIDClass()
dockWinSWID.Value = My.ThisAddIn.IDs.frmSW
dockWindowSW = My.ArcMap.DockableWindowManager.GetDockableWindow(dockWinSWID)

dockWindowSW.txtAcres.Text = strArea

But I'm still getting a shared member error. How do I access the textbox?

Any help would be appreciated. Thanks!

[PamCowher]

Finally after another few hours of searching I found the answer at the following thread.

http://forums.arcgis.com/threads/16562-Access-Textbox-from-Dockable-Window-from-another-class

Thought I'd repost because it wasn't easy to find.