Folder Paths Updated

NaroCAD installer paths are possible to be set in Program Files/User directory setup like for Windows XP/Vista/Windows 7 machines.
So you may expect that your NaroCAD on Windows experience to be smoother.

OCWrapper Replacement With PInvoke Version

NaroCAD had a surgical change based on the prototype was presented earlier. How will affect NaroCAD?
From user standpoint, will unlikely change it. The wrapper will be a bit smaller, but will make no change in rest.
From developper standpoint, will make possible to build the wrapper and to DEBUG it. The new wrapper also is using open (read: not WOK) build systems, based on XML to declare/expose the APIs, QMake as C++ project generator (even is not a Qt project). The XML parsing to read and expose APIs will make easier to work on long run.
Also, the imported parts are minimal parts we really use in NaroCAD. At the end there are two underlying final migration advantages: we can migrate right now from Visual Studio 2008 to 2010 with a recompilation of NaroCAD (without rebuilding C++ wrappers) and if all work, will be no extra issue. And we can go to 6.5 wrapper stubs in minutes by simply relinking and making easier to debug them, simplifying all runtime based problems we had previously with Visual C++.Net runtime.

NaroCAD New Wrapper Prototype Finished

As said in previous post, I worked to a replacement of OCWrappers and it is made.
How it works: there are three steps build:
- generate a XML API file, this is equivalent of CDL files but is easier to parse and populate. There is a visual tool that will scan from old OCWrappers with reflection and you will pick which methods are used. This API file make distinction between methods and properties.
- from this XML file are generated and updated C# and C++ projects with code. This is the most boring side, but also is where the power stands. The code generator makes patterns of code that are friendlier to debug. Also this part will make sure that the compiled code (mostly C++ side) will not include more than is needed.
- you have to rebuild the updated projects. In a typical workflow you will want to link to the C# project to see if all dependent classes. For now just the string type have to be fixed manually (because strings can be both wide strings and char* strings, two ways or repreenting Unicode and ANSI string encodings). Also, the C++ build is based on QMake (part of Qt SDK) for simplicity.
This design permit to improve all wrapping stack, is also a C# codebase and at the end makes a easier to work with both resulting code and with wrappers in themselves. As when the 6.5 OpenCascade issues will be found, the migration to new wrappers is possible as classes were written in a separate namespace and uses a different naming convention, so from gp_Pnt will get to gpPnt, and functions that return one number, will be likely automatically become properties which make easier for C# used eye.
The C++/C# projects permit to use different compilers (mostly different Visual Studio versions) for C++ side of wrapper/C# side, so makes sense in future to migrate to Visual Studio 2010 (when the C++ wrapper is still using VS 2008) so no binary compatibility issues will be involved.

NaroCAD Wrappers Review. Work on Previewing Sketch Constraints to Remain Persistent

Probably you heard about Xamarin, if not, is not an issue. The opensource .Net implementation (Mono) was forked as the main company did not support it that. I don't want to discuss politics, but I just wish to this new company to succeed and to promote Free/OpenSource as Miguel de Icaza (the creator of Gnome and Mono project) is its owner.
Right now I want to discuss on development on wrappers. In fact, why if things work right, most likely I will try to remove the the original CLI wrappers and to import just the necessary methods/clasess. The design will be a bit different from the actual wrappers and we will try to work using .Net technologies and will extract the information from the existing wrappers.
This approach have many advantages, one of them is the possibility to debug using those wrappers and to make some changes that are at least nice to have for a C#/.Net programmer: automatically using of properties (like gpPnt.X() is better to be used in its property form gpPnt.X and so on), P/Invoke which will make easier to migrate to Visual Studio 2010 (C++ side of wrappers do not need to be recompiled for migrating to VS 2010 for example). This prototype is advanced yet not complete.
This will mean a thing for contributors that were interested in wrappers: is hard for our team to support them and is even harder for every new package to us to investigate why things crash and so on. Also, it make little sense (excluding for making a package) to give wrappers that later will make others' product to crash cause of our fault.
At the end, is just about to separate the codebase and to let as most as possible of C++ behind. If the prototype will not work, we will still use the old wrappers, but if will work (with minimal flaws), we have likely no reason to still use the C++/CLI (aka C++.Net) wrappers. You are still welcome to take Svn snapshot and provide patches and we will include in our Svn tree if you need them and you will want to contribute.
In between I did prepare the code to make previews of constraints persistent (they were shown just in previewing of lines) and if possible to make possible to delete them by selecting and pressing delete. It would be nice if clicking on a constraint to switch automatically to constraint action but this is not also certain.

NaroCAD 1.6.2 (Alpha) Released

NaroCAD gets new capabilities and big changes happen from inside.

This new version focuses on:
- Constraint automatic detection: so drawing perpendicular, parallel, middle of points will create automatically constraints with the SketchSolve based component. Circle/arc based were also added in default setup (yet are not detected automatically) so you can work with more constraint combinations
- a Fixed-Point constraint was done: this will fix the annoyances that a SketchSolve solution will mess your entire sketch.
- Sketch constraints are previewed (now only with line action) and shows texturing capabilities that will likely permit that more components will use in future this capability
- more sketch related unit tests/Boo scripts will work (fixes are still needed but as they are fixed, easier will be to test crashes and inconsistencies)
-it was investigated and a working OpenCascade 6.5 (ultimate upstream version) wrapper was done. Seems that behavior was changed to work with Opencascade so crashes are not from wrapping side (or should be minimalist) but from usage side. We don't support those wrappers but if someone wants a starting C#/.Net way to work with wrappers you're welcome to use them taking the source or the binaries from SVN repository

Download it from here.

Constraints are Fixed, In Two Ways

So constraint preview had a random crash because NaroCAD uses wrappers that obey to .Net virtual machine and this can break references in previews of textures, a functionality offered by OpenCascade using an indirect reference that .Net liked to destroy it. The solution was to stick references to used objects so .Net memory manager (garbage collector) to not delete it. The solution will create a transparent way to store this reference and a good part to it is that can be used in future to all other cases that may have similar crashes (yet this is the first case that was really necessary to not make a really custom development to make it work).

Another development based on work of Sami and bxtrx initially, enhanced, mapped and completed by myself is that points can be constrained. A full action will preview all points initially with blue, and you can constraint them by clicking them and they will transform with red color to know that they are constrained. After that the constraining will not be jumping.
See video here: (made with a virtual machine setup, so sadly it skip frames)

SortedDictionary ...

NaroCAD uses in a lot of instances SortedDictionary and of course this is rarely needed. The reason using it for that many times, is to have good performance profile. For who knows O(log n) search time, knows that performance of lookups is scalable in time with number of digits of the search entries.
But in a lot of cases this is not needed (to have items sorted by key) and as someone informed me, I will use Dictionary generic class instead in future.
Relevant quote:

"Retrieving a value by using its key is very fast, close to O(1), because the Dictionary class is implemented as a hash table." Looks like the query time for Dictionary is O(1), but the query time for SortedDictionary is O(logn) -- "The SortedDictionary generic class is a binary search tree with O(log n) retrieval, where n is the number of elements in the dictionary. In this respect, it is similar to the SortedList generic class. The two classes have similar object models, and both have O(log n) retrieval. Where the two classes differ is in memory use and speed of insertion and removal."

So, for your better writing code, use Dictioary always.
Fixes are made lately so most of your Boo scripts will work as sketch code is automatically handled, more shapes will also work. Dangling texture rectangles shown in preview of automatic constraints were fixed and are display and will disappear at the end of your design. There is a crash of .Net/C++ memory management that will be fixed before release in this area.

Fixed point constraints

Because the solutions found by the solver algorithm move all the points of the constrained shapes and there is no fixed point constraint we had to implement one.
Implemented a fixed vertical and horizontal point position constraint, made tests with it and it seems to work well. Adding this constraint to Naro will be a must have feature added probably on next week, this will enhance a lot the solver solutions - currently the constrained shapes "jump" on scene because of the solver solutions found.