Can .Net controls be used dynamically?

Posted by Stefan Drissen on 29-Dec-2013 16:04

We have a ui renderer that is responsible for creating all (Progress) widgets based on what the ui logic components are telling it to do. I have created a version that does the same for .Net controls, but am missing the dynamicness of vanilla Progress widgets.

For example to set the X of any widget on a Progress widget I just need the handle of the widget. I seem to be unable to do this generically for .Net controls. I am currently having to CAST the class (stored in my temp-table as a Progress.Lang.Object) to a temporary class variable defined as the .Net control that requires adjustment and only then applying the X (via Location). This is resulting in case statements with repeated code (but with a different class variable) for every attribute. 

DYNAMIC-CAST works for passing an object into another object (for example clsForm:AddControls:Add( DYNAMIC-CAST( tt.cls, tt.cls_type ) - but I cannot DYNAMIC the left part (clsForm) to for example clsTextBox.

  • tt.cls is a Progress.Lang.Object
  • tt.cls_type is a character filled with class' type, for example STRING( clsForm:GetType() )

Is there a more efficient way to do this - similar to simply changing X on the widget-handle provided? Or do I need to have lots of repeated code within CASE statements?

OpenEdge Development - Forum
Posted by Matt Gilarde on 30-Dec-2013 09:05

The Location property is inherited by all controls from the System.Windows.Forms.Control class. You should be able to cast your object of class Progress.Lang.Object to System.Windows.Forms.Control and set the Location (or any other property of the Control class) generically.

Posted by Shelley Chase on 30-Dec-2013 09:37

You need to cast the control so you can access the property - in your example "X". The base classes PLO and System.Object do not have this property. There are some base classes for winforms that you can use to limit the number of case statements you will need. Take a look at msdn.microsoft.com/.../system.windows.forms.control(v=vs.110).aspx for example.

Good luck.

-Shelley

All Replies

Posted by Matt Gilarde on 30-Dec-2013 09:05

The Location property is inherited by all controls from the System.Windows.Forms.Control class. You should be able to cast your object of class Progress.Lang.Object to System.Windows.Forms.Control and set the Location (or any other property of the Control class) generically.

Posted by Shelley Chase on 30-Dec-2013 09:37

You need to cast the control so you can access the property - in your example "X". The base classes PLO and System.Object do not have this property. There are some base classes for winforms that you can use to limit the number of case statements you will need. Take a look at msdn.microsoft.com/.../system.windows.forms.control(v=vs.110).aspx for example.

Good luck.

-Shelley

Posted by Stefan Drissen on 30-Dec-2013 11:57

Thanks both - that looks interesting for the common subset of properties.

hw:list-items for example will give a run-time error if the widget / object hw is pointing to does not support list-items. Combined with the can-query function (or accepting run-time errors) this keeps it nice and simple.

Posted by Mike Fechner on 30-Dec-2013 12:37

All geometry related and basic behavior related (Enabled, Visible, Data Binding) are accessible on System.Windows.Forms.Control.

For specific properties like the ListItems you need to cast to the actual type.

.NET reflection would be an alternative (INTERNAL-ENTRIES, DYNAMIC-SET for .NET) but makes code more complex and ugly to debug. I'd only use reflection when 100 percent dynamic UI is required. Typically most UI's only use a hand full of controls. In that case, reflection is avoidable.

For an entry into reflection, check the GetProperty/GetProperties methods of the system.type class and the TypeDescriptor class on MSDN.

Von meinem Windows Phone gesendet
Von: Stefan Drissen
Gesendet: ‎30.‎12.‎2013 18:57
An: TU.OE.Development@community.progress.com
Betreff: RE: [Technical Users - OE Development] Can .Net controls be used dynamically?

Thanks both - that looks interesting for the common subset of properties.

hw:list-items for example will give a run-time error if the widget / object hw is pointing to does not support list-items. Combined with the can-query function (or accepting run-time errors) this keeps it nice and simple.

Posted by Mike Fechner on 30-Dec-2013 12:40

Sorry, PropertyInfo, not TypeDescriptor.

Posted by Stefan Drissen on 30-Dec-2013 17:13

Thanks again - this cleaned up a lot of copy / paste code.

I can live with the cases floating around - so will skip .Net reflection for now - thanks for the pointer though.

This thread is closed