3D geometric solver

Implemented the 3D geometric solver code. Currently it supports points matching and plane matching, the point matching works ok, the plane matching needs improvements.

The next step would be to integrate the solver into the solver pipe so that all mouse events go through the solver. After that will add also a drawer that displays magic points.

Command line working

Command line is a working component. Every command interface with NaroCAD events and are transparently sent. Also, all known bugs are fixed

It comes with possibility to manage history, code completion based with biggest common prefix.

So, if in future will be two commands: subshape and subface, writing 's', right now it will offer to you all commands that start with s, pressing space, considering that are this only these two commands, command text will complete to 'sub', the biggest common prefix, pressing s (so your word is 'subs' right now) and again space, will complete to you as subshape. Also, as is shown in screenshot, every param is bolded to be obvious the type expected for your param. Every command that succeed will be saved to history.

Also, small remaining bugs like finishing all shapes, or to not select the last shape created, were fixed. Also, a bug regarding that you've got a not so clear error message when you input an invalid parameter is already fixed. So enjoy using it for big automation tasks.

Command line, plugins, geometric solver

Improved the modeler so that it provides an Event based interface that allows it to be controlled from outside (the command line can control it). It allows drawing shapes, displaying shapes into the property grid. Modified the current functionality (draw line, draw rectangle, extrude) to work with interface events.

Made the geometric solver an independent module, made a solver pipe that will pass all the mouse points through the solver.

Rearranged the modules so that functionality exposed to plugin developers will be provided as interface assemblies. Implemented a test plugin that registers itself in the View menu and listens to events. This plugin will be developed to have the same functionality as the line drawing tool (the purpose would be to discover the functionality needed by the developers to be exposed).

Will continue working at the geometric solver. At porting the 2D to 3D, the functionality will be changed because the mouse points coordinate conversion from 2D to 3D depends on the plane where the user works. Also the magic points in 3D will be detected in a different way.

Command line improved (almost working!)

Command line (with help of bxtrx) have been greatly improved. There are still bugs here and there, but most commands are there, also, when you do create a shape, is saved in the script list. You can save scripts and execute them later. Most commands are not finished, but they have most code there, most of them depend in 1 line fix to make them work.

At the end you have code completion (activated with Space and hints about param types you should fill in).

Command execution only if succeeds only it will be saved in history list.

Also, there was fixed a bug in command line scanner that commands which require strings, to have removed spaces and to not get parameters at all, but the command to be called still.

Command line basics in progress...

Command line module is mostly defined.

Initially I had tried to make it close to IronPython previous work but I found really hard to work for most users. It will be too hard to make it both user friendly and users will have to work hard to understand an error.

So the work is right now based on a command line interpreter that will fire events to Naro core modules. This interpreter have most work done. Means a scanner that will recognize easily if tokens are on the right types, also, there is a parser logic (that need to be fixed) and an extensible command list.

Hopefully tomorrow I will accomplish at least the line command working and if is time to add the history list. Thursday, I will complete the previous late tasks and I will add all other other basic commands which are already defined in OpenCascade like drawing a rectangle or doing an extrude. Also Thursday I will try to do document integration (so to be possible to do undo after a bulk of commands).

2D to 3D porting

Worked at porting the existing OpenCascade 2D code to 3D. Removed all the references to 2D from the project. Finished refactoring the infrastructure code so that now it works having two or more modeler windows in the same time.
Made the command line specifications and made some tests with launching commands between the modules(command line module <-> modeler module).
Added also the Sketcher functionality that when clicked rotates the selected face and fits the model into the window. Also a grid area is shown on that plane.

Will continue working at implementing the Sketcher functionality (port the geometric solver to 3D, add magic point drawing, enable edit mode for the shapes). Will also help with the command line and plugin system implementation.

Iteration 0.0.11 closed

Closed Iteration 0.0.11. Among the tasks finished during this Iteration:

- Added support for layers,
- Drawn rectangle in 3D,
- Made tests code for PropertyGrid, TreeView, GUI leakig tests,
- Stabilized the Extrude, it also works to Extrude the face of an Extrude,
- Stabilized Undo Redo,
- Stabilized the parametric modeling propagation,
- Implemented the NaroCad Linker that generates a reduced wrapper assembly that contain only the packages used in NaroCad.


For the next Iteration (Iteration 0.0.12) among the scheduled tasks are:
- Implement command line and possibility to execute command files, estimated 1-3 days,
- Move to 3D all the code that was implemented with 2D, this task also includes implementing a geometric solver and magic points drawer, edit mode for objects, estimated 1 week,
- Display intermediary info during drawing, like if an rectangle is drawn the point clicks can be changed during drawing, we will have to find a solution for this and make an estimation,
- Algorithm validation that verifies if the conditions to launch a tool are met or notifies user if something is wrong, estimate 2-4 days,

Lower priority tasks from the current Iteration:
- Implement the Cut, it takes 2-3 days,
- Stabilizing current code, bug fixing,
- Establish the API to be exposed to plugin developers, made some sample code for plugin developers - this should enable developers to use Naro as a platform, 2-5 days.
- Establish some shape drawing policy like: 4 lines can make a rectangle shape, or a closed shape policy.

Developing on Atom CPU

This weekend I tried to sum what are limitations to work on a low spec machine (for today's standard) as a developer on NaroCAD. So I tried to work on a netbook.

Netbooks have mostly this specifications:
CPU between 900 MHz up to Atom 1.6GHz
RAM 512M or 1024M
Screen resolution: 800x480 or 1024x600
Integrated Intel video card
Windows XP SP2 or SP3
Most of them have enough disk space.

It is enough to develop on NaroCAD?
For me the biggest limitations even having the high end of this specifications, I barely can say yes. The biggest limitations were: screen resolution and memory. With 512 RAM you can barely start NaroCAD, so is hard to think you can start an IDE to it. Also, this memory supposedly is not only NaroCAD, even you are either a user or developer. You may need a browser or a PDF reader to read the specifications you want to fill in by designing them in NaroCAD.

What are quick fix solutions:
- if you have any antivirus, stop at least background file scanning. If you want to keep anti-phishing module enable, do it, but not more! Elsewhere you will see that at any operation your maching will work too slow without a proper reason
- stop any program you have in memory that seems useless to you. Do you see a tool that increase brightness of your screen with one click? Stop it, you can do it using your laptop keys. The battery tool? You have also a good XP one... etc.
- when you develop, you can develop using the full-screen mode. SharpDevelop have it. You will be able in this way to see much more text and to have a bigger context to see it. Or even better, if you have from your older PC, a display, use as a second display. It will save to you a lot of headache and lot of scrolling. Also, you will need an USB mouse to attach to that laptop, using the small touchpad may be troublesome
- if you have a SSD limited drive, XP have the possibility to compress folders, so you may do this: go to folder->right click->Properties->General Tab->Advanced->Compress content to save disk space. This will slow things much less than you expect. The full sized wrappers (even you cannot compile them on your machine) if they are expanded they should occupy 2GB on your disk, but they will occupy in fact 1.1G. Also, if you will compile only using NaroLinker, the space requirement of wrappers will be around 1G expanded, so only 500M (on disk).

The IDEs that are free and work if you are price sensitive (considering that you develop on an netbook, you may be one) works great. If you have an Atom CPU, which have the ability to run better two processes, I recommend Visual Studio C# Express which do background compiling, and will do it a bit faster.

My personal preference is SharpDevelop which also run well, but will not have all smoothness of Visual Studio. SharpDevelop have also integrated the TurtoiseSVN tools, unit testing, profiler, which makes it feature wise much closer to Professional editions than Express one.

What you cannot do on NaroCAD development on that machine at all:
- you cannot compile full sized wrapper. The good think is that NaroCAD project provides them in SVN
- you should buy still a 2GB memory module. It should cost you 10% of price of the laptop, but at least will bring to you bit smoother experience in almost any applications, not only in NaroCAD. If you will have 2GB of memory, you can at least build using NaroLinker tool the C++ wrappers. It should take a night of compiling, but at least it will do it.

What I was really pleased to see:
- without an antivirus Atom CPU is pretty fast, or to name it better, enough fast
- the integrated video card was enough fast also, and it gives really no visual artifacts on OpenGL, which is for me at least impressive
- your laptop machine is really very quiet, low power consumption and you can use NaroCAD smoothly (at least with 1G of RAM)

Small API fixes and tweaking on updater/installer

NaroCAD have small touches in function API, mostly two:
- till now, every time you create a node with function you should call BeginUpdate, to avoid crashes in Execute.

NaroCAD have a parametric modeling architecture built-in so, every time a parameter is changed right after you define a function, may make the function to be called even before all dependencies are defined. To avoid this was necessarily to call BeginUpdate right after you called a function.

Right now the BeginUpdate is called silently. And the EndUpdate was already called as a part of Execute.

Putting BeginUpdate by default, will make the concern that the developer will want to call too early the Execute method still. Because this cannot be solved in all cases, the Function attribute (which can create a shape) have right access by dependency to an property named: HasDependenciesSolved which will return a boolean value that reflect if your function have all stated dependencies defined.

This property is checked and will block and log misused calls to create a shape without defined dependencies.

Also, before uploading the file to Naro server, it is setup an option to take the snapshot from Naro server. The installer is also updated to install by default NaroCAD to local user folder. Also, a small fix is that the installer will point NaroCAD to NaroStarter.

Standalone part modeler

Refactored the application so that the Sketcher and Modeling manager modules are removed. Now the Part modeling module is completely independent, it has its own toolbars and events that it registers at startup.

Will continue working at improving the event system (for the case when there are two or more windows open in the same time), fix the menu and after that port the Sketching code to 3D. Will also improve the module separation to be completely independent so the application is not affected when one module is missing (ex: if the importer module is missing the application starts and works properly only that it can't import and export).

Naro Starter, Updater and nightly build... all at once

Naro gets a lot of refinements from user perspective as NaroLinker.

Also, is much better to them to have the latest version updated silently. What do you need right now to start and test NaroCAD?

A small starting download of NaroStarter. NaroStarter do also environment checking on your machine (you still need to have preinstalled .Net 3.5!). Right now NaroStarter will check every time using a less than of kilo download if you are up-to-date, and if you aren't, it will download ONLY what was changed. So is even faster than downloading the installer file.

So as an user, you will only need a 100k download (excluding the big OpenCascade download and C++ Runtime SP1 if you don't have already download) and the rest will work silently to you. All parts using the update system can be changed. Means: updater itself, NaroStarter or any other file.

For developer was made a visual tool that do this, automatically that reads the setup installer script and compare differences with the current files. So excluding the upload time, the process is seamless both for devels and for users.

So, enjoy it!

Layer support to NaroCAD

NaroCAD have right now live layer support!

The layers configuration is setup in the root node and is comma separated integer value like: 2, 3, 5 (means that you have 3 layers which are visible with indexes 2, 3, and 5).

And every shape have a layer to work on. When you setup in both document and in any shape, you will see lively that shapes will dissapear/appear correspondingly with the layer are visible.
Layer zero which means no layer means that a shape is visible regardless of layer.

Layers can have multiple data attached but for now it does not contain any.

Note: SubShape or any other shapes can be hidden from tree by adding a special interpreter to them. For now only SubShape that is used to extract a specified face from a shape is excluded!

2D to 3D conversion

Started refactoring the code to replace the 2D functionality with 3D functionality. The Sketcher and ModelingManager module will be removed, also the event routing and toolstrips will be simplified. Almost finished cleaning up the ToolStrips (also made them visually editable, previously they were built through code). When this will be finished will continue with simplifying the WorkItems and message routing.

Removed the window zooming flickering but it still seems to have a problem receiving duplicated mouse click events.

Introducing NaroLinker and others...

Today I did try to make an interesting project as I had a great user oriented idea.

Because I made as simple observation: NaroCAD (and any project in general) use a lot less of the API it has access. Also NaroCAD should be not bloated. .Net 3.5 in itself is huge. Also the OpenCascade may be huge. But NaroCAD is a project that needs to be changed pretty often so it may be useful for users to not download a 30M package only to test it. In fact NaroCAD in itself including almost all dependencies, it is 8M package, excluding the file I will talk next.

The single problem is about OCWrappers, which contains wrapper code to almost a half of OpenCascade library, and is not less than 19M compiled. This are in themselves dummy and they are used as much as Naro grows. But what if Naro uses only a half? Should not be much wise for users to have only used wrapper part?

Naro in itself do not use for instance OCAF. Only removing OCAF from wrappers, will make a a reduction of 2M. The problem appears still that what if tomorrow we will use it. Or what if we remove a thing, and compiler will complain. This will make for developer that want to create a minimalist wrappers a tedious task. Is really to heavy to take in account every linking error or every relation. Also, you can do on other way: you start minimialist and you wait compiler to complain. For every class it complains, you add to your wrappers. Because by references the relations are more than 1000 classes right now from 2300 wrapped, for certain a lot of persons will run away for this job.

But I know someone who will not... This is the computer!

NaroLinker is a program that does this:
1 - Start from an empty wrapper.
2 - Compiles it.
3 - it offer to NaroCAD and tries to build it.
4 - NaroCAD will complain: I miss this classes!
5 - NaroLinker will add to that wrappers project the classes needed
6 - NaroLinker will try to build this wrappers. Because this classes may need anothers, NaroLinker will add them one by one
7 - NaroLinker will recompile the wrappers and add dependency classes till it succeds
8 - Go to step 3 until NaroCAD may have all symbols solved and the process stops here.

Also, there is a possibility to add your own used classes (care, they should be from already wrapped packages!), so if you have wrapped circle but you know that you need ellipse, you will be able to add it even is not used by NaroCAD and rebuild everything nicely! (this is why Add Class button stands for)

How good is it?
In current usage the compiling time goes from 35 minutes to compile the original full wrappers to around 40 minutes (because around 40 compilations and linkages are involved) but the final wrappers goes to 8M. This dependencies are fully working as they are requested explicitly by code or are dependencies of the used classes. The installer saves 1M compressed, which is in fact a 11M on disk. So right now instead 3.9M, the installer goes in 2.75M.

As a developer I still recommend full sized wrappers. They offer all wrapped packages, not only used one, but from a QA or user perspective, a slimmer binary is much better. The other small advantage, is that if you have a 2G machine, the full sized wrappers at least on Vista64 (my machine), the linking step of all 2000+ classes may get over 2.5G, when the 1100 classes used by smaller wrappers may make the compiling of wrappers to be faster on that machine. Also, if you will use the reduced wrapper, and you work on NaroCAD at least for testing purposes, you can have at least a significantly reduced wrappers so are easier to be search and faster to navigate on them. The linker remove unused classes not unused methods, so you will have still a coherent assembly that contains the wrappers!

Note: I work to add extra attributes to items to not be displayed in trees or to appear in Layers. More on them tomorrow!

Fillet working again (and other small fixes)

Firstly this is a small fix: empty commit will not make that revert will do an undo.

Fillet right now is working and can be edited in properties also!

There is also a small fix in extrude related changes: in case you extrude starting from a face of other extrude, the face with index zero was skipped. Right now it will not give problems to you.

So day by day Naro is more pleasant to use!

So why not to give it a try? (installer scripts updated, also you can download and test it from here: http://www.narocad.com/binary/setup.exe )

Finished shape drawing on 3D

Finished implementing the 3D Rectangle drawing. Also refactored the Line 3d, Extrude and Rectangle 3D to be derived from the same base class sharing some of the functionality, validated the functionality checking for crashes, undo, redo. Validated some of the finished tasks and bugs from the current iteration.
Solved the right click rotation bug (if the shape was rotated using right click before, after or during an extrude the face picker stopped working).

Will continue with studying if the 2D code/functionality can be replaced completely with 3D, will also help with the 3D geometric solver and magic point drawing.

Smarter zoom and small fixes

Zooming an area works again right now. It was based on a new input, which gives a rectangle area to the modeler view. This means also that future actions that use a rectangle may get use of it.

Also, I was fixed the case of changing color on a shape may not be applied on Undo if the shape have no color previously. This was because removing attributes was not notified by the Naro framework code. Right now the removal of attributes is notified and will not make this problem to appear again (for any other properties that will disappear on undo to not update the view).

Custom changes: Document have right now an boolean AutoTransact property. Setting it as true, will make the transactions to be much lighter as they will be considered right after the last commit. Based on that, is both advantageous if you are unsure how to use the document. Also a small changed that was done in the last days is that Document.Commit will get a reason string. This will mean that you will see the reasons for most events in your Undo/Redo lists.

If you don't know what is it about: NaroCAD store the entire scene in one document. This document can have undo/redo operations but they are happening when changes are computed between a document.Transact(); ... document.Commit(reason);. The changes between Transact() and Commit() are setup in your Undo/Redo list. Because some persons may forget to call Transact, setting AutoTransact = true; will make your code to not behave wrong cause of this, and also be a lighter as Commit() will compute a tree as a base of differences, that is passed as the part of Transact() which means that Transact will not generate again the same tree.

2D shapes drawing in 3D

Started working at making the 2D shape drawing in 3D. Reimplemented the 3D line drawing so that it uses the FacePicker to generate working planes, when the user moves the mouse over a plane/face the generated points are on that plane. In this way the line points can be drawn on the same plane/face or on different planes. Started also making the rectangle drawing code, probably in 1-2 hours will finish it.

Worked also at validating some of the functionality made until now, the extrusion and parametric modeling propagation seems to work well, no more crashes are generated.

Will continue investigating the bug that makes the face picker not detecting faces when rotating with right mouse button. Another important issue would be to study in detail the OpenCascade 2D functionality and decide if this can be replaced only with 3D modeling code so that there is no need to switch between 2D and 3D.

Eventually fixed!

Some bugs live with your application and sometimes are really hard to be noticed! The last one was in this category. All tests show that all components of the tested component work, but unfortunately, it did not from outside. What should it be?

If you take NaroCAD till this Sunday and you do this simple steps: make an extrude twice, do an undo, make the second extrude again and do twice undo, you should have no extrude. But you will see that one extrude is floating still. Eventually seems to me that was the second extrude (from the list of three created).

But why? Making first day of debugging session I eliminated the possibility of wrong computing diffs or not applying correctly the undo. After more research I removed the possibility of Extrude to do a wrong-doing in document live cycle. The single thing that remains in my mind was: it is a leak that is floating, and try to find it...

After a long research and trying to make small breaks, I remained out of ideas.

Eventually, I made assurances not by debugging but in code also that all parts are right, one by one. So I found that the diffs was computed wrong. Means that they were wrong from what was visual and what was computed. The diff in undo was computed right, but the trees eventually seemed wrong. The cause seems to be that after applying Undo, I did not make the compare point as previous.

So as a simple sketch: and you have 3 stages, A, B and C. And you will go from A to C like: A->B->C

When you do an Undo, you will go one step before C, so you will have A->B. The bad thing is that when you do: A->B->D, in old code, the diff was made between C and D, not B and D, and all went wrong.

That was really a well hidden bug, but the great thing is that at least undo/redo and at least all workflow of data between rectangle, reference subshape and extrude works flawlessly and is checked countless times, also in all relations between undo, redo and events like removal of them!

Undo and propagation

There was a case when constant propagation do not work well. And the case is pretty complex. The case is mixed with Undo/Redo code. So may be a problem in Undo/Redo, Extrude itself or other problem. So from any moment may be a solution I would hope to find, but for certain is not obvious.

Also, today was make that parametric modeling will create undo/redo points. This makes that there the defined guard will be able to have both visual impacting changes or non visual. The non visual changes will only create an Undo/Redo point. A good thing also is that there is a minimalist code to make a undo/redo to happen by adding two lines in code.

Cascade propagation last fixes

Propagating multiple extrudes works right now. (That means that modifying any parameter will update only the geometry affected and its dependencies)

Another crash is fixed due to what the dependency handling naro code will not crash in case one shape is invalid in a chain of dependencies.

Also the side effect of flickering updating all changes is done using a guard class (because IDisposable interface is not called in a predictable way, the user should explicitly call the view but in a much smaller way).

Combined with bxtrx fixes which improved the speed greatly, right now Naro is a much more pleasant application to use.

Extrude in action

Bug fixing

Bug fixing mostly this time:

Undo/Redo seems to be fixed completely in all known cases to have problems.
- there was a case when undo (or redo) crashes silently when it need to remove objects
- undo was used not properly in case of extrude and let some objects floating

I was looked with bxtrx initially for leaks and found a part of the problem (as it was related with OCC and not with TreeView and PropertyView).

Right now I'm investigating why propagating events in cascade happen to generate to many times in case of a chained extrude list and gets even recursively. I did not found yet the reason because it blocks easily. With the leak fixed the solving hopefully will be much more smoother.

Found the GDI leak source

After several checks saw that the TreeView is not leaking (as the nUnit tests were showing).
After verifying each of the components involved in drawing (the Weifen Luo window on which a Custom control is put, control that contains a table layout panel and four controls on which OpenCascade renders) found who causes the GDI leaking: in Naro there are 4 views from which only one is visible and the other 3 are hidden. For each control an OCC view is created and mapped to it. Somehow this creates problems at the OCC level, GDI leaks appear even if all the four windows are displayed. Made and uploaded a temporary solution to create only one OCC view mapped on the visible view and this doesn't leak, this should solve many of the Naro crashes. In order to enable for the user to display four views more research is needed to understand how mapping is made especially when many windows are mapped in the same time and also what are the handles that cause the leaking and how should they be correctly used. This also explains why the nUnit OCC tests passed with no leaks, they were using only one window.

Leaking investigation (2)

Made detailed nUnit tests for all the methods of the TreeVew (LoadTree, ObjectTreeList, ClearTreeList, SelectNode, OnNodeMouseClick, OnTreeMouseLeave, OnTreeMouseMove) also checking for GDI leaks and didn't find any problems. Improved also the tests for PropertyGid and also no leaks found.
In Naro the TreeView seems to leak, reimplemented the mouse hover code to remove flickering (caused by the fact that the tree is completely redrawn) and it seems that also the leaking disappeared. Need some more functionality checking before committing.

Will continue investigating the GDI leaking caused by the the OCC visual window.

Leaking investigation

Made a nUnit test code for the TreeView. Decided to implement full tests for the TreeView. Investigated the drawing, resizing, mouse move messages on the MultiView control and also on the controller for GDI leaks.

Will continue investigating Naro for leaking, make full nUnit tests for the TreeView.

Iteration 0.0.10 closed

Closed Iteration 0.0.10. Among the tasks finished during this iteration:

- reviewed the data tree functionality, found and solved two bugs at it,
- made the Extrude work with clicks, enabled extrusion on extrusion, added code that makes a temporary extrusion when the user moves the mouse and when finished saves the model in the data tree, fixed some of the Extrude bugs, made some fixes at propagating the parametric modeling dependencies,
- reviewed and fixed the manipulation tools (global panning, dynamic panning, dynamic zooming, dynamic rotation, etc). Made them work with clicks instead of dragging,
- made a test framework for OpenCascade code, made nUnit test codes for adding and removing objects form the view, test for displaying a node from the data tree, test for property grid,
- made code improvements at the PropertyGrid descriptors (code that displays on the grid the data from the data tree), more work needed at improving the data validity check,
- found and investigated a problem: it seems that at mouse move over objects in the tree or on the OCC view the number of allocated GDI objects increases very much and when reaching the maximum allowed limit for the thread the application crashes. This is also the cause of some Extrude crashes.


Will start Iteration 0.0.11. The first and the most important task scheduled on this iteration is fixing the GDI leaking. Looked for this problem on older versions of the application and it seems that it appeared also at these versions only that during time the leaking increased from 20 objects per mouse move to 300 objects.

Cancel current action functionality

Added functionality to cancel the current action in 2d and 3d by pressing the Esc key. The action returns to neutral point (ActionNone).

The GDI object leaking bug couldn't be solved it is still blocking the development. Investigated the WeifenLuo library, the OCC objects drawn using wrappers, the property grid and the tree list view.

Will continue with closing the Iteraton 0.0.10 and schedule the iteration 0.0.11.

Test codes

Investigated the GDI creation leaking by commenting code and profiling for memory. Made also two more test codes that verify the show and hide of objects for 1000 times and another test that shows and hides objects in property grid for 100 times.

Will continue investigating this bug as it is important to solve it. In order to finish some of the tasks proposed for iteration will allocate also some hours for making tests for 2D shapes and for finishing the Extrude.

Automatic test codes

Noticed a fact that when the mouse goes over and out of a drawn shape or over an item from the tree list the reported number of GDI objects increases with about 300 objects at every mouse over. When it reaches 10000 GDI objects the application crashes. This is a reason for some of the Extrude crashes but it is not related with the extrusion algorithm.

Verified the PropertyGrid for leaking, the TreeView and also the NamedShapeInterpreter.RegenerateShape(). Couldn't find the problem. In order to solve it, improved the descriptors that display the objects in the grid so they are reused instead of being created at each display.
To test the shape creation for leaking decided to make nUnit test codes for it: implemented a test framework that prepares the environment for testing OpenCascade objects, implemented a test that creates a shape, displays it and removes it 1000 times and it wasn't generating GDI object creation leaks, implemented another test that creates a rectangle in a Node from the data tree then displays the shape generated and selects/unselects it 1000 times, this also is not generating any GDI leaks.

Will continue investigating this problem improving and fixing the code while investigating.

Extrude fixing

Made several fixes at Extrude crashes and at parametric modeling propagation, added the MidPlane extrusion that can be changed from the PropertyGrid. Found the reason why Extrude wasn't deactivating and fixed it: the OnDeactivate() from the Action3d base class was disconnecting the Inputs but because this method was overriden in Extrude the inputs were not disconnecting and were sending events to the deactivated Extrude event.

Will continue with fixing the PropertyDialog that shows messages that parameters are invalid. Will also continue fixing the parametric modeling propagation.

Extrude on Extrude

Finished the code that allows extruding a face of an extrude or of another complex shape that has more than one face. Implemented this feature by adding a SubShape function that refers to the original shape knowing which face it points to. The extrude is applied on this SubShape. It works well on many difficult situations but there are still some cases when it crashes.

Reviewed, converted to clicks and fixed the manipulation tools like global panning, dynamic panning, global zooming, dynamic zooming, dynamic rotation, left, right, top, bottom, front back.

Will continue with stabilizing and improving the existing code on Extrude. Also noticed that sometimes the Extrude is not disabled when another tool is selected, this needs to be fixed.