Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
We're considering upgrading to 64-bit AutoCAD to take advantage of additional memory over the 3GB limit. Right now we have a significant amount of in-house VBA utilities, and while i understand that AutoCAD 64-bit supports VBA, it does so using an external process that would require the VBA applications to be re-written for late binding, and would run significantly slower, perhaps even slow enough to be unusable.
After a bit of research, I'm learning towards the following approach; I'd re-rewrite these applications using VB.NET, but using the ActiveX/COM (early bound) whenever possible. This way i can re-use as much existing code as possible plus avoid the double hit of learning .NET and autocad's managed libraries at the same time. After the initial conversion, i could then focus on slowly transitioning the classes using COM to their managed counterparts. Later if i need to make it more portable, i'd switch to late bound.
Does this approach make sense?
-How hard have people found using early bound COM in .NET to be?
-Is there a significant performance penalty?
-I've seen issues on .NET's garbage collection being incompatible with COM's...has anyone run into this?
-Does intelisense in visual studio not work on late bound objects, similar to VB/VBA?
wrote
We're considering upgrading to 64-bit AutoCAD to take advantage of
additional memory over the 3GB limit. Right now we have a significant amount
of in-house VBA utilities, and while i understand that AutoCAD 64-bit
supports VBA, it does so using an external process that would require the
VBA applications to be re-written for late binding, and would run
significantly slower, perhaps even slow enough to be unusable.
After a bit of research, I'm learning towards the following approach; I'd
re-rewrite these applications using VB.NET, but using the ActiveX/COM (early
bound) whenever possible. This way i can re-use as much existing code as
possible plus avoid the double hit of learning .NET and autocad's managed
libraries at the same time. After the initial conversion, i could then focus
on slowly transitioning the classes using COM to their managed counterparts.
Later if i need to make it more portable, i'd switch to late bound.
Does this approach make sense?
{quote}
Absolutely.
It is IMO, the best possible migration path for VBA.
{quote}
-How hard have people found using early bound COM in .NET to be?
{quote}
Depends on your background, but if you stick to VB.NET, you
can reuse quite a bit of your existing code, and most things
will be familiar (which is by-design of course).
{quote}
-Is there a significant performance penalty?
{quote}
None at all. In-process ActiveX should run just as fast as VBA,
mostly because that's what VBA is.
{quote}
-I've seen issues on .NET's garbage collection being incompatible with
COM's...has anyone run into this?
{quote}
It is in C# because there is no equivlent to the 'set' statement that
is what generates calls to IUnknown.AddRef()/Release(), but if you
are using VB.NET, and it supports SET, then that will take care of
the releasing of COM objects.
In C#, you must explicitly release COM objects in code when
you're done using them. Failing to do that with COM wrappers
of AutoCAD entities can cause problems with the Properties
Palette, QuickProperties, object tooltips, Fields, and possibly
other COM-dependent features.
{quote}
-Does intelisense in visual studio not work on late bound objects, similar
to VB/VBA?
{quote}
Intellisense can't work on late bound objects, because there's
nothing known about them. In VB.NET, it's the same as it is in
VBA (you declare the variable as 'Object', and then you can do
late-bound calls on it, but you get no Intellisense).
--
http://www.caddzone.com
AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009
About two years ago I was in charge of migrating a large VBA application to 64-bit AutoCAD using VB.Net. Increasing performance was the real issue so they were going all out (quad-Xeon server, 64-bit SQL clustered server, the works). At that time, Acad 2008 running as 64-bit was running VBA as 32-bit and there were still a lot of little quirks that hadn't been worked out. Correct me if I'm wrong but I doubt Autodesk or Microsoft has taken the time to make VBA truly 64-bit compliant since they're starting to phase it out.
Using COM in .Net is very easy and allows a quick translation but you won't see an increase in performance until you rewrite things as managed code and take advantage of all the tools .Net offers.
You'll probably feel like a fish out of water when you first switch to managed AutoCAD .Net but I found after a couple of weeks I hated programming in VBA.
I agree....VBA in 64-bit autocad is probably always going to be sketchy. That being said, I'm very happy with how our vba applications perform under 32-bit autocad. If i use COM in .NET will i see similar performance to what i saw with vba in 32-bit autocad?
As for hating coding in VBA...i'm sure. I imagine i'd eliminate a few 1000 lines of win32 API calls alone.
Tony...thanks. I was kinda hoping you might respond.
Another question....what's the technical explaination to why late binding must be used when vba is run out of process, either via a VB application or the VBA implementation in 64-bit AutoCAD? You can use early binding when automating Office from AutoCAD, and that's out of process...isn't it?
You can use late binding or early binding from either in-process
or out-of-process. With COM, early binding requires a reference
to the server's type library whereas late binding does not.
--
http://www.caddzone.com
AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009
wrote in message
news:6141447@discussion.autodesk.com...
Tony...thanks. I was kinda hoping you might respond. Another
question....what's the technical explaination to why late binding must be
used when vba is run out of process, either via a VB application or the VBA
implementation in 64-bit AutoCAD? You can use early binding when automating
Office from AutoCAD, and that's out of process...isn't it? -Chris
(skip to about 18:38) mentions that the New keyword can't be used as it attempts to create the object in process and causes an error. They recommend using AcadApplication.GetInterfaceObject() instead. I assumed that meant late binding...but you're saying that's not the case?
Sorry for all the questions but I stil don't have a 64-bit copy here yet to play with.
wrote in message
news:6141475@discussion.autodesk.com...
Interesting...however if you look at the the AutoCAD 2008 64-bit porting
presentation:
http://through-the-interface.typepad.com/presentations/AutoCAD/2008/64-bit/AutoCAD2008-64-bitPorting.html
(skip to about 18:38) mentions that the New keyword can't be used as it
attempts to create the object in process and causes an error. They recommend
using AcadApplication.GetInterfaceObject() instead. I assumed that meant
late binding...but you're saying that's not the case? Sorry for all the
questions but I stil don't have a 64-bit copy here yet to play with. -Chris
