Vba, 32bit vs 64bit

[Anonymous]

Over the last several years I have been developing a vba project file that performs an extensive amount of operations, from iProperties, BOM exports, accessing data bases to retrieve information....etc,etc. I have just been given the approval for a new laptop. I ordered a Dell M6400 Covet mobile workstation, Vista business, 64 bit with 8 Gb. After reading some of the posts here regarding Vba and 64 bit, I am wondering if I have made a mistake... At this point in time I really do not need a lot of code issues with Inventor, vba and 64 bit OS. Does anybody have any input on how difficult this transition will be? I am considering going back to a 32 bit machine with only 4 Gb. Are any of you using 64 bit with Vba. Please give me your impressions of how it works.
Thanks
Wayne

[Anonymous]

If you need these functions that you have coded in VBA you will most likely eventually need to port them over to being an add-in because Microsoft is trying to move away from VBA and toward .NET. When and how that will happen is still unclear. They have already closed VBA licensing to any new customers, but they say that existing VBA customers can continue to purchase licenses and also say they have no intentions on removing VBA from the Office applications.

My opinion on the subject is that if you have problems with VBA in 64 bit Windows, you might as well tackle the beast and start translating over to .NET. Moving back to 32 bit means you can't go over 4GB of RAM, which I know I'd have a difficult time with in Inventor.

As to how difficult it is, the answer would seem to be not too terribly bad. There are several articles I've seen floating around. See here for a good starting point. There are some new things to learn, but after you get over the hump, .NET and add-ins open the doors to a lot of good things. Edited by: NoRAM256 on Aug 19, 2009 6:00 AM

[Anonymous]

If you are living in VBA and not .NET, then I would think that the transition wouldn't be too bad, if there is any issue at all, as you are in VBA and VBA is in Inventor. I am currently working on 32bit system at work, but have been doing some development at home on 64bit. As per my hero, Brian Ekins, suggests 🙂 I have been developing in VBA and will soon be porting over to .NET so that it can simply be an add-in. So far, I have seen no issues with the 64bit. I haven't ran a lot of my routines at home, but what I have ran, have ran flawlessly. I would think the main issue that might arrise is if you are making function calls to other applications such as Word or Excel, then, where you are accessing system calls and not just Inventor calls, you might see some minor issues. So far as porting to .NET - I would say start thinking about it, but I wouldn't be rushing off to port my routines to .NET just because they say VBA will be going away, but as with all things Micro$oft, I'll believe it when I see it!!

[Anonymous]

VBA in 64 bit Inventor should work for the most part, but note that since
Microsoft does not provide a 64 bit version of VBA, it is implemented as an
out-of-process application. So things may be slower. The following tips from
the programming help may be useful.

Sanjay-


VBA in 64-bit Inventor is implemented only as an out-of-process 32-bit
component. Therefore, for 64-bit Inventor, a 32-bit process is used to host
VBA. Thus all the API calls are out-of-process calls. This has several
implications:

1.. In some cases, API calls can cause Inventor to update its UI. This can
cause your VBA code to slow down. For long operations, where your code makes
multiple calls to Inventor, you can regain performance by disabling the
Inventor UI. To do so, set the UserInterfaceManager.UserInteractionDisabled
property. Please do this carefully, as you are responsible for resetting
this property afterwards. Note that this slowdown does not happen when your
code is responding to an event raised by Inventor.
2.. The FileManager.FileSystemObject property returns Microsoft's
scripting FileSystemObject which is instantiated in Inventor's process
space. Using FileSystemObject directly in 64-bit space gives the wrong
current directory etc. Therefore you should avoid using built-in VBA
functions such as chdir$.
3.. To wait for Inventor to complete processing of pending windows
messages, you need to use UserInterfaceManager.DoEvents instead of the
builtin DoEvents subroutine in VBA.
4.. ThisDocument in Document projects is not supported. You can embed a
VBA project in any Inventor document. Usually in a macro within such a
project, you can use ThisDocument property to refer to the document itself.
With VBA for 64-bit Inventor, ThisDocument object no longer refers to the
document. Instead for 32 & 64 bit VBA compatibility, you will need to
manually replace all the references to ThisDocument by
ThisDocument.InventorDocument.
5.. No VB6 support for creating Addins You can not use VB 6.0 to create
Add-ins for 64 bit Inventor.
6.. Handles in 64-bit Windows are supposed to be 64-bit. However only the
lower 32-bits are significant and the rest are zero. Therefore
Application.MainFrameHWND returns 'long' type which works in 32-bit
Inventor. You just need to "zero out" the higher bits. You can use the
handle in a 32-bit process as well.
7.. Application.GetInterfaceObject32 creates the COM in-proc server object
in the 32-bit host that is used to host VBA. It requires that if the typelib
is also registered in the 64-bit registry, then the methods and properties
should match.
8.. The ApplicationEvents.OnRestart32BitHost event is fired when the
32-bit host process is restarted for any reason.
9.. Some of the Inventor API methods and properties use IPictureDisp
interface when working with icons/images. This interface does not work
across process boundaries. Thus any such methods cannot be used in 64-bit
Inventor VBA.
10.. Use of Me in Document projects is not supported. You can embed a VBA
project in any Inventor document. Usually in a macro within such a project,
you can use Me property to refer to the document itself. On the VBA for
64-bit Inventor, Me object no longer refers to the document. Instead for 32
& 64 bit VBA compatibility, you will need to manually replace all the
references to Me by Me.InventorDocument.

[stevec781]

Sanjay can you please advise where in the help you found these tips. Was it in the Inventor help or in the VBA help?

I am trying to find a similar set of tips for Autocad so I can fix all of my Autocad macros as well. Hoping it will be in roughly the same place.
Thanks
Steve

[fle]

Wayne,
Instead of loosing time using VBA, I would definitivly recommend you to convert your programs to .NET.
VBA is a dieing technology.... and should think on a term of more than 2-3 years. The day will come when you do not have the chance to go back to your old machine or an older Inventor version.... so, be prepared for the future!

See this micorosoft article for more information:
http://msdn.microsoft.com/en-us/isv/bb190538.aspx

Best regards,
Andreas

[Anonymous]

I know some excel VBA and I'm trying to learn IV VBA when I came across this. What is .net and how do I get started w/ that? Does it have a recorder like a lot of the VBA macro recorders and maxscript? I find that's the easiest and quickest way to learn.

[Anonymous]

Here is the link where you can download Visual Basic 2008 Express Edition.
This will get you up and running with VB.net.

http://www.microsoft.com/express/Downloads/#2008-Visual-Basic

Good luck
Wayne