Obtaining the OEA code

when dropping a control onto a form, various bits of code are generated.

In short you are missing the AppBuilder API and XFTR within the Visual Designer

It might be easier to write your own Visual Designer and code serializer...

b) intercept the generation and "enhance" it

You have examples of what kind of enhancements you are looking for?

#1) automatically setting properties to a company "standard" (width, height etc)

#2) automatically adding a label for a textedit

#3) converting certain types of components into another (for example,

dropping a combo box would bring up a selection of usercontrols for db

lookups)

loads more

julian

Aha. Now we're talking. You wanna create wizards, like in the SmartComponent Library.

Check the CreateComponent () API of the IDesignerHost Interface, fly to Boston for PUG Challenge Americas and learn how to create Designer Verbs to trigger your own wizards.

meh, not quite. What I really want is the ABL code that is generated

when you drop a control onto a form.

At the moment, my kludge is to create a test form, drop the control

on, and look at the source , copy the appropriate lines of code and

put them into output strings.

Very yukky. Effective (it works) but yukky.

I was hoping to be able to silently create a hidden form in design

mode, add the component, grab the generated code and export it to my

file.

Julian is not only going to be there, he is speaking!

The code serializer in OEA is a non-trivial amount of code. It primarily converts a structure called codedom received from the designer host into ABL code. Part of this is rewriting a bunch of the C# supported structures into equivalent ABL. The other thing it does is translates the data types from .NET to their ABL equivalents where necessary, merging into existing code, translation, event handler generation and removal, and a bunch of other stuff you probably don't like to think about.  Probably way more stuff than you really need it to.

Several of the wizards in OEA use extensive use of codedom to do this type of thing when setting up the initial structure for a class.  So these types of things are possible without needing access to the OEA VD code.  But even this is limited to some initial setup and it knows nothing about the individual objects.  In most cases the standard Microsoft code object serializer handles all the conversion of the live objects into code dom.  The VD and its code serializer don't have direct control over what properties get written out or what objects are present.  That is up to the control itself based on annotations and its property providers.

The custom property provider is usually the way to go since it can handle generating custom code.  The kinds of thing you are asking for is done by such controls as the toolbarmanager in Infragistics where it both adds custom properties, but it handles its own special code generation.

I *know* it's non-trivial. Trust me, I know

That's why I wanted to leverage and resuse what's already been done - something is generating the ABL code, and that something is inserting it into the editor . I just want to grab that code string

something is generating the ABL code, and that something is inserting it into the editor . I just want to grab that code string

But that's always happening for the full class file / InitializeComponent method. Nobody just creates ABL code when you drag a single control from the toolbox. That's the code-dox to ABL serializer which is part of MS Visual Designer specification.

ok, so perhaps we are getting somewhere. Does this code-dox to ABL

serializer have an api that I can use to get the abl code string from

a component

def var a as char.

a = SomeMagicalCodeDoxThing:GiveMeTheCodeForDefiningTheVariableForThisControl("DevExpress.XtraEditors.ComboBoxEdit")

a = SomeMagicalCodeDoxThing:GiveMeTheCodeForBeginInitForThisControl("DevExpress.XtraEditors.ComboBoxEdit")

etc

ok, so perhaps we are getting somewhere. Does this code-dox  to ABL

serializer have an api that I can use to get the abl code string from

a component

I doubt it. And if such a thing would exist it would be undocumented and subject to change without notice.

You'll need to understand some critical concepts before you know the proper thing to ask for.  This may help:

http://msdn.microsoft.com/en-us/library/ms171834.aspx

And a practical implementation:

http://windowsclient.net/articles/shapedesigner.aspx

and an older one, but most of the concepts still apply:

http://msdn.microsoft.com/en-us/magazine/cc163634.aspx

There is code in OEA that takes a code dom and writes out ABL code.  But that won't help you until you get past the first part which is how to build your code dom.  The problem is there must be a live instance of an object first.  The VD is a glorified way of modifying the properties of that live object.  This live object is the thing you build in the designer.  This is then converted to code dom using the microsoft classes.  Until you build that live object in the VD, nothing exists to serialize other than a class outline (super class, interfaces and a few other basics) which created using the wizard.  You could build the code dom in other ways, but something has to build it.  Usually this is the serializer asking the live object (or objects) about its properties and either asking it to serialize itself, or doing some fancy reflection to build the code dom, and more often than not a combination.

I'm guessing, but didn't take a close look, that you could do most of the example above in pure ABL and then you'd have something you could automate.

So this:

a = SomeMagicalCodeDoxThing:GiveMeTheCodeForDefiningTheVariableForThisControl("DevExpress.XtraEditors.ComboBoxEdit")

Looks more like this:

obj = new live object

objectserializer = new ...objectserializer()

codedom = objectserializer.serialize(obj)

codeserializer = new code serializer()

code = codeserializer.serialize(codedom).

You don't serialize a type, you always serialize an instance of a live object.

There is code in OEA that takes a code dom and writes out ABL code. But that won't help you until you get past the first part which is how to build your code dom. The problem is there must be a live instance of an object first. The VD is a glorified way

Matt, one thing that's not 100% clear to me: do you serialize based on the Control/Component instance only or does the Components's designer play a role too during the serialization?

The Components designer is responsible for a lot of your glorified way of manipulating the Components instance.

You're getting into an area I haven't looked at in a while so anything I would say would be unreliable.  There are a lot of moving parts, most of which are completely handled by the MS code.

I believe this is the MS class that handles most of it.

http://msdn.microsoft.com/en-us/library/system.componentmodel.design.serialization.codedomserializer.aspx