Walking the Control tree

Posted by rbf on 11-Dec-2009 04:22

I am getting stuck with the .NET version of walking the widget tree.

I am trying to find Infragistics.Win.UltraWinToolbars.ToolBase controls on my form but get mixed up between System.Windows.Forms.Control and the Infragistics controls. From the class browser I don't seem to be able to find a common denominator between Infragistics controls and .NET controls. This is what I am trying to do:

METHOD PRIVATE STATIC VOID GetActions(INPUT parentcontrol AS System.Windows.Forms.Control+ControlCollection):
  DEF VAR ldebug AS LOGICAL NO-UNDO. 
  DEF VAR icont# AS INTEGER NO-UNDO.
  DEF VAR childcontrol AS System.Object NO-UNDO.
  DEFINE VARIABLE ocont# AS Infragistics.Win.UltraWinToolbars.ToolBase NO-UNDO. 
  controlloop:
  DO icont# = 0 TO parentcontrol:Count - 1:
    childcontrol = parentcontrol[icont#].
    ASSIGN 
      ocont# = 
CAST(childcontrol,Infragistics.Win.UltraWinToolbars.ToolBase) no-error. 
    IF VALID-OBJECT(ocont#) AND ocont#:TOSTRING() MATCHES "*Tool" THEN 
    DO:
      MESSAGE ocont#:TOSTRING() CAST(ocont#,Infragistics.Win.UltraWinToolbars.ToolBase):Key "found!".
      NEXT controlloop.
    END. 
    GetActions(childcontrol).
  END. 
END.


As you can see, I am succesfully mixing up several different concepts here . Please help. I will give you points!

OpenEdge Development - Forum

All Replies

Posted by Admin on 11-Dec-2009 04:41

Hi Peter,

the least common denominator between all .NET Controls (independent from the Vendor) is the System.Windows.Forms.Control class. The issue is, that neither the toolbars manager or the tools (the ToolBase derived types) are Controls. The ToolbarsManager is a component (System.ComponentModell.Component). That's why you find him in the lower yellow part of the design canvas.

I doubt you'll be able to walk a single "widget" tree for UltraTooblars elements on Controls.

What are you trying to achive?

Mike

Posted by rbf on 11-Dec-2009 04:59

mikefe wrote:
the least common denominator between all .NET Controls (independent from the Vendor) is the System.Windows.Forms.Control class. The issue is, that neither the toolbars manager or the tools (the ToolBase derived types) are Controls. The ToolbarsManager is a component (System.ComponentModell.Component). That's why you find him in the lower yellow part of the design canvas.

Aha! THAT is what I was missing.

What are you trying to achive?

I am trying to synchronize the database with the design canvas so we can enter authorizations for the toolbar tools in the database.

Posted by Admin on 11-Dec-2009 05:23

I guess you need to look at things in different ways, based on the Controls. I've gone thru that already.

Now your looking the Controls and Tools. For Controls probably Visible and Enabled are the properties you want to control. For tools that are different objects and properties (don't forget that a user can customize the Toolbar and might bring back tools that you've taken away).

Same with UltraGrids. It are two different stories of a Column is not visible (Hidden) and if the user can't drap and drop it to and from the Column Chooser.

Posted by rbf on 11-Dec-2009 05:44

mikefe wrote:
I guess you need to look at things in different ways, based on the Controls. I've gone thru that already.

I am open to suggestions.

How do YOU enable an application administrator to authorize user actions?

Posted by rbf on 11-Dec-2009 07:00

> I doubt you'll be able to walk a single "widget" tree for UltraTooblars elements on Controls.

Well now that you put me on the right track this seems to work:

METHOD PUBLIC VOID GetActions():

  DEFINE VARIABLE icomp# AS INTEGER NO-UNDO.

  DEFINE VARIABLE ocomp# AS System.ComponentModel.IComponent NO-UNDO.

  DEFINE VARIABLE itool# AS INTEGER NO-UNDO.

  DEFINE VARIABLE otool# AS Infragistics.Win.UltraWinToolbars.ToolBase NO-UNDO.

  DO icomp# = 0 TO THIS-OBJECT:Components:Components:Count - 1:

    ocomp# =

THIS-OBJECT:Components:Components:Item[icomp#].

    IF TYPE-OF(ocomp#,Infragistics.Win.UltraWinToolbars.UltraToolbarsManager) THEN

    DO:

      MESSAGE "toolbar:" CAST(ocomp#,Infragistics.Win.UltraWinToolbars.UltraToolbarsManager):DockWithinContainer:TOSTRING ()

      VIEW-AS ALERT-BOX.

      DO itool# = 0 TO CAST(ocomp#,Infragistics.Win.UltraWinToolbars.UltraToolbarsManager):Tools:Count - 1:

        ASSIGN otool# = CAST(ocomp#,Infragistics.Win.UltraWinToolbars.UltraToolbarsManager):Tools:Item[itool#].

        MESSAGE "tool:" otool#:Key VIEW-AS ALERT-BOX.

      END.

    END.

  END.

END METHOD.


I just can't figure out how to get the (fully qualified) name of DockWithinContainer so tools can be uniquely identified.
Message was edited by: Peter van Dam

		

		
		
		

		  
Posted by Admin on 11-Dec-2009 07:06

		  
I just can't figure out how to get the (fully qualified) name of DockWithinContainer so tools can be uniquely identified.
Since it's an ABL Form derived class:
CAST(ocomp#,Infragistics.Win.UltraWinToolbars.UltraToolbarsManager):DockWithinContainer:GetClass():ToString()

		

		
		
		

		  
Posted by Admin on 11-Dec-2009 07:07

		  
mikefe schrieb:
I just can't figure out how to get the (fully qualified) name of DockWithinContainer so tools can be uniquely identified.
Since it's an ABL Form derived class:
CAST(ocomp#,Infragistics.Win.UltraWinToolbars.UltraToolbarsManager):DockWithinContainer:GetClass():TypeName






Sorry, TypeName, not ToString().

		

		
		
		

		  
Posted by rbf on 11-Dec-2009 07:20

		  
ToString() returns something like "Progress.Lang.Class_1179".
TypeName returns something like System.Windows.Forms.SplitterPanel
I was hoping for splitContainer1.Panel2 etc.

		

		
		
		

		  
Posted by Peter Judge on 11-Dec-2009 08:06

		  
That should be the control's :Name.
-- peter

		

		
		
		

		  
Posted by rbf on 11-Dec-2009 08:30

		  
pjudge wrote:
That should be the control's :Name.
-- peter
That is what I expected as well. However:
CAST
(ocomp#,Infragistics.Win.UltraWinToolbars.UltraToolbarsManager):DockWithinContainer:Name 
returns nothing and
CAST
(ocomp#,Infragistics.Win.UltraWinToolbars.UltraToolbarsManager):DockWithinContainer:GetClass():Name 
does not compile as Progress.Lang.Class does not have a name property.

		

		
		
		

		  
Posted by Peter Judge on 11-Dec-2009 09:03

		  
You shouldn't expect to see the variable name on the P.L.Class object, since that's the type (ie definition) of the object and not the instance itself.




It appears to me that this is not a UTM issue, but rather a SplitterPanel issue. I wasn't able to see the Name prop of the splitter panel being set anywhere, nor was I able to change it in the property grid.   However, when I changed it in code, I got a value.




See attached.


[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/2134.form1.cls.zip:550:0]


[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/0005.form1.resx.zip:550:0]


hth,


-- peter

		

		
		
		

		  
Posted by rbf on 11-Dec-2009 09:52

		  
pjudge wrote:
You shouldn't expect to see the variable name on the P.L.Class object, since that's the type (ie definition) of the object and not the instance itself.
It appears to me that this is not a UTM issue, but rather a SplitterPanel issue. I wasn't able to see the Name prop of the splitter panel being set anywhere, nor was I able to change it in the property grid.   However, when I changed it in code, I got a value.
See attached.
hth,
-- peter
Good discovery!. Annoying. This kind of stuff makes me uncertain about myself and then it turns out to be a bug.
The bug makes it harder to create a generic solution but the workaround is to set the name in code in case of a splitter panel then.
P.S. What is UTM?
P.S. 2. Where to report this bug?

		

		
		
		

		  
Posted by Peter Judge on 11-Dec-2009 10:01

		  
Good discovery!. Annoying. This kind of stuff makes me uncertain about myself
and then it turns out to be a bug.
The bug makes it harder to create a generic solution but the workaround is to
set the name in code in case of a splitter panel then.
P.S. What is UTM?
UltraToolbarsManager (lazy fingers on a Friday  
P.S. 2. Where to report this bug?
I'd think this is a .NET bug (Microsoft), although if you read the opening sentences here http://msdn.microsoft.com/en-us/library/system.windows.forms.splitterpanel.name.aspx  , it seems like this behaviour is deliberate. So there might be a bug in that the Name property is public.
-- peter

		

		
		
		

		  
Posted by Admin on 11-Dec-2009 10:01

		  
Good discovery!. Annoying. This kind of stuff makes me uncertain about myself and then it turns out to be a bug.
I wouldn't consider it a bug - it's more a feature. As a .NET developer (Microsoft in this case) you can specify which properties are available from the properties grid using annotations in the (C#) source code. That's why the Name property seems to be hidden. 
 P.S. What is UTM?
My guess it's UltraToolbarsManager...
P.S. 2. Where to report this bug?
Microsoft?

		

		
		
		

		  
Posted by Admin on 11-Dec-2009 10:04

		  
So there might be a bug in that the Name property is public.
It needs to be public because the splitter pane's inherit from the Control. I don't see that as a bug, rather as a nice feature because you can count on the fact that all Control child-types have a Name property.

		

		
		

				

		  
		  
		 This thread is closed