mms

Does your project read/view DXF files without any ACAD dll's?

Did you really dump your "Old VB6 2D CAD package" in the recyle bin?

Gruff

Well. Looks like you have been giving this a lot of thought.

My goal in making the viewer control was to build something a step beyond the picturebox control but not much. My dividing line was to keep 99 percent of the user interface in the container.

The Viewer Control performs and gives some mild feedback.
This way the a programmer can design any kind of interface desired. As you pointed out in an earlier post the original viewer app looked different than the simple CAD example.
They were. It was easy to knock out a new container that worked differently on the same control. In short the control is meant to handle the complexity of working with 2D vector CAD entities. The container was meant for the interface.

BTW if I had thought of a decent way to keep the translator outside the control I would have. it shouldn't be inside the control IMHO.

If you want a control that has the interface built in then I would suggest you do what I did and Start another class which inherits the Picturebox_2D_Cad control and extend it as much aa you like.

I hear you about vision issues. I am heavily diabetic and have cloudy vision.
BTW the cursors I provided are there for a reason. They show the user what snap is currently selected without taking up any extra screen space.

Zooming by keys and mouse are just a perk. As you can see in the example app they can be accessed by other means as well. ZoomExtent IS the state the part when loaded.
A public ZoomExtents is available as a method.

Since the control was designed to use three values to control zoom and pan. Views can easily be saved and restored. One could keep an array ot them to allow a perusable view history. To do this I guess I would add a View() method that used those three parameters to the control. This way several different view history could be designed and maintained by the container.

Just a note. The web site SketchUcation.com has a plethora of user generated utilities Fillets, Corners, intersections, transorms etc... Someone even made a sheet metal unfolder. You have to make a simple account with them before you can download the tools. I've got over 100 of them. I wrote a tutorial on how to write VB addins for Ruby.
Their built in program language. It ends up a bit nasty but workable.

They also have scads of tutorials. I found one on how to construct with real world values instead of eyeballing everything. Nice.

Gruff

The sample viewer control does not use any ACAD components.

Yup. As stated there are scads of ACAD Editor clones out there. All of them better than what I was working on. A number of them Free.

I only created this viewer control as there wasn't anything available for free that I could shoe horn into my custom manufacturing Barcode Viewer. That or they were ActiveX based components. VB.NET Interop doesn't always play nice with them.

Hence a VB.NET Winforms based control.

See Attached Pics The Last Pic is my Viewer Control in the Bar Code Viewer being used by our Press Department to verify bending locations on a flat sheet metal cut out.

surfR2911

I'm sure that's not true!

I noticed the Private Sub LoadColors(), under ImportTools.vb (where the DXF file loading and parsing routines reside), that you hard coded the rgb values for the standard ACAD colors.
Here's a webpage that shows the actual colors involved.
Yes I was thinking about this also..it is somewhat "awkward" from a design standpoint, but I don't know if anything can be done easily/quickly to resolve this.
Yes, "3" did seem quite arbitrary, but I'm still working my way through creating/raising custom events in custom user controls --creating methods in custom user controls are next on the list (thank goodness .Net doesn't have all that property bags boilerplate code that creating custom controls under VB6 had..I did find this and this and this though).
I understand your reasoning for this almost total encapsulation, based on the way you are using the control
in your Bar Code Viewer, but it makes it hard to open the control up to other possibilities/enhancements (especially from an altered gui standpoint).
Actually that will not maximize my learning opportunity for exploring user controls. I was thinking of going all the way back to a plain PictureBox control and build from there to see if I end up in the same place you arrived at.

I noticed a comment in Private Sub oImport_AddToLayerList of the
PictureBox_2D_Cad.vb code:I definitely do want to display a list of layer names.
So how is the oLayers list related to the LayerName Index?
Can I use an index (number) to access the oLayers alpha text name?

I know your code is probably very well thought out from an OOP principles point of view, but right now I'm trying to wade through all this entities code trying to figure out how to generate some kind of object hierarchy diagram in my head.

Gruff

I hope you are not trying to use this control as a shining example of a user control.
As a port it is a devils blend of New and old programming practice.

You would be much better served writing a few sample classes of your own to get a feel for VB.NET OOP.
UserControls retain all the features of a standard classes. This is to the good.

I am having trouble fixing your level of knowlege about VB.NET
Where are you at specifically? I'm about beginner to average on the topic.

---
AutoCAD and most Autodesk products have a ton of features and options.
To match them all would be a huge task. I settled for a sub set the met my needs.
I really have no further interest in working on the Viewer control myself.

I am willing however to lend you support should you need it in your efforts to rewrite it.

1) Autodesk supports the export of a custom dxf attributes map file.
I could have had this read from disk, but not all dxf exports have them.

2) Importers could be written in the container and the full list of resulting
viewer entities could be passed into the control by reference.
Not sure what this does to memory considerations

3) 3 variables. (2 really) ZoomScale and an XY Offset Point.

4) Yup. Rewrite it anyway you like.

---
5) Each Entity contains a Layer Integer property filled at import.
At the same time the layerNames List (of String) is populated.
Also Populated is the SelectedLayers list of integers. (All layer numbers)

In the container after you open a dxf ...

To show a different set of layers in the control we
clear the control's selectedlayers list then loop through the chkLstLayers check list box and
build a new control's SelectedLayers list of layer indexes. Example 0,1,3,9,10,29


When the control redraws it filters on the SelectedLayers list.

surfR2911

Since Microsoft's VB6 to .Net "migration tool" was so really horrible (Microsoft should have basically just bought up ArtinSoft and incorporated it's VBUC software into .net at the earliest stage possible in the .Net evolution),
I have concentrated mainly on converted my existing code base of VB6 code to unmanaged C++.Net code.
Many commercial software vendors use this type of .Net code and so it is unlikely that Microsoft will pull the rug out from under them overnight, so I've considered it a "safe bet" up-to-now.

Even though I have had a personal policy of not releasing any VB.Net code public (sort of my own way of protesting that Microsoft never came out with a separate and robust "bridging" utility for VB6 to VB.Net conversion), I have nevertheless "kept my toe in the water" when it comes to VB.Net.
I find it much easier to work with GDIPlus in .Net then in VB6, for one reason.
Plus I always download and play around with all VB.Net code that passel is kind enough to post.

I'm also "beginner to average" (maybe slightly below average) on VB.Net.
(of course I already sensed your level and that is one reason why I used your code for guinea pigging instead of, for instance, some of the advanced code divil has in the dot net sister forum's knowledgebase/code library.

The inclusion of XNA support for VB.Net has me hopeful that certain conspiracy theorists are wrong in suggesting that Microsoft has purposely use the ".Netification" of VB to kill off a product (the "classic" line of VB ending in VB6) they were no longer interested in supporting.
VB.Net still doesn't have full GSE (Game Stdio Express) and Xbox360 support, though, so it's long term trajectory still remains uncertain in my view.
I do realize this
I appreciated this greatly and I know that you have a day job which limits how much time you can spend on this one thread. Please feel no obligation to respond to any of the subsequent posts I may make in this thread. If you do choose to respond also feel no obligation to respond in a timely manner since it will take several months to complete my exploration of the possibilities of you code. Put responding to this thread at the very bottom of your priorities list please.

I will continue on with technical stuff in a follow-on post..

Gruff

I still hammer out VBA Code Projects in Solidworks, Inventor, AutoCad, Sigmanest, Excel, Access, various Cam programs and more...
As I have on going feature creep apps I am expected to support until dooms day.
Many of these apps tie together, streamline, and reduce effort for engineering workflow.

It's a good reason to get up each morning.

i am making an effort to write replacement addins in VB.NET but the development cycle is soooooo slow. I dabbled in VSTA but it looks like it faded softly into the night. *sigh*

All of these have links to CAD or Solidmodeling at some point. Last year a knocked out a GCode to Acad importer for our Laser GCode in those rare instances we have a customer that sends us GCode as data. Also a Laser GCode Generator in ACAD that can produce GCode arrays.

I think it is safe to say I will be working in mechanical engineering software for some time to come.

surfR2911

Now that the "where's I at" part one is out of the way, onto to coding matters.

Thanks for the code regarding layer indices.
This is an issue.
Even more important than my VB.Net coding level,
my level of understanding of ACAD products in general is somewhat limited.

I have played around with dxf and dwg files. I even had an old version of AutoCad..like one of the AutoCad 2000 version after AutoCad R14 if I am remembering right..that I used for some manipulation and plotting of PCB designs when I was in school.
(Autocad version-ing references: AutoCad version release history and release timeline)


However, there is are difference between AutoCad and the AutoCad Architecture.
Here's a blog post which goes into that a little.

So I have to admit that when it comes to ACA (AutoCad Architecture), my understand is pretty abysmal -- strictly at the "overview" level of that linked to wiki article.

Of course I know where the ACA root page is on the AutoDesk site, which leads to the Support & Services documentation section (version specific of course, which makes it tough to establish lowest common denominator capabilities).


Anyway, in terms of adding code to the DXF Viewer, one thing I'm trying to do is increase the robustness of the dxf file handling.

There are standard VB.Net code file I/O routines that can be added to the file error handling code to do rudimentary tests (0 bytes, lack of EOF, etc), handle parsing of pathways of DXF files on remote servers, and give return values specifying entries from an error code look-up table.
All well and good, but what if the DXF files being opened are not generated by AutoDesk products.

I have tested the DXF Viewer agiains several dxf files found "in the wild" (downloaded from the internet).
Have you ever dealt with Sonnet DXF files?
Here is a link to the sonnetsoftware site (and their CST Suite), but I haven't fully been able to detail the differences between a sonnet dxf file and an AutoDesk/AutoCad dxf file.
I also use Illustrator and CorelDraw to generate dxf files as well as certain converters which are used to convert a whole bunch of vector formats (Gerber RS274X/D & GDSII, HPGL/2, IPC350/356/356A, CIF, IE3D, etc.) to dxf files. Those dxf files do not look (internally) like your sample dxf file, although there are similarities.
Sections can include: header, classes, blocks, entities, objects
There's also seems to be at least 9 different types of tables and a thumbnail image.

By "robustness" I also mean I would like the DXF Viewer to be able to handle whatever type of dxf file thrown at it.

Of course I know your humble envisioning of the DXF Viewer for your own purposes never coded for this,
but for my special tweaked version should, at minimum, have:
1.) Some way to detect if a DXF file is corrupted and have some kind of escape code that will return an reasonable error message that will help give a human user some idea if the file is "recoverable" or totally corrupted to have no usable sections.

Note: I noticed there is a "sniffer", which tests dwg files for possible corruption on this page..is there something similar (that you know of) for dxf files?

2.) A way to detect if the dxf file is a "well formulated" dxf file.
It may have sections that are "non-standard" from an AutoDesk specification framework, but any such sections should be gracefully "skipped over" or ignored (except for noting them in an auto-generated "errors/exceptions" log).

So the question becomes, I'm sure the code you developed to read dxf files was based on some kind of AutoCAD/AutoDesk documentation of dxf files (I'm thinking perhaps of this AutoCad 2002 dxf pdf as well as the pdfs found on this page).

However is there some non-AutoDesk movement to establish dxf has an "open standard"...like the opendesignalliance has tried to do with the fairly proprietary dwg file format --or like Adobe's proprietary actionscript specification is represented as an open, non-proprietary, version of the ECMA-262 (ECMAScript) public standard?

surfR2911

Definitely sounds like you are keeping busy --and it's nice to have job security, even if the tedium level (I'm sure) can get high sometimes..

Gruff

Welcome to the club. I too am a novice with much of it including DXF. Autodesk does not go out of their way to document or explain the internals (Or their API's) It was never their intention for DXF to become a standard and definitely NOT their intention that it be open source.
BTW ACAD is a Product. AutoDesk is the company.


This has been a huge issue for all cad formats even before PCs. Mainframe CAD packages did not talk to each other at all until IGES (International Graphics Exchange System) was formed. Even then many CAD manufacturers ignored it. The grandchild of that is the STEP format which many PC Cad packages can handle today. The only flavor of DXF that you can count on to be a standard is the one from AutoDesk, and even they change it up from version to version. Essentially the driving force has been for CAD companies to try and make their products Propietary so as to keep a strangle hold on their customers. Anyway you slice it getting all flavors of DXF to work is a very tall order.

I believe there is even a binary form of DXF or mixed text and binary.

Sound good to me. In the standard Text based DXF there should be SECTIONS. My quick solution was to tap into only the most basic of these sections. Level Defs, Line Style Defs, Entity Defs. EveryEntry in Text DXF is in Pairs. TypeCode and Value.
Value always follows TypeCode on the next line.
Sections that support complex entity types are more convoluted. If I couldn't figure them out I just ignored them. So I have no insights as to their structure.

The only way I could get a better understanding of the format besides reading autodesk's glossed over description was to create a sample dxf with only one or two entities. Then examine the results. Whatever you write be aware that some dxf files may not include all Sections or sub sections or for that matter thumbnails.

I know of the opendesignalliance. I believe that autodesk has been trying to legally stop them from infringing on their intellectual property. Part of the alliance is based offshore so they still exist. The ODA is not free to join. They charge (The last time I checked.) a substantial yearly membership fee.
In any case if Autodesk changes the format ODA has to follow along to read the latest Acad verson data.

On a tangent note. I've never liked the dxf format as it IS overly complex for 2D vector graphics. Like many Autodesk products they try to drag historic products into the futuer while maintaining compatibility and features.
Sometimes it is better to start with a clean slate.

Cadkey's CADL was a remarkably clean text based 3D wireframe file transfer format and would have made a much better standard.
All Arrays were defnined at the top of the file and all entities were defined on full lines in the bottom half. The trailing values are entity attributes like color, level, linestyle, etc...

surfR2911

Yes I am running into the convoluted entity types in some of the dxf files I've found.
I'll just have to arrange the code to skip over them if they are not documented somewhere.
I was afraid you would say that.

Cadkey's CADL looks like a good candidate for a file type to support.

Gruff

I've been giving the importtools some thought.
In the current version the importtools class creates a new entity based on the Entities2D Class then raises an event with the new Entity. In the PictureBox_2D_Cad class the Entity is appended to the oList variable

ImportTools ---> NewEntity ---> Event ---> PictureBox_2D_Cad --- oList.Add()

If we add a Public method (Sub routine) in the PictureBox_2D_Cad control that adds entities to the oList variable we can move the ImportTools class to the container.

Container ---> NewEntity ---> PictureBox_2D_Cad.AddNewEntity() ---> oList.Add()

The control would have to be documented well enough that someone writing importation code would knw the requirements for the PictureBox_2D_Cad Entity data. For instance some CAD systems store Arcs as StartAngle then End Angle. Some allow negative values others do not. Units could come from Radians, Degrees, Inches, mm, cm, meter, Etc..

I am storing the data in the viewer as Inches and Decimal Degrees.
Arcs are stored as in AutoCad DXF (StartAngle then Delta Angle).

surfR2911

I already made this change playing around with the code - since the Entities2D Class was too tightly coupled in the original code.
Yes I already ran across this and this. From my preliminary testing not a lot of the files I found had negative angles so my preliminary assumption was that support for negative angles among various CAD programs is relatively low.
Sloggin through the online DXF documents I came across this and this and this. Of course there basically the same, but in terms of what you are talking about "decimal degrees" there is this paragraph:
However, what you didn't tell me is the really important stuff like:
...from here.
Knowing this definitely helped make more sense of some of the older dxf specs.

Some pseudo-coding (if additional vector file formats, besides dxf, are to be considered):
1.) In cmdOpen_Click sub, add additional filters for different cad file formats
Change CAD1.OpenDXF to CAD1.OpenFile

For new "Public Sub OpenFile", alter "Public Sub OpenDXF" to do the following:
2.) Look at file (don't make any assumptions about file based on one of the CAD file formats selected or the actual extension to the file).
3.) From lookup table of characteristic of different CAD file types, decide what routine should open/import the file (using select case statements logic?)
4.) If file type is DXF, then perform validation for proper well-formulated, DXF code (including whether ASCII or Binary perhaps)
5.) If anomalies are found try to match dxf file internal structures to closest known (stored) dxf file configuration/structures.
6.) If it looks like Autocad/AutoDesk generated DXF, then use the existing code in the "Public Sub OpenDXF"

So in handling processing of multiple CAD file types should I roll different sections of the PictureBoxEx code (entities2d, math, etc) into a single encapsulated "HandleDXF" code class (so there can be code classes for each file type),
or is there enough "crossover possibilities" to say, be able to use the Math and Entity2D classes across those multiple file types (not encapsulating similar code into multiple, separate, class handlers of each file type).

Right now I've got a whole bunch of "virtual coding" thoughts like this flowing through my head and I'm still researching for other examples of how such things are structured in other VB.Net code projects.

Gruff

All supporting classes except importtools are geared to work with the control entities2d class. If for example a Cadkey importer were created all Cadkey entity types would be converted to entities2d types. The entities2d class would have to be extended to hold all 2D Cad wire frame constructs you wanted to import. For the most part there are not that many base types. For instance line entities might be stored in external formats as vector and magnitude or expressed as a Bezier spline curve. If we are only talking about a viewer all of them can be converted to our viewer line2d class. This doesn't mean that the vtewer should exclude Bezier spline types, but only store and display geometry if it is explicitly denoted as such in the imported file. Like any software project though I think one has to put design limits in place or it becomes a nightmare to maintain or update. These other formats are moving targets.

I'd limit the viewer to 2D wireframe mechanical engineerig or 2D wireframe architectual but not both. For Winforms I'd lean toward the former as architectual files can drift into the gigabyte range and there are drawing
speed limits with winfurms. WPF Forms are suppose to be much better, but it is outside my experience.

surfR2911

That's the good news. The not so good news.
Plus there aren't that many 2D wireframe architectural out in the open on the internet (and being in the gigabyte range means they probably aren't emailed around too often - thinking about the cybercafe surfer that is one of the target audiences mentioned earlier).

I'm attaching some DXF files for code testing. Each of these was connected with a specific DXF viewer coding project (so they all "work" in the specific DXF viewer designed for them).

You probably already know that searching the internet for VB.Net DXF viewers produced few results, but there is a limited set of VB6 DXF viewer code available. I would note that I found the Tufts code easy to understand but very limited in terms of general DXF viewer functionality.

I am also running issues with BLOCK INSERTS.
From what I've read:
So..what can I do if I find more than one INSERT entity with the same block
name? How do I know which one applies to each LINE, since for a given block
name there is only one BLOCK structure in the blocks SECTION but in
some cases there is more than one INSERT entity in the ENTITIES
section.

There are several non-AutoDesk convertors I've tried that make somewhat of a mess when doing dwg to dxf file conversions. It makes dxf validation..well..not a trivial task.

Gruff

Not email, but by ftp or similar transfers. We routinely have to deal with files that can describe a 10 story building in excruciating detail. Many contractors can not be bothered exporting a single kitdhen or clean room on the 4th floor. They just pass along the entire file from the architect as is.

Think of a block of entities as a group. The viewer stamps them at xy locations about the drawing. Copies are rotated, Scaled, Etc... if needed. When redrawing the display you run through the inserts. get the single stored block that is referenced by name. run it through the insert transfom matrix and draw it at the insert locaton (Based on the block origin.) You do not translate the block into copies in the oList storage.
This is going to make snapping to entities within the displayed block instances much more difficult. As a matter of fact I do not have a clear idea on what kind of structure to store blocks in except that it cannot be in the oList. (Inserts would be in the oList)
Off the top of my head I guess oBlockList would have to be a naned list of entity lists

surfR2911

Yes much more difficult.
I was afraid of that.
Named lists of lists -that sounds tough to code when considered the entities snapping within block structures, and I don't know what your thinking is in how oLists would relate to oBlockLists (since the insert parameter references the block of entities, yes?).

I'm just thinking about how this complicates the pipeline of the layer rendering.
It's probably a stupid question, but when considering block entities as a group could you have multiple groups per layer or have to keep them in separate layers?

Gruff

By Definition Blocks can be created on one or multiple layers. Remember Blocks are just a group of entities with some extra information. Each Entity in that group has a layer property. (Or attribute if you prefer.) Autocad users routinely create blocks that have entities on multiple layers.

As it is a new day and my brain has reset... I guess you could also store the blocks at the end of the oList. The End of the raw list and the start of each block segment would have to be stored in a table with names and offsets. Reading the raw data for display would have to stop before the first block segment. Insert Entities in the Raw Entity Segment would trigger a table lookup.

On the other hand perhaps for purposes of this viewer you could create each block as its own set of geometry in the olist as it is today and not worry about memory considerations. The only thing the viewer has to do is display and measure. Any other block features as they are exercised in ACAD do not apply. For example when selecting a Block Entity in Acad the entire block is selected.

---
Blocks have specific uses in industry where they make a big difference in data file size and memory storage of cad entities.

I'm thinking of chip manufacturing or electronics where you might have a circuit or component that has to be generated or arrayed 1000 or more times. In Architecture doors, windows, Fixtures and other components. In some mechanical engineering screws, fixtures and purchased components.

As an aside not every CAD system has this form of blocks. For instance under Cadkey they called them patterns and did not store them inside the main file at all. They were always external files. If you created a dxf I believe it exploded them into descrete entities. (No Blocks)

---

Some complex entitiy types that were supported in their own formats were (and are) not supported in DXF. For instance Anvil Cad had a parallel spline entitiy that stored the original spline data, an offset distance value, and offset direction.
This was recreated as two grouped splines in their dxf output as Autocad had no such entity.

Today even Autocad has parametric entities and Constraints or for that matter 3D entities bundled into the mix. Other Cad systems do not support these and a compromise has to be employed when generating file transfers.

Dimensioning geometry is a whole different kettle of fish. Not all dimensioning types are supported in different CAD systems. chain, ordinate, baseine, tolerances, geotol symbols might or might not exist or be expressed in different ways.

What I am getting at is that when a software company desgns a new CAD system they are generally not concerned about compatibility with other products. They design them to fullfill their own needs which may not have much in common with any sort of standard.

surfR2911

Thanks for the extra info on blocks and suggestions on how to work blocks into oList and for the info blocks=patterns.

I'm still trying to work out entity structures in DXF files and I find its much easier if I use "object" or "grobject" (graphics object) in place of "entity" when trying to parse the dxf internals into a visual diagram - I'm working on putting the text sections of a dxf file into a treeview control where I can graphically "see" the layer-grobject branching.

I also have been doing some research of detecting mouse pointer cursor themes/schemes.

Here's a random scattershotting of what I found:

A mouse scheme is a style theme (what's the difference between "theme and "scheme" - who knows I googled around for both).

The mouse cursors are stored on a per-user basis in the registry at:
HKEY_CURRENT_USER\Control Panel\Cursors\Scheme Source

Possible entries:
HKEY_CURRENT_USER\Control Panel\Cursors\Scheme Source, 5000, "REG_DWORD"
HKEY_CURRENT_USER\Control Panel\Cursors\Scheme Source” “Scheme Source"=dword:00000000
HKEY_CURRENT_USER\Control Panel\Cursors\Scheme Source” “Scheme Source"=dword:00000001

Left-Handed Mouse Pointers
http://archive.msdn.microsoft.com/le...ReleaseId=2509

MousePointer Changes in Visual Basic .NET
http://msdn.microsoft.com/en-us/libr...=vs.71%29.aspx
table shows the Visual Basic 6.0 Mouse Pointer constants and values and their Visual Basic 2008 equivalents.
http://msdn.microsoft.com/en-us/libr...=vs.90%29.aspx
Pictures of cursors
http://www.vbdotnetheaven.com/upload...ors-in-VB-Net/

I though getting the current mouse cursor scheme/theme programmatically would be easy using a few API calls like GetSystemMetrics or SystemParametersInfo

GetSystemMetrics
http://www.pinvoke.net/default.aspx/...tsystemmetrics
GetSystemmetrics Enums
http://pinvoke.net/default.aspx/Enums.SystemMetric

SM_CYICON=12,
/// <summary>
/// Width of a cursor, in pixels. The system cannot create cursors of other sizes.
/// </summary>
SM_CXCURSOR=13,
/// <summary>
/// Height of a cursor, in pixels. The system cannot create cursors of other sizes.

SystemParametersInfo Vb.Net
http://www.pinvoke.net/default.aspx/...parametersinfo
http://bytes.com/topic/net/insights/...en-combo-boxes
http://social.msdn.microsoft.com/For...-a02b04d69604/

MSDN SystemParametersInfo function
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
MSDN: How to Use SystemParametersInfo API for Control Panel Settings
http://support.microsoft.com/kb/97142

However "SPI_GETMOUSE = &H3" doesn't get any info mouse cursor pointer sizing..

vb.net SetSystemCursor and OCR_ constants
http://www.vbforums.com/showthread.php?t=378893

How to get Windows to read and apply new registry entries?
http://www.xtremevbtalk.com/showthread.php?t=249256

Location of cursor (and cursor theme) files:
Windows7
%SystemRoot%\resources\themes\Aero\
%SystemRoot%\resources\themes\Luna\
WindowXP
%SystemRoot%\Resources\Themes\ThemeName\Cursors\

Cursor.Size Property and Private Sub DrawCursorsOnForm(cursor As Cursor)
http://msdn.microsoft.com/en-us/libr...rsor.size.aspx

Custom Mouse Cursors in VB.Net
http://www.codeproject.com/Articles/...Cursors-VB-NET

Changing mouse cursor point theme/scheme after changing registry
http://social.msdn.microsoft.com/for...a-fc2836f4f7df

FAQ Item: How to change the system’s cursor using VB.NET?
http://social.msdn.microsoft.com/For...-bbd458724f1d/

Use GetSetting while protecting against bad values in the Registry in Visual Basic 2005
http://www.vb-helper.com/howto_2005_...ng_safely.html

Accessing the Registry with VB6 and VB.NET
http://www.codeguru.com/vb/gen/vb_sy...-and-VBNET.htm

"High Contrast #1", DWFLAGS = 127 ; " Windows 7 Basic" DWFLAGS = 126
SystemParametersInfo in VB.Net for detection of HighContrast theme
http://social.msdn.microsoft.com/For...d-a69c972b371a

Windows XP icon and cursor support (see "Cursor sizes" and "Cursor scaling problems" sections)
http://support.microsoft.com/kb/307213

Enum SystemMetricsIndexes values of SM_CXCURSOR = 13, SM_CYCURSOR = 14
http://www.codeproject.com/Articles/...-alternate-way

get the system current cursor size (bypassing GetSystemMetrics SM_CYCURSOR and SM_CXCURSOR)
http://www.codeguru.com/forum/showth...hreadid=449040
http://cboard.cprogramming.com/windo...or-height.html

The last set of links seems to be the "real" (actual) way to get the current cursor size but its C code and I couldn't find any VB.Net version..

Gruff

Wow. Your energy seems boundless. (and somewhat infectious)

The term "Entity" is used to describe "data only" structures that represent geometry. In CAD venacular "Dumb Geometry". All manipulation of the geometry is made with external tools. Metamorphically, programmically, and from the end user standpoint a very real actuality. This is true for 2D, 3D, or Solid modeling.

Graphical objects have their own additional internal actions, logic and feedback. (in OOP terminology Methods, Properties and Events.)

Autodesk differentiates them for this reason. If you look at early wireframe CAD (and my viewer,) Entities were used exclusively. You drew lines but for the most part they were fixed. In today's CAD packages you can modify graphical objects in great detail. Parametric geometry is totally dependent on them.
---
I'd really like to see that tool if you feel like sharing.
---
I'm not following your concern with cursors. What are you trying to acheive with them in regards to the viewer project?