[Mono-devel-list] Automating an application
ThorstenNRW
ThorstenNRW at gmx.de
Fri Oct 24 07:20:50 EDT 2003
Hello,
is it possible to automate an application using Mono?
Until last week we wanted to automate one of our applications using JavaScript, but Mono came to our mind to be possibly the better solution since it has some advantages.
Automating means, that we define in our C++ host application a lot of classes (and object instances) that shall be accessible by a scripting language. For example we provide an object of type "Circle" and instances named "Circle1", "Circle2", etc. (or whatever names).
In the script language the user shall be able to enter code like "Circle1.color = COLOR_RED" to change properties of the object. It shall also be possible to read properties as well as calling methods of objects. Vice versa our C++ application needs to be able to call methods of an objects of the C# environment (ok, we think this is already possible).
With JavaScript this can easily be done by defining a class in a C++ structure and exporting the class to the JavaScript engine.
A class is defined in C++ in the following way (simplified example), by defining the name of the class as well as a set of properties and a set of methods:
typedef struct
{
const char *Name;
MonoPropertySpecs *CirclePropertySpecs;
MonoMethodSpecs *CircleMethodSpecs;
} MonoClass;
For our "Cirlce"-class definition this might look like this:
MonoClass Circle =
{
"Circle",
CircleProperties,
CircleMethods
};
The properties are defined in a separate MonoPropertySpecs array of structures:
(For "Methods" the definition is almost the same.)
MonoPropertySpecs CircleProperties[]
{
"Color", CircleGetColor, CircleSetColor, Type,
"LineStyle", CircleGetLineStyle, CircleSetLineStyle, Type,
etc.
};
The problem starts exactly here!!! In JavaScript everything is TYPELESS, but not in C#.
"Type" must be the type of the property (for example MonoInteger, or System.Drawing.Color), I think this is really a problem since C++ does not know anything about the classes and types defined in outside assemblies.
For example in our true C++ implementation of our "Circle" class, the Color-Member is just a "long" which holds the RGB value of the color.
Finally, CircleGetColor, CircleSetColor, etc. are true C++ functions:
void CircleGetColor(void *ObjectInstance, Type **ReturnValue)
{
Circle *p = (Circle *)ObjectInstance;
*ReturnValue = MonoNew Type(p->Color);
};
So my questions is: Is full automation already possible? (I don't hink so, couldn't find any info about that anywhere)
Does anyone have an idea on how to enhance Mono in this direction? It seems to me that the problem with Types can not be solved (except implementing a managed C++ compiler).
But if anyone has a good solution in mind: Please tell it!
If there should be a solution: Is anyone interested in enhancing Mono together with me in that direction? I would be willing to perform the necessary work as much as I can.
Regards
Thorsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20031024/81e216a7/attachment.html
More information about the Mono-devel-list
mailing list