.NET
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Use AutoCAD 2000 VBA or upgrade to AutoCAD 2006 for VBA .NET?

11 REPLIES 11
Reply
Message 1 of 12
Tony.
485 Views, 11 Replies

Use AutoCAD 2000 VBA or upgrade to AutoCAD 2006 for VBA .NET?

I'm posting this question here because when I originally posted in the VBA group I was advised that this would be a better group for this question.

My company has recently accepted a proposal I made to develop VBA routines in AutoCAD and Excel 2003 to replace our current suite of Fortran programs. Since we currently use AutoCAD 2000, I'm wondering whether it makes sense to embark on such a huge programming project with an old version of AutoCAD. So my question is, are there compelling reasons to upgrade to AutoCAD 2006 before embarking on this development? Specifically, I'm interested in .NET related advantages.

Briefly, the Fortran programs have been with the company for about 40 years, and they perform numerous geometrical calculations and display 2D profile graphs for the tools we make. I've attached a copy of the sort of polylines the program typically generates. Actually, a transition has already begun since the generated graphs can be exported to .DXF files as simple polylines. The most complicated graphics generated by the Fortran programs can all be output as 2D polylines consisting of well-defined arcs and straight-line segments. Thus the elements of the geometry are simple, although there's a lot of relatively involved calculations involved in finding tangent points where straigtline segments touch arcs. I've done VBA in Excel and feel comfortable with that part.

What I envision is tying the data for all those polylines to data tables in Excel 2003 so that manipulating, say, a cell corresponding to a certain angle in an arc, will then change the shape of that portion of the tool.

This program is huge, having been developed and refined over 40 years, but the basic geometry underlying it is all straight 2D AutoCAD type stuff. While one module will be developed at a time, eventually completing the project will likely take 2 to 5 years.

I know that Microsoft lists details about .NET has advantages over regular VBA, but all these details are a little hard to absorb by someone like me at this point. II'm hoping that a more experienced AutoCAD programmer will be able to provide advice about what issues are really important here. Specifically, what compelling reasons are there to do this development in a .NET framework?

Also, if I do end up upgrading and then develop a combined VBA Excel 2003 and VBA .NET AutoCAD 2006 package, does this means that users will have to have AT LEAST Excel 2003 and AutoCAD 2006 in order to use my routines?

Thanks in advance,
-Tony
11 REPLIES 11
Message 2 of 12
Anonymous
in reply to: Tony.

I read your post in the other group.

There is not VBA.NET. If your main concern is that the code you develop
something in Acad2000VBA would be used in Acad2006 later, then, as you have
already been replied, there is very little that the VBA in Acad2000 would
not work in latest Acad, unless you used some components that are
incompatible with later version of Acad/later OS.

If you use .NET (VB.NET or C#) to automate Acad, then there is little
different from what you can do with VB. People here in this group maily for
discussion of ObjectARX .NET API, a subset of API exposed to .NET
programmer, started since Acad2005. It is still in its early stage (and
would get better, maybe?). Its is only part of ObjectARX and a bit hard to
learn and code, even you are very comfortable with VB.NET or C#.

IMO, if you are confident that VBA can do what you want to, then it could be
the best approach in the regard of ROI (return of investment). I'd expect
VBA code will run in next 10 years, at least (assume MS and Acad can last
that long, But 40 year, as your Fortran?, I don't know. AutoCAD did not
exist then, did it?).

This is my opion from my instinct, without knowing exactly your system does.
OTH, if you already know .NET well and do not mind the steep learning curve
on ObjectARX .NET API, your solution may survive longer, or may be more
powerful. However, you need to get Acad2006 or later.

wrote in message news:5082754@discussion.autodesk.com...
I'm posting this question here because when I originally posted in the VBA
group I was advised that this would be a better group for this question.

My company has recently accepted a proposal I made to develop VBA routines
in AutoCAD and Excel 2003 to replace our current suite of Fortran programs.
Since we currently use AutoCAD 2000, I'm wondering whether it makes sense to
embark on such a huge programming project with an old version of AutoCAD So
my question is, are there compelling re
asons to upgrade to AutoCAD 2006 before embarking on this development?
Specifically, I'm interested in .NET related advantages.

Briefly, the Fortran programs have been with the company for about 40 years,
and they perform numerous geometrical calculations and display 2D profile
graphs for the tools we make. I've attached a copy of the sort of polylines
the program typically generates. Actually, a transition has already begun
since the generated graphs can be exported to .DXF files as
simple polylines. The most complicated graphics generated by the Fortran
programs can all be output as 2D polylines consisting of well-defined arcs
and straight-line segments. Thus the elements of the geometry are simple,
although there's a lot of relatively involved calculations involved in
finding tangent points where straigtline segments touch arcs. I've done VBA
in Excel and feel comfortable with that part.

What I envision is tying the data for all those polylines to data tables
in Excel 2003 so that manipulating, say, a cell corresponding to a certain
angle in an arc, will then change the shape of that portion of the tool.

This program is huge, having been developed and refined over 40 years, but
the basic geometry underlying it is all straight 2D AutoCAD type stuff.
While one module will be developed at a time, eventually completing the
project will likely take 2 to 5 years.

I know that Microsoft lists details about .NET has advantages over regular
VBA,
but all these details are a little hard to absorb by someone like me at
this point. II'm hoping that a more experienced AutoCAD programmer will be
able to provide advice about what issues are really important here.
Specifically, what compelling reasons are there to do this development in a
.NET framework?

Also, if I do end up upgrading and then develop a combined VBA Excel 2003
and VBA .NET AutoCAD 2006 package, does this means that users will have to
have AT LEAST Excel 2003 and Au
toCAD 2006 in order to use my routines?

Thanks in advance,
-Tony
Message 3 of 12
Anonymous
in reply to: Tony.

Can you explain what role Excel serves in your current
and or planned system? Is it used simply as a way for
the user to enter many values that control how your
graphics appear? Are calculations done in Excel, or in
your code, or both?


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:5082754@discussion.autodesk.com...
I'm posting this question here because when I originally posted in the VBA group I was advised that this would be a better group for this question.

My company has recently accepted a proposal I made to develop VBA routines in AutoCAD and Excel 2003 to replace our current suite of Fortran programs. Since we currently use AutoCAD 2000, I'm wondering whether it makes sense to embark on such a huge programming project with an old version of AutoCAD So my question is, are there compelling re
asons to upgrade to AutoCAD 2006 before embarking on this development? Specifically, I'm interested in .NET related advantages.

Briefly, the Fortran programs have been with the company for about 40 years, and they perform numerous geometrical calculations and display 2D profile graphs for the tools we make. I've attached a copy of the sort of polylines the program typically generates. Actually, a transition has already begun since the generated graphs can be exported to .DXF files as
simple polylines. The most complicated graphics generated by the Fortran programs can all be output as 2D polylines consisting of well-defined arcs and straight-line segments. Thus the elements of the geometry are simple, although there's a lot of relatively involved calculations involved in finding tangent points where straigtline segments touch arcs. I've done VBA in Excel and feel comfortable with that part.

What I envision is tying the data for all those polylines to data tables
in Excel 2003 so that manipulating, say, a cell corresponding to a certain angle in an arc, will then change the shape of that portion of the tool.

This program is huge, having been developed and refined over 40 years, but the basic geometry underlying it is all straight 2D AutoCAD type stuff. While one module will be developed at a time, eventually completing the project will likely take 2 to 5 years.

I know that Microsoft lists details about .NET has advantages over regular VBA,
but all these details are a little hard to absorb by someone like me at this point. II'm hoping that a more experienced AutoCAD programmer will be able to provide advice about what issues are really important here. Specifically, what compelling reasons are there to do this development in a .NET framework?

Also, if I do end up upgrading and then develop a combined VBA Excel 2003 and VBA .NET AutoCAD 2006 package, does this means that users will have to have AT LEAST Excel 2003 and Au
toCAD 2006 in order to use my routines?

Thanks in advance,
-Tony
Message 4 of 12
Tony.
in reply to: Tony.

The plan is to have Excel be the "number cruncher" part of the system as well as the way to store and display the many endpoints and angles associated with the parts. The graphical features in Excel allow one to view trends in the tabular data easily. Furthermore, one can manually adjust (by clicking and dragging data points) any generated graphs of the data so as to smooth out the trends or meet some needed condition (such as, "the angle needs to be 90 degrees at this point).

We have 3 basic things that need to be done:
1) Deal with graphical depictions of the tool geometry (polylines)
2) Store tables of data that define the tool geometry at each sage in its formation (endpoints and arc lengths)
3) Perform calculations for how the geometry will change between each stage in formation so as to reduce stress and/or deal with constraints due to cost

Because we deal with such a large number of tools, item (1) is very significant, and AutoCADs features provide a great way to deal with it. Items (2) and (3) on the other hand, are better dealt with by a program like Excel. Thus, we'd like to take advantage of both programs in order to meet our needs.

Again, I really appreciate all the expert help in these Discussion Groups.

-Tony
Message 5 of 12
Anonymous
in reply to: Tony.

Tony,

I agree with the post by Norman he gives you many good points. especially
IMO, if you are confident that VBA can do what you want to, then it could be the best approach in the regard of ROI (return if investment).

Do a search in this group for "VB" and you will see many questions/posts go unanswered . If you decide to use
.net it will require you climbing a very steep learning curve.
I have the help of many professional very experienced programmers to help me with my VB.net hurdles.
Unless you have these resources I think you will
have a big job ahead.

If you need the capabilities of ARX/NET then you have no choice. For example If wanted to create you own custom drawing entities.

There are more users programming the Net API in C# or C++

Do your self a favor and start with a small task and try to do it in VBA and then see how long it takes to complete.Then try the same task in NET and see how long it takes.

Maximo
Message 6 of 12
Tony.
in reply to: Tony.

Thank you for the advice. I do have friends and co-workers using .net, but I was hoping to hear from specifically AutoCAD .net developers.

One of the fears I have is that development in AutoCAD VBA will lead to code that eventually won't be supported. By contrast, my understanding is that .net will not face this problem since multiple languages compile to a single intermediate code.

Having programs that will still be working well in 20 years without endless recoding is not a small issue -- especially when you're experiencing it right now with a FORTRAN system -- and that's why it's important to me to not begin with a language/system that might face longevity issues. On the other hand, maybe AutoCAD 2025 will still be running AutoCAD 200 VBA routines...I don't know.

-Tony.
Message 7 of 12
Anonymous
in reply to: Tony.

Hi

Just some thoughts from left field

Going by the past few years I would expect acad 2007 to be release late
March early April,
VBA uses COM which Microsoft has superceded by .Net 1.0 1.1 & 2.0.....
I believe you can get a Fortran.NET compiler...
.Net XMLserialization could give you a way to save the data without using
excel,
I am guessing by the age that the fortran code is procedural and and .NET is
Object Oriented,
You could use GDI+ to draw charts directly onto a form, or even use the
DirectX SDK


I currently have a similar setup where I use VB (COM) to export data of 1 to
250 related objects acad into excel where we apply parameters to each
object, then excel calculates the design based on standards, and draws
graphs, then the design is put back into CAD using VB (COM).

The limitations I have run into with this is that because part of the
programme is embedded into the formulaes in the spreadsheets cells, it is
it is dificult to update the design standards or use different design
standards, especially on exiting designs. For these reasons I am working on
removing Excel from my application and moving to .NET


Mark
Message 8 of 12
Tony.
in reply to: Tony.

Mark,

These comments are helpful because of your experience with the Excel/Acad interface with VBA. You mention driving graph generation using equations in Excel which is something I'm quite interested in at this point -- if you could point me to resources focused on that, I'd be interested.

However, the limitation you mention w/r to drawing designs related to standard formulas might not apply to our situation. I don't so much want to drive drawings based upon standards, but rather form specific bends in the polylines based upon elements in the Excel data table (such as lengths and radii of arcs, etc...). When the resulting Acad drawing of the tool is acceptable, I'll then send the Excel data directly to the manufacturing machines. It's hard for me to see the need of xml serialization for such a situation.

-Tony.
Message 9 of 12
Anonymous
in reply to: Tony.

I use the excel chart 'Scatter plot' to draw graphs of the design.
wrote in message news:5083910@discussion.autodesk.com...
Mark,

These comments are helpful because of your experience with the Excel/Acad
interface with VBA. You mention driving graph generation using equations in
Excel which is something I'm quite interested in at this point -- if you
could point me to resources focused on that, I'd be interested.

However, the limitation you mention w/r to drawing designs related to
standard formulas might not apply to our situation. I don't so much want
to drive drawings based upon standards, but rather form specific bends in
the polylines based upon elements in the Excel data table (such as lengths
and radii of arcs, etc...). When the resulting Acad drawing of the tool is
acceptable, I'll then send the Excel data directly to the manufacturing
machines. It's hard for me to see the need of xml serialization for such a
situation.

-Tony.
Message 10 of 12
Anonymous
in reply to: Tony.

any reason why using classic VB6 is not a good choice?
I am curious if its going to be around for a long time or not. You would think not, but it seems to be living on
despite what MS is doing...
I would rather learn .net than program something big in VBA though, seems like that is a dead ringer of a language to be
replaced with VBA.net at some point.

Tony. <>
|>I'm posting this question here because when I originally posted in the VBA group I was advised that this would be a better group for this question.
|>
|>My company has recently accepted a proposal I made to develop VBA routines in AutoCAD and Excel 2003 to replace our current suite of Fortran programs. Since we currently use AutoCAD 2000, I'm wondering whether it makes sense to embark on such a huge programming project with an old version of AutoCAD So my question is, are there compelling re
|>asons to upgrade to AutoCAD 2006 before embarking on this development? Specifically, I'm interested in .NET related advantages.
|>
|>Briefly, the Fortran programs have been with the company for about 40 years, and they perform numerous geometrical calculations and display 2D profile graphs for the tools we make. I've attached a copy of the sort of polylines the program typically generates. Actually, a transition has already begun since the generated graphs can be exported to .DXF files as
|> simple polylines. The most complicated graphics generated by the Fortran programs can all be output as 2D polylines consisting of well-defined arcs and straight-line segments. Thus the elements of the geometry are simple, although there's a lot of relatively involved calculations involved in finding tangent points where straigtline segments touch arcs. I've done VBA in Excel and feel comfortable with that part.
|>
|>What I envision is tying the data for all those polylines to data tables
|> in Excel 2003 so that manipulating, say, a cell corresponding to a certain angle in an arc, will then change the shape of that portion of the tool.
|>
|>This program is huge, having been developed and refined over 40 years, but the basic geometry underlying it is all straight 2D AutoCAD type stuff. While one module will be developed at a time, eventually completing the project will likely take 2 to 5 years.
|>
|>I know that Microsoft lists details about .NET has advantages over regular VBA,
|> but all these details are a little hard to absorb by someone like me at this point. II'm hoping that a more experienced AutoCAD programmer will be able to provide advice about what issues are really important here. Specifically, what compelling reasons are there to do this development in a .NET framework?
|>
|>Also, if I do end up upgrading and then develop a combined VBA Excel 2003 and VBA .NET AutoCAD 2006 package, does this means that users will have to have AT LEAST Excel 2003 and Au
|>toCAD 2006 in order to use my routines?
|>
|>Thanks in advance,
|>-Tony
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 11 of 12
Anonymous
in reply to: Tony.

"James Maeding" wrote in message
news:5090261@discussion.autodesk.com...
any reason why using classic VB6 is not a good choice?
I am curious if its going to be around for a long time or not. You would
think not, but it seems to be living on
despite what MS is doing...
I would rather learn .net than program something big in VBA though, seems
like that is a dead ringer of a language to be
replaced with VBA.net at some point.

Tony. <>
|>I'm posting this question here because when I originally posted in the VBA
group I was advised that this would be a better group for this question.
|>
|>My company has recently accepted a proposal I made to develop VBA routines
in AutoCAD and Excel 2003 to replace our current suite of Fortran programs.
Since we currently use AutoCAD 2000, I'm wondering whether it makes sense to
embark on such a huge programming project with an old version of AutoCAD So
my question is, are there compelling re
|>asons to upgrade to AutoCAD 2006 before embarking on this development?
Specifically, I'm interested in .NET related advantages.
|>
|>Briefly, the Fortran programs have been with the company for about 40
years, and they perform numerous geometrical calculations and display 2D
profile graphs for the tools we make. I've attached a copy of the sort of
polylines the program typically generates. Actually, a transition has
already begun since the generated graphs can be exported to .DXF files as
|> simple polylines. The most complicated graphics generated by the Fortran
programs can all be output as 2D polylines consisting of well-defined arcs
and straight-line segments. Thus the elements of the geometry are simple,
although there's a lot of relatively involved calculations involved in
finding tangent points where straigtline segments touch arcs. I've done VBA
in Excel and feel comfortable with that part.
|>
|>What I envision is tying the data for all those polylines to data tables
|> in Excel 2003 so that manipulating, say, a cell corresponding to a
certain angle in an arc, will then change the shape of that portion of the
tool.
|>
|>This program is huge, having been developed and refined over 40 years, but
the basic geometry underlying it is all straight 2D AutoCAD type stuff.
While one module will be developed at a time, eventually completing the
project will likely take 2 to 5 years.
|>
|>I know that Microsoft lists details about .NET has advantages over regular
VBA,
|> but all these details are a little hard to absorb by someone like me at
this point. II'm hoping that a more experienced AutoCAD programmer will be
able to provide advice about what issues are really important here.
Specifically, what compelling reasons are there to do this development in a
.NET framework?
|>
|>Also, if I do end up upgrading and then develop a combined VBA Excel 2003
and VBA .NET AutoCAD 2006 package, does this means that users will have to
have AT LEAST Excel 2003 and Au
|>toCAD 2006 in order to use my routines?
|>
|>Thanks in advance,
|>-Tony
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 12 of 12
Anonymous
in reply to: Tony.

Hi,

From what I can recall the replacement for VBA is to be VSTA (Visual Studio
Tools for Aplications) ie .net
I have moved on to .net from VB6 and I find going back to VB6 quite
painfull.

The dificulty in moving from VB6 to .net is that VB had to be changed to
make it an Object Oriented Programming Language, and conform to the .net
model, meaning changes to source code, so rather than going to VB.NET I went
to C#.net which I find easier to read now.

I think 'classic COM' aka VBA VB6 will be around for a while yet.
But once your on the otherside you don't want to go back

Mark

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report

”Boost