Monday, May 31, 2010

Point to Point Constraint Improvements and other fixes

Point to point constraint was fixed, but was hard to use and some unexpected results did happen: when you pick those two points, the action did move your shapes to match this point, and you could later make it place where you want.
As bxtrx did come with a better usage idea, right now the points are constrained when you pick them on the shape, without moving the shapes, and you will be able to edit distance for your convenience. In this way you can constraint points without going to Property Grid but also you will have the ability to change it later.
This week starts the bug fixing week, and some bugs were fixed like: cut and extruded were constrained to not work on some shapes, but on which Extrude (or cut) can really operate. For example applying Extrude on a pipe, was not possible, because this shape was not considered extrudable. This part is fixed right now and you can enjoy working with extrude unconstrained. Anyway, Extrude is still restricted to extrude shapes as sphere, or the rounded face around the cone or cylinder, but the filter is much much weaker so the cases of false positives (when extrude tool was possible, but NaroCAD forbids you to do so, to avoid crashes mostly) will be practically none.
On a similar note, the action activation/deactivation was affected on some extend from command line refactor (that permits all actions to get access from CL) and I hope those bugs are also addressed. Some extra testing still need to be done, but fixes on this area seem to be in place.

Friday, May 28, 2010

Point to Point Constraint Working

Point to point constraint is working right now. Even the action was done previously, it did not succeed working for one reason, the way that transforms work and how NaroCAD handle it. In short NaroCAD store two items as information for shape's transformation. One is the transformation matrix itself and the other one is the pivot. The pivot is the "origin" of the shape.
When the old code worked, it tried when you picked two points, to adjust the pivot to be aligned with the difference of the point. The problem was that the pivot was adjusted with overriding the pivot itself, instead of doing add/substract of coordinate difference. That made when moving the source shape, the second "follower" shape, will simply jump trying to readjust the ever changing modified shape.

Updating NaroCAD website

I've started updating the NaroCAD website to contain more useful info about functionality and development.
You are now able to download the current release of NaroCAD, and older versions directly from You will find also an link to our Nightly build.
There is also and some text file which teach you how to build and run NaroCAD on Visual Studio or SharpDevelop. There is also posted our first video tutorial; in the future we will add more tutorials.

Thursday, May 27, 2010

Solver cleanup

Started cleaning, updating and fixing the solver code. As many changes occurred during time the solver needs some work to be made fully working as it previously worked.

Fixed and enabled the same height solver code. This code detects cases like when the user wants to make two extrudes having the same height.
Fixed and cleanup also the solver dialog that allows using the check boxes to enable and disable the solver components.

Will continue with fixing the point detection algorithm problems. Like in some cases the rectangle has only 3 magic points for the 4 corners. Planning by tomorrow to finalize this task and then continue with the shape editing task.

Wednesday, May 26, 2010

Solver unit tests

Fixed solver unit tests and added them to be executed in the installer script.
The tests cover the plane, point and parallel detection.

Tuesday, May 25, 2010

Improved Unit Tests

I've added some new meta actions and transformation tests for normal, parallel, vertical, horizontal lines, boolean operations. In the future more tests will be added for Command Line parser.

Monday, May 24, 2010

Editing Code Review

Editing code was reviewed to fix it and to make possible to add custom tools for the selected shapes that makes sense. But the code did not work that right because of separation between editing component and actual mouse handling (like face picking functionality). Also, those tools will paint everything in a custom document, meaning that they can bring a lot of functionality in a consistent way without letting things trailing in the actual document, and also is based completely on NaroCAD code, which gives another good things to work on). I will hopefully soon make a concept that works and I will show the progress as soon as possible.

Friday, May 21, 2010

Unit tests finished.

I've finished to make unit tests for MetaActions and Transformations for most of the shapes. A few has remained do be done. I hope to finish them the next day. The good part of this is that all tests run when any release or night build is made, and if any test fails, the release can't be made.

Thursday, May 20, 2010

Pipes and Inputs Cleanup. Line in Polyline mode. Others

There are some design limitations that are for good reasons but some of them may appear silly to some. One of those limitations is that MetaActions (which are automatically generated actions based on defined dependencies) can be filled by command line when Actions (the tools/shapes that are defined as requiring resources from NaroCAD workspace) cannot. On the other side MetaActions cannot work with multiple nodes at once, just with one current node.
The polyline tool can work in two modes: simply as one shape, and NaroCAD can fill it as a meta-action (and will operate more or less as a spline), or can work as an mutiple lines shape. The first way of thinking have some advantages, but also disadvangates: the polyline, being one single shape, will make you annoyed if you want to delete just one edge that is drawn by mistake.
But on the other hand the line in polyline mode will miss the command line features.
So the changes to make both actions (line in polyline mode and polyline) did face some need of change. The biggest is that command line may be accessible to regular actions, but not only command line control but also the parser. Those changes are more subtle from the user standpoint, but in short if the parser will have changes (like supporting just two coordinates), this will work for all actions (and metaactions) without making necessary for every action that use command line to parse the string that command line gives.
For my bad the polyline itself have some issues and I did not fully tested the parser separations but I will target those fixes tomorrow (hopefully will be fixed all together).

Tuesday, May 18, 2010

A Handy Command Line Point Input

If you input points you may be used to write just two coordinates (and the third coordinate to remain Z = zero). Latest changes allow for parser to accept just two coordinates, as well as three coordinates. Also the command line dialog ongoing work will improve how it work with the parser and as a effect, some other actions that were not working as meta-actions, will be able access not only command line dialog, but also the parser (to get points coordinates). Wait for more updates soon.

Saturday, May 15, 2010

Code Cleanup and What It Means

NaroCAD did grow a lot quite a bit as a project. It has a lot of code to play with and in a lot of cases the code was written at different levels of experience and some mistakes were propagated again and again. A simple mistake that NaroCAD codebase has is this:
void SetData(object data)
var mouseCoordinate = data as MouseCoordinate;
SetMouseCoordinate(mouseCoordinate.X, mouseCoordinate.Y);
If by mistake the method SetData will be called with another class (like a Point3D instance), your runtime error will be a NullPointerException at accessing mouseCoordinate.X (for dereferincing null value).
This code should likely be written as:
void SetData(object data)
var mouseCoordinate = (MouseCoordinate)data;
SetMouseCoordinate(mouseCoordinate.X, mouseCoordinate.Y);
where conversion is explicit. In this way the exception will be more explicit (that will state about invalid conversion) and the code will be more compact.
How can be done those changes right? Probably there is no simple way, but I've used a tool to discover them. From the total around 5000 introspection errors (like previous one), I've reduced to around 2500 ones, but keep in mind that not all code is NaroCAD code, and some external components cannot be fixed that easy and fixing them will bring no code quality to NaroCAD project itself. Also, as any tool that do automatically scan, it give false positives (for example the reflection solved methods are in many cases detected as "unused", but in fact they are used directly by their name - in case of events or of Lua script commands) so this will mean that at the end most execution crashes will give more sense.

One last note is that for some reason Visual Studio 2008 Standard (not Pro) gave an error of invalid project file at some test unit assemblies. I've regenerated them creating by hand the same project in VS Standard and seem to work. In this way those folks which use Standard version because is lowcost and do not want to use Pro version or SharpDevelop (an opensource C# IDE), can build also the test units for solver component and application framework.

NaroCAD 1.4.4 Released

NaroCAD evolves constantly and makes big steps forward as always. This 3 week from the moment of release 1.4.3 it did improve a lot on quality and is the most stable release to date and also the most featured one. In this release you will see not only bug fixes, but also another user visible changes as:
- Ported the property grid to WPF
- Added radius constraint, rectangle width and height constraint
- Fixed transformations from property grid and how transformations work internally
- Shapes can be selected also from tree
-Added capabilities functionality. Tools are restricted on what shapes they work on.

You can download this release from here.

Friday, May 14, 2010

Finalized transformations fixes

Finalized fixing all transformations, shape drawing problems. Also the property grid transformations modifications are fixed. Merged all code with latest fixes and pushed everything on devel repository.
Naro enters now to final detailed testing to prepare for release.

Thursday, May 13, 2010

Dimensionable Shape Defined

There was as bug that Dimension tool works on shapes that should not work, the most affected ones were: Horizontal Line and Vertical Line. In general all shapes that are tools in themselves may not want to accept dimension. Because we have already the restricted shape capabilities, I was made all shapes to accept dimension. In this way we can guarantee that in case that dimension do not work today (as is on Torus) to not also be enabled (for now). For this reason the intermediary subshape that dimension have was removed also.
So clicking on an shape that do not accept dimension will simply fail.

Finalized transformations

Finalized modifying all tools to use transformations. Fixed also drawing animations to use the transformations when calculating positions in scene.
Added automatic unit tests for transformations at Line, Circle and Sphere.

As the transformations changes had a big impact on many areas of Naro the changes will stay tomorrow on bxtrx repository and if the code passes testing will be moved to devel branch.

Wednesday, May 12, 2010

Delete Shapes Logic Changed

Delete tool was a working component that have it's really strong point but also some shortcomings like: some chain of shapes do make some kind of shapes to dangle (like if you delete a rectangle and attached to it was a dimension, this dimension was simply inaccessible to delete and remain as artifact in scene). In the past the deleting was done like this: hide the shape, and if the shape was unreachable and all it's shapes that are unreachable, they were removed.
As right now it explicitly lookup of it's dependencies and it's referees and makes the deletion more consistent and hopefully glitch free.

Tuesday, May 11, 2010

Fixing a 6 Month Old Bug

There are bugs and bugs. Some bugs really stands out. This one was a love/hate relation because was as simply untouchable: I was need to select a rectangle from OpenCascade view and I had two options: to make it flicker or to make not update at all. Those two solutions make to appear the Zoom Window tool to work.
The cause was that mixing OpenGL view from OpenCascade with GDI+ from System.Drawing do not work well.
Right now the selection works nice using a workaround (using a transparent window on top of NaroCAD application) and no API mixing is involved. All other solutions (like picking double buffering to parent control, all known APIs of OpenCascade to make flicker free) do not succeed.
So enjoy using this new selection.

Meta Actions Transformations

Started bug fixing the beta release version. It seems that this version is quite stable having 49 bugs opened (compared to 104 previous version), majority of the bugs being low priority.

A problem that I am currently working on and will fix many problems is incorrect transformations on shapes. On Naro the drawing concept is that the shape is drawn located in 0,0,0 as local coordinate system and represented on scene in the global coordinates system as being translated to the position where the user made it. Tools like translate, mirror only work on the transformation matrix and don't affect the original shape.
The majority of tools after being ported to meta actions (integrated with command line) where generating shapes using the global coordinates and not applying transformations.
After the transformation were enabled, final shapes work but at live drawing the shapes are made in the origin of the global coordinate system, which is a bug. In order to control this bug made some automatic unit tests so after fixing it any future problems will be monitored by the unit tests. Will continue investigating this bug as it seems difficult to find.

Monday, May 10, 2010

Solver Magic Point Fixes

Magic points help you to get things easier but when they work wrong they just make your work just worse than using them. For this reason, the shapes that did get most of points wrong (exactly the Cuts and invisible shapes) they will not generate solver points and the annoyances hopefully will get better.
Also a small fix change was done in document format (again) and this hopefully will be more stable for future so you will be able to use for a longer period NaroCAD without throwing your old work.
The nightly build will be a beta release for 1.4.4 and as far as it goes it is the most stable build from all builds we have for a long time, so if you will want to try it, you will help to pinpoint even harder problems that we did not take in account and all will benefit. The nightly build link you can find on the right and you can get the most up-to-date build that is mostly in sync with blog developments.

Sunday, May 9, 2010

Restricted Extrude Improved

Restricted shapes are implemented at two levels: at NaroCAD shape level and if wanted the restriction on using references can be implemented with separate logic on OpenCascade level. The second one is more powerful, but is to get cases that were not handled by the high-level restriction.
A simple case: you extrude a circle and you want to extrude the rounded face. Extrude will try to make it but it will fail.
This improvements will check if the face you clicked one is a plane one so Extrude will report the error on surface, even theoretically the extrude can operate on this high level shape (an extruded one).

Saturday, May 8, 2010

Point to edge constraint

Implemented point to edge constraint function. It seems that there are some problems related to translations (object transformations) and this feature affects also the constraints. Will fix first the translations and then continue finalizing the constraints.
Pushed to devel repository all features and fixes made until now. Will start preparing for bug fixing week and releasing.

Friday, May 7, 2010

Old Property Grid is Removed

The Windows.Forms Property grid was removed as it duplicate the WPF contextual property control. Also some code was rebased to corresponding namespaces from project. As NaroCAD solves properties via reflection this will mean that old files will not be compatible with actual version. Just if you do an update, take some time and backup your work and do the install in a separate folder. A test build will be available next week and testing will occur with the found bugs, so you will be welcomed to test the new release and to give the feedback over the new build.

Face picker blocking

Updated the meta action tool so that the plane picker is suspended when Ctrl key is pressed. In this way a shape can be drawn in the same plane over other shapes without the face picker to catch other drawing planes located under the mouse.

Thursday, May 6, 2010

TreeView Selection

If you will try the nightly build it will give to you a better way to work with tree: you can select items directly from here. This mean that you can extrude shapes you cannot see previously as they were hidden by other shape.
This will also simply selection of shapes that are blocked by OpenCascade selection bugs (like if you have three juxtaposed shapes, sometimes the OCC selection will just work random).

Finalized line tool automatic test

Finalized a complete unit test for the line tool meta action. Simplified the code so that the tests can be easily extended to all tools.
Currently the tests cover a simulation of mouse clicks and also checks the data tree integrity. In the future test might be extended to check also for drawing animations.

Wednesday, May 5, 2010

Restricted References Completed

Tools and constraints in NaroCAD are mostly based from different shapes. Combining them in a wrong way can make OpenCascade or Naro to crash. As for now they are restricted to work just with known shapes.
The single part that was not great was that it used a concepts&capability code that may be hard to be understood by "outsiders" because you have to setup your mind differently. Because of this, there was exported all those logical constraints in a separate external file that can be edited by hand and which have a fairly clean format to read (similar with Domain Specific Languages but was done with a much simpler "parser" than regular DSLs).
Property grid can be considered fully migrated to WPF, from the advancements are:
- search and focus when you press enter to a specific property
- instead being a combobox, it is a dropbox (meaning you cannot edit items)
- resizing is much faster
- the line for editing a point3D have a more consistent X, Y, Z way, than was previously
- transparency is setup via a slider
At the end most likely more constructions that were prone to errors will be removed in the next release. Till that moment you may test the nighly build to get a proper feeling by trying to crash Naro. Also, this nighly builds have a way to report bugs under the Options pages (go from Ribbon "start" menu, Options, and at the end you may go to report bugs page.

Monday, May 3, 2010

Line tool unit tests

Succeeded to finalize a unit test setup for the line tool. The unit test simulates automatically two clicks that draw a line and goes successfully from beginning to end.

Will continue improving the test so that more tests are added to check that Dependencies are properly set, that the Function execution succeeded, that all event notifiers are launched properly.

Shapes Restriction Framework Update

Previous work on tools restriction was focused to force shape references to accept invalid combination. But the mapping was valid under the document (model level) but was not accessible and handled from the action level.
For now the meta-actions (the actions you click on) that have invalid references will point to you error on accessing it.
I will update the constraints mapping so most shapes will not bring NaroCAD down.

Sunday, May 2, 2010

Point to Point Constraint, Shape Restriction Framework

Point to point constraint code was done. The code is still far from perfect (it have some bugs that seem to appear like a random jumping around the area, so may be a logic point).

Even the constraint is important as constraints were introduced and they can make NaroCAD a more than useful tool by supporting a lot of operations, sometimes the problem is that a lot of testing and crashes are just because of incompatible operation of different objects. For example you should not apply a constraint like: Line Length Constraint on a circle shape. You should apply it only on a line. Because of this the code behind was extended to support for references on your operations at two levels:
- a logical (high level) one, like: you can pick the reference shapes and the operation that applies to
- a reference based (low level) like: you can write your custom code to accept/exclude a shape from candidates
Also this works as previously code for shapes that you don't want that this extra checks to occur.

I will try to work in two directions: try to integrate this work to actions/meta-actions to use explicitly this code to give to user information like: "Incompatible shape to this operation".
This will be nice to avoid known crashes of NaroCAD code or of OpenCascade operations.

You may check it using the nightly build.