Work progress 31 July

Ported NaroCad on the wrappers and it worked well.
Started working at the ApplicationFramework wrappers. In 1-2 days also these wrappers should be finished. With these wrappers the wrapping task should be finished. Will improve them while working at Naro.

After wrapping will continue with working at the application architecture. This task should take 2-4 days.

Work progress 30 July

Uploaded and built the latest wrappers.

The wrapping situation is the following:
- the FoundationClasses module contains 22 wrapped packages out of 43 packages,
- the ModelingAlgorithms module contains 61 wrapped packages out of 107 packages,
- the ModelingData module contains 44 wrapped packages out of 45 packages,
- the Visualization module contains 28 wrapped packages out of 31 packages,
- the Draw module is not wrapped,
- the DataExchange module is not wrapped,
- the ApplicationFramework module is not wrapped.

Around 10 - 20 packages from the ApplicationFramework need wrapping, task estimated to take 1-2 days.

Ported successfully the MakeBottle tutorial to the wrappers. The tutorial uses visualization but also many geometry and topology operations.

Next tasks to be done:
- port Naro to wrappers, task that should take 1 day,
- wrap needed classes from the ApplicationFramework module, task that should take 1-2 days,
- some wrapper improvements, task that should take 1-2 days. Compiling and linking takes more than an hour, that should be improved. Probably the dll will be uploaded on SVN. Also the project should be split in 3-4 dlls but at latest try encountered problems at referencing base classes with native pointers from another assemblies.

Work progress 29 July

Wrapped 80 more packages that cover topological functionality and dependencies. With these packages the MakeBottle ported to C# compiles successfully.

To build the wrappers dll takes around one hour, luckily I installed a trial IncrediBuild and gathered together 5 cores to build with.

Tomorrow will work at making the MakeBottle tutorial with the wrappers. Also will work at porting Naro to see if it works.
Also tomorrow will start uploading the new wrappers and make a situation with them. Many of the OpenCascade modules are almost covered by wrappers.

Work progress 25 July

Worked at porting the MakeBottle tutorial to use the wrappers because it contains more OpenCascade functionality than Naro. Because there are operations like building edges, wires, operations that are not wrapped yet, for the missing functionality wrapped the missing packages. Probably in one more day will have something working.

Next steps in development:
- port Naro to the wrappers, task that should take a day,
- wrap the OCAF/Application Framework packages, there are around 8 packages with dependencies, task that should be solved in one day,
- work at the application architecture: study the Mono AddIn, SCSF, CSLA, Windsor framework concepts, task that should take around 2-3 days.

NaroCad Plugins

NaroCAD Plugin System

A must have is a screenshot, taken from the current SVN code.

To understan it is somehow simple, and you should understand the following concepts:

• Node

• Link

  • Signals (Provider links)

  • Slots (Required links)

• Node provider list

• Solver

Node

A node is a class that is derived from: NaroCommands.Node and is a component.

In the sample there are following nodes:

• an OptionsDialog

• OptionsPage

• MenuBar

• DocumentList

• FileSave

• FileLoad

• DocumentView

They may run independently as much as they don't need data from other compoents.

Links

For making the components to be connected they need a LinkBase implementation

The links are of two ways:

• provider nodes named Signals

• consumer nodes named Slots

The default relation of one link is to connect One to Many. So one signal may be connecting to as many slots, and one slot may receive signals from as many signals. For making one signal or slot to accept only one connection (cause of design causes), the connection has an attribute of being exclusive. So, every new reconnection between signals or slots will remove the old one.

To add to a node connections, you should override the method CreateConnection:

Creating a signal:

public override void CreateConnections()

{

ProvideLink("Link.Form.Main");

}

Creating a slot:

public override void CreateConnections()

{

RequireLink("Link.Naro.Document");

}

You may create as many signals and slots for one component, depending of your needs.

Providers

Sometimes some nodes are common components and are needed any time. They can be found in the provider lists or may be added easily:

Adding a provider node:

ProviderList.Get.AddProvider(new MainMenuProvider()); //add directly a node

ProviderList.Get.AddProvider("Options", new Options.OptionsPreferencesProvider()); //add a node with a specified name

To obtain a specific provider, you should eventually convert to it's type, if is not enough to you to work with a NaroCommands.Node class as following line:

Options.OptionsPreferencesProvider optionsProvider =

ProviderList.Get.Item("Options") as Options.OptionsPreferencesProvider;

In this code, optionsProvider may be null if at the „Options” label is stored another type than the needed one.

Solver

The solver creates based on the Node name, a node and automatically build dependencies to it to complete the node links.

(Work in progress)

The solver do only one thing: will assure that connections (signals and slots) of every node are connected. Based on that you may work with objects without care about connecting the nodes manually. The solver stores too a repository of all node names, so you can build a node by name, without care of which assembly (class library or executable) is the originator.

The implementation is right now in the polish stage and will get an improvement soon as matter of how to work with and how to work with the solver.

Progress report 24 July

Worked at polishing the wrappers. Added improvements and small changes, recompiled and verified the functionality of the code. It seems to work ok.

Tomorrow will work at porting Naro to the wrappers.

Progress report 23 July

Yess! I suceeded to display an OpenCascade window using the wrappers (a triedron can be seen on the top left of the screenshot).

In order to do that I made some manual adjustments at the code. Tomorrow I will apply the manual modifications at all classes from the framework, task that will take around half a day. The detected problems that need changes are the following: the constructors that receive native handle parameters need to allocate the internal handle, allocate native objects before calling non handle constructors with them, replace the AspectHandle with IntPtr and extract the pointer with IntPtr.ToPointer().

I am glad that it works, it is good that nothing crashed. I will think how to make some checks for memory leaks.

In parallel with wrappers started thinking at how to organize the project as an agile project to improve the progress monitoring and accelerate deliveries. On this week I am planning to do something about it.

Started also thinking at the application architecture: studying concepts, frameworks, patterns and factories like CSLA for BusinessLogic, CAB and SCSF for smart client, for IoC the WindsorContainer, ObjectBuilder.

Next steps: tomorrow I will work at improving the wrappers and use them to see if i find any bugs. Other tasks planned for this week: port Naro on the wrappers, wrap the OCAF/ApplicationFramework from OpenCascade to include undo/redo and storing in Naro, improve the project reporting/planning/progress tracking, think at the application architecture.

Progress report 22 July

Finished wrapping the first set of packages that contains functionality that covers the visual representation of objects. In total wrapped around 67 packages, generated around 5900 files.

Tomorrow will work at porting the MakeBottle OpenCascade tutorial to use the wrappers as a test; during porting will adjust the wrappers and repair errors.

Progress report 21 July

Today wrapped 24 packages. 10 more packages to wrap until the AIS package.

Scheduled for tomorrow by the end of the day to finish wrapping everything including AIS and start making some visual test application with the new wrappers.

Progress report 19 July

Spent two hours organizing a little the wrapping work: organized into folders/packages the generated files in the VisualStudio solution, also updated the wrappers/wrappers.txt wrapper report file with the work finished until now.

The situation is like this:
- the FoundationClasses module contains 14 wrapped packages out of 43 packages,
- the ModelingAlgorithms module is not wrapped,
- the ModelingData module contains 3 wrapped packages out of 45 packages,
- the Visualization module contains 13 wrapped packages out of 31 packages,
- the Draw module is not wrapped,
- the DataExchange module is not wrapped,
- the ApplicationFramework module is not wrapped.

Will continue with making a test with the wrappers to see if they work properly.

There is one unwrapped package named AIS from the Visualization module that is needed for displaying shapes. To wrap this one it is needed to wrap another 35 packages that it depends on, task estimated to take 2-3 days.

Progress report 18 July

Finished wrapping 6 more packages. Until now wrapped the packages: Standard MMgt TCollection Quantity TColgp TColStd gp TopLoc GeomAbs Geom Bnd TShort TColQuantity SortTools Resource Aspect Viewer OSD MFT PlotMgt Image Graphic2d Xw WNT AlienImage Graphic3d Visual3d V3d TopAbs TopoDS.

Will continue with making a test with the wrappers to see if they work properly.

Progress report 17 July

Improved the generated code by modifying the way enums are generated, wrapped also enums to be managed. Recompiled the previously generated 11 packages and compiled 14 more packages (from a total of 31).

Hope tomorrow to finish the remaining 6 packages and start working at making some visual OpenCascade quick test application to see if it works properly. If everything ok will port Naro to the generated wrappers code.

Progress report 16 July

A problem appeared: spent the day investigating cross boundary passing of native types in different assemblies. If I want to create different dll files for the packages of OpenCascade it happens that there will be classes in one package/assembly derived from classes located in another package/assembly and the native pointer hold in the base class in not visible in the derived class from the other assembly.

Reproduced this problem on a simple project and could solve the error by using #pragma make_public(type). Trying to apply the solution on the OpenCascade wrappers project the linker generates "Custom attributes are not consistent" on several files.

There are two possibilities to solve the problem:
- investigate further the attribute inconsistency and try to generate separate dlls for the OCC packages,
- or put all the wrapper files into one solution and generate one dll for all the wrappers.

Will continue with investigating the attribute inconsistency for half a day and if no acceptable solution will be found probably will put all the wrappers into the same solution and generate one big dll with all of them.

Progress report 15 July

Added 4 more packages that build successfully to the FoundationClasses packages.
Generated wrappers for 19 other packages (a total of 30 packages generated until now) for the Visualization and ModelingData modules. These packages don't compile yet, there are redefinition errors caused by the package splitting.

Tomorrow will work at compiling these packages, hope to finish in one more day. After that will continue with making a test application that uses the Visualization package to see if everything works ok.

Will add also some improvements to the code: the abstract methods will not be generated at all, for classes that don't hold internally a handle but a regular pointer should add some boolean that tells if the attached pointer should be released or not.

Progress report 14 July

Started wrapping 20 packages: TopLoc, GeomAbs, Geom, Bnd, TShort, TColQuantity, SortTools, Resource, Aspect, Viewer, OSD, MFT, PlotMgt, Image, Graphic2d, Xw, WNT, AlienImage, Graphic3d, Visual3d, V3d, TopAbs, TopoDS. These packages cover the graphical representation of objects functionality. Wrapping not finished yet because the code generator doesn't detect properly the overriden methods in a class hierarchy and doesn't add the "override" keyword. This problem generates at least 2000 compiling errors.

Will work at adjusting the generator.

Progress report 11 July

Finished wrapping the MMgt, Quantity, Standard, TColGp, TCollection, TColStd, gp wrappers and uploaded them on SVN. The code contains also destructors.

Started organizing the files on projects so that for each package a dll is generated. The compiled packages are built on the FoundationClasses.dll. Made also a wrappers.txt file where I made a situation with wrapped packages and packages to be wrapped.

Added and uploaded on SVN a quick test C# project that uses the dll.

Will review the code to see if everything ok; if it is ok will start generating more packages.

Progress report 10 July (2)

Made a quick test application that worked well. The following code is written with wrappers and works properly:

Double pi = 3.14159265358979323846;
private bool TestCircleClass()
{
// Create an indefinite circle
OCgp_Circ circ = new OCgp_Circ();
Double radius = 10.0;
Double calculusError = 0.5;

// test the radius methods
circ.SetRadius(radius);
if (Math.Abs(radius - circ.Radius()) > calculusError)
{
return false;
}

// test the length
if (Math.Abs(2 * pi * radius - circ.Length()) > calculusError)
{
return false;
}
// test the area
if (Math.Abs(pi * radius * radius - circ.Area()) > calculusError)
{
return false;
}

// test location
OCgp_Pnt p = new OCgp_Pnt(100, 200, 300);
circ.SetLocation(p);
OCgp_Pnt internalPnt = circ.Location();
if ((p.X() != internalPnt.X()) || (p.Y() != internalPnt.Y()) || (p.Z() != internalPnt.Z()))
{
return false;
}

Console.WriteLine("Circle tests OK");
return true;
}

Progress report 10 July

Succeeded to build in about one hour with minor changes the 731 wrapper files that compose the packages MMgt, Quantity, Standard, TColGp, TCollection, TColStd. Cool.

Need to add code to generate the destructors and rebuild. Will also make some test codes to see if the generated dll can be used in a C# project.

Progress report 9 July

Succeeded to build a set of 5 classes from the gp package and the classes that they depend on (around 20 classes) with minimal changes on the generated code.

Added for compiling all the classes from the gp package and the packages it depends on (MMgt, Quantity, Standard, TColGp, TCollection, TColStd) a total of 731 files and started compiling and adjusting the generator. It seems that there are 3 types of errors that need adjustment at the generator.

Hope to finish adjusting tomorrow the code generator and build the packages. After that will make a test project to see if it the wrappers work well.

Progress report 8 July

Spent the day generating code for 6 packages (around 600 files) and making generator adjustments. The source codes are not building yet.

Will continue with generator adjustments and compiling. Hope to succeed building these packages.

Progress report 7 July

Added constructor with native handle parameter at the code generator for classes that hold handles to native pointers and also classes that hold native pointers. Made a Convertor class that applied on parameters converts them from managed to native and back. Analyzed other packages to see if the current code applies on other situations like getting an Iterator and iterating through a list of shapes and the code seems to apply well on these situations.

I'm making the final adjustments to the code generator, operation that should take half a day and after that I will start wrapping.

Wrapping progress

Compiled the Standard and MMgr packages and integrated the dll into a C# application. Could execute successfully in C# a code like:


// build a managed object passing a managed string
OCStandard_Type standardType = new OCStandard_Type("test");
// call managed methods
UInt32 t = standardType.IsImported();
Int32 sz = standardType.Size();
// call methods that return managed Strings built from native char*
String s = standardType.Name();

Made marshaling for the String^ to be received as parameter and also to be returned by functions. It remained to add to the code generator some constructor that builds a managed object receiving as parameter a native class and that should cover the functionality needed for the wrappers and will start wrapping. Another improvement will be added: the native types will be changed with managed types like: Standard_Boolean -> bool.

There is one problem that couldn't be solved completely: although the marshaling from native char* to managed String^ works ok, the marshaling from String^ parameters to native char* creates problems because it is needed to allocate a char* buffer (because the managed String holds internally a wchar) and some of the native classes that receive char* parameters store internally the pointers. If the allocated buffer is released then the internal pointers points to an invalid area:

// Constructor of the Standard_Type wrapper
OCStandard_Type::OCStandard_Type(String^ aName)
{
// the managed pointer is pinned
pin_ptr tmp = PtrToStringChars(aName);
// the wchar is converted to char* and passed to the native constructor
nativeHandle = new Handle_Standard_Type(new Standard_Type(TCollection_AsciiString((Standard_ExtString)tmp).ToCString()));

// the allocated char* buffer is released when returning, if the native class
// doesn't copy the char* internally it will point to an invalid area

// found some cases of native classes implemented incorrectly that hold internally
// the char* pointer passed as parameter
}


Tomorrow will continue with:
- finish and test with C# the constructor that receives a native handle as parameter,
- modify the generator to replace the native types with their correspondent from .Net, the marshaling for strings is made,
- made some code cleanup at the generator to prepare it for uploading on SVN,
- generate again the gp package and the 4 packages it depends on to see if more problems are encountered.

If everything goes with no problems will start generating wrappers for more packages.

Wrapping structure

Decided on the wrapping solution. Will use a constructor that builds managed objects from native handles, the classes that are used through handles will have a protected native handle, the others an IntPtr (both of these accessed through a Handle property). Will have to add also some = operator overload and a copy constructor.

The trick for declaring the managed class hierarchy is the following:
class ManagedA
{
protected:
// The pointer/handle that will hold a reference to the unmanaged class.
NativeA* na;

protected:
// dummy constructor used to avoid the calls to the default constructor
// from the derived classes, used to avoid allocating na in the
// base and derived classes
ManagedA(ManagedA*) { };

public:
ManagedA() { na = new NativeA(); }; // constructor with no parameters
ManagedA(int i) { na = new NativeA(); }; // constructor with parameters
// The pointer is released in the base class even if
// allocated in the child classes
virtual ~ManagedA() { delete na; };
int MFooA() {return na->NFooA(); }; // Base class method call

};
class ManagedB : public ManagedA
{
protected:
ManagedB (ManagedB *) : ManagedA((ManagedA*)0) { };

public:
ManagedB () : ManagedA(0) { na = new NativeB(); };
ManagedB (int i) : ManagedA((ManagedA*)0) { na = new NativeB(); };
~ManagedB () { };
int MFooB() {return ((NativeB*)na)->NFooB(); };
};


It took a lot of time to adjust the code generator to create this type of structure and didn't finish integrating the project with a C# application. Suceeded to generate two classes from the Standard package that build with no manual modifications.

The highest priority now is to build a dll with the gp package and the other 4 packages that it depends on and use them in a C# project to detect any other possible adjustments needed.

There is no exception system yet. Will have to think also at this.

Work progress 2 July

Improved the code generator, it generates around 80-90% of the code. Now the code is generated in both .h files and .cpp files, static functions are properly wrapped, operators and aliases are detected, included header files are generated properly.

Compiled successfully the Standard and MMgt packages. Found some design flow, I will have to adjust the class hierarchy.

The plan for tomorrow is to improve the class hierarchy, compile the gp package together with other 4 packages that this package depends on and make a C# test application to find other possible problems.

Work progress 1 July

Today worked at compiling and adjusting the wrapper classes. When one class is compiling successfully a new class is added to the project. There are still problems with the include files, methods that return native handles that should be reimplemented with managed classes, there are types that are not used as handles.

Will continue with compiling, adjusting the classes and adding new classes at the compiling project.

Made a compiling list with a minimal set of packages and their dependencies needed for Naro and the list contains around 70 packages.