Topic: Rewriting program - opinions?

[quamper]

Currently I've got a VB COM app that I'm toying around with rewriting from the ground up using the .net api stuff as I've hit some limitations over time. I've already rewritten a few smaller ones with good success.

I've got a chance to change a few fundamental things and I'm wondering whether I should or not before I get too far into it.

One of the big components of my program is that it creates 3-4 different overall styles of Blocks based on a whole lot of different criteria, and inserts them into the drawing. Each of these blocks has a ton of attributes (most of the hidden/non-visible attributes). A typical drawing may have 5-30 of these "intelligent blocks". Alot of the reason for this program was previous to dynamic blocks, but it still does alot more than dynamic blocks do so thats not really an issue.

I'm mostly wondering at this point:

1. Currently using blocks if I create one and insert it into the drawing, then I delete the block, it's still in the database unless I do a purge. Ideally I don't want multiple references to the same block in the drawing, nor do I want a block not referenced at all. Is there another way to do that or should I have an event that watches for deletion of these blocks and purge them programatically, and also prevents multiple instances? The geometry in the blocks isn't terribly complicated. Are blocks the most efficient way to handle this?

2. Attributes vs. Xrecords? Is there any advantage to using xrecords? Are there limitations of using xrecords that I should be aware of, as I've not used them much at all, except in learning the basics of how to use them.  Currently the attributes never get edited via Autocad dialogs and strictly by the application.

Thanks

[Draftek]

One question I would ask is - What are the limitations you've hit and will re-coding the thing in .Net actually eliminate those?

As far as using blocks or not and the worry of references vs inserts - it all depends - if your worried about the user manipulating the geometry then your either stuck with blocks or a custom object, I guess. If not then you could use primitives and attach xdata or xrecords / dictionaries. I've used these before along with handles to create kind of a poor mans custom object. I would avoid monitoring events at all cost...

[LE]

I'm too would like to know what are those limitations (perhaps you refer about future compability or accessibility to the API's that might required in example C#?)


About those inserts - can they be anonymous - so in case they are deleted, they will be purge by acad once the drawing is closed ?

I am working in my first COM project but it is in C++ and ObjectARX - and the reason they want to have this, it is because it will be used in a VB or VBA application's [and for now it is easier to them to go this way, instead of porting or re-coding all what they have in VB to C++/ARX/or C#]. I use dictionaries to save some of the data too.

[quamper]

"What are the limitations you've hit and will re-coding the thing in .Net actually eliminate those?"

The short answer is, yes. Some of it is because of performance, some of it is because Autocad seems to be heading away from supporting VB/COM stuff and more support for the .net api. I have run into a few specific instances where I just couldn't accomplish what I wanted to do. It's been a little while I'm sure I have some notes somewhere of what it was. And I've got the time to do it so I'm not really worried about that aspect.

"I've used these before along with handles to create kind of a poor mans custom object."

I guess thats in essence what I'm currently doing...and I guess creating my own custom object isn't really any option unless I dive into ObjectARX which isn't really an option. So since creating blocks and tying info to them is fairly easy and accomplishes what I'm needing. Is there any benefit then to tons of attributes vs xdata/dictionaries for all the extra data I'm associating with the block
 

 

[quamper]

"About those inserts - can they be anonymous - so in case they are deleted, they will be purge by acad once the drawing is closed ?"

Right now they are all named, but theres no reason they couldn't be anonymous I suppose. So thats an acceptable solution.

[Draftek]

Good point about the future of vb and vba. That is what drove me to C# a few years ago.

I guess I would say the main advantage of using xdata or xrecords in lieu of attributes would be security - you can only access them via the programming interface. savvy people can figure out how to get to attributes. Again, if you don't want the users stretching your lines out of whack a block might be best - you could still use xdata instead of attributes if you like.

I was going to suggest a custom object if you don't have to deploy outside of your realm and you have some c++ experience - that gives you the most control.
You should consider breaking your project up into a n-tier app so if you decide to wrap some autocad object in c# later you will be able to. If the graphics are simple, creating a custom entity is not that hard.

[quamper]

"I was going to suggest a custom object if you don't have to deploy outside of your realm and you have some c++ experience - that gives you the most control."

From everything I've read about custom objects, I think that definitly would be a really nice solution/fit for what I'm doing. I don't need to deploy outside so thats not an issue, however I don't have c++ experience. Most everything I've been writing for Autocad has been in VB.NET. I think I could make the switch to C# relatively easily, but I've not done any C++ programming so I don't how different of a beast I would be tackling.

I know there was mention of the Autocad developers possibly allowing custom objects to be created with the .net api in the 2009 or 2010 release, but I haven't heard/read any updates about that coming to pass.

[Nathan Taylor]

I've found 3 benefits of rewriting my VBA programs with .NET.

1. Revisting the logic of how the program works.

2. Extra capabilities of the AutoCAD .NET API, the .NET framework and .NET forms.

3. Better speed of the AutoCAD .NET API.


Regards - Nathan

[LE]

"I was going to suggest a custom object if you don't have to deploy outside of your realm and you have some c++ experience - that gives you the most control."

From everything I've read about custom objects, I think that definitly would be a really nice solution/fit for what I'm doing. I don't need to deploy outside so thats not an issue, however I don't have c++ experience. Most everything I've been writing for Autocad has been in VB.NET. I think I could make the switch to C# relatively easily, but I've not done any C++ programming so I don't how different of a beast I would be tackling.

I know there was mention of the Autocad developers possibly allowing custom objects to be created with the .net api in the 2009 or 2010 release, but I haven't heard/read any updates about that coming to pass.

Custom Objects are not easy starting from scratch - I have done quite a few - and you required a strong knowledge of ARX among heavy background of C++. There are some step by step custom object sample(s) posted here in the ARX or was C++ forums by MickD and me.

C# can be your best choice.

[quamper]

1. Revisting the logic of how the program works.

Thats exactly why I'm asking the questions

Along with the other reasons.

[MickD]

Custom objects at first glance seem like a great idea but they can get real complicated real quick and if you implement one - even only for internal use - you can find compatibility issues a real problem even between minor versions.
I would also suggest xdata/records and some custom tools to access/edit the data, if you need special methods called with normal acad commands you could use reactors or just create your own special methods, this is much easier to maintain and extend than custom objects IMO.

[Glenn R]

As Luis has already stated and Mick reiterated, custom objects require a LOT of work to make a good one and a serious grounding in C++ and ARX.

From what you've mentioned, if it was me, I would do as Luis has suggested...anon blocks with an extension dictionary containing your xrecord - then you control everything.

You can also use the database Purge function and pass a list of ObjectIds of the block defs you want to nuke for any cleanup you require.

Just some thoughts.

Cheers,
Glenn.

[Draftek]

Here is something I've been dying to code but just do not have the time - Wrap the AcDbEntity with a C++ mixed / managed project and expose it to .Net.
Wallah! - you have custom entities for .Net.

I realize that it's not easy to create custom objects but it's not rocket science either - especially if the graphics are simple. Hell, if I can do it.... But as I and everyone else mentioned, you must have some C++ experience first and I would definitely not recommend quamper attempting it at this time.

Anyway, I'm moving all my development projects to Inventor and 3D - I may never get to write any AutoCAD code again

[quamper]

Yeah I don't think I want to tackle creating custom objects now. I know I have a working method for accomplishing what I want for the time being.

But that's good to know, if they ever do open up custom objects in the Autocad .net api, I may revisit that then.

Thanks for the advice/opinions

[MickD]

Just off topic for a sec,

Here is something I've been dying to code but just do not have the time - Wrap the AcDbEntity with a C++ mixed / managed project and expose it to .Net.
Wallah! - you have custom entities for .Net.
...

In theory that sounds good but the problem is registering the new object with acad and there is also some callbacks etc. that need implementing, this all gets done with a macro (I can't think of it just now) so you never see what's going on.
I actually started to write a C# CE and I got all the way but for the callbacks, now I know a bit more about them I might have a better chance.
I'll see if I can dig up the code and I'll start a new thread for a bit of fun and learnin'