Moving old code up - vb5stkit.dll issues

[wundrlik]

Ok, finally ran into one of those projects I hate, and have run out of ideas.

I have old VBA code, written years ago, and it references Vb5stkit.dll. (Also references kernel32.dll, but that should still be the same). I’m on win 10 x64, and cannot get the dll to register (no shock there). Is these a good or direct replacement for this, or am I going to have to rewrite (and figure out) multiple lines of code.

I feel that this should be any easy change or update, but I’ve had no luck with my usual methods in getting this section to run. 

Anyone have a good method to this madness, or am I going to have to reinvent the wheel?

thanks

[norman.yuan]

I have no idea what Vb5stkit.dll is for, but from your description, I guess it is a COM DLL built with classical VB (VB5). If so, it is useless with 64-bit AutoCAD (unless the 64-bit AutoCAD is Acad2013 or older), because DLL built by classical VB (VB5/6) is 32-bit.

If you do know what that 32-bit DLL does, for example, it is just a wrapper of Window 32 API calls, you can directly call the Window API in AutoCAD VBA with necessary modification because of 64-bit (such as change Long type to LongPtr type...). 

Maybe, it is time to stop wasting time on VBA; instead of re-invent the wheel (of Vb5stkit.dll), you would be better off re-invent the functionalities of your out-of-date VBA project with AutoCAD .NET API.

[wundrlik]

That's what I suspected...unfortunately that was not what was agreed to, as much as I'd have taken this over to the .NET API from the get go, that was never part of the scope, so I just have to put a bandaid on it...

Here's one of the lines of code:

Declare PtrSafe Function OSfCreateShellGroup Lib "vb5stkit.dll" Alias "fCreateShellFolder" (ByVal lpstrDirName As String) As Long

However, I cannot find any references in the rest of the various pieces that actually refer back to any of the vb5stkit declared functions, so I'm suspecting that it may have been put in (as a common module), but is not actually used at this point.  That's my current suspicion, since none of the functions defined by the vb5stkit lines are called anywhere in any other parts of the dvb, only defined in the Common module.

[norman.yuan · Accepted solution]

I am certain Vb2stkit.dll is 32-bit DLL, which simply cannot not be used in 64-bit VBA. If you suspect that the function OSfCreateShellGroup() in the line of code "Declare PtrSafe Function ......" is not actually call anywhere in your DVB project, you can search the project for "OSfCreateShellGroup". Or, you can simply comment the line out, and click VBA menu "Debug -> Compile [project name]" to compile the code to see if that function is actually used. Of course, if the said VBA project (DVB file) is shared/referenced by other existing VBA projects, removing this line would break other VBA project (but, so what? It does not work in 64-bit VBA anyway!).

[wundrlik]

Just to let you know...I bailed out of all the old VBA (the vb5stkit stuff), code was 100% unaffected (to the originating author had a bunch of crap that was never used).  

I did put this on the radar list that they will need to abandon this code at some point in the future and move it up to the .NET API

Otherwise, it's working again, like it should with some minor modifications.

Thanks for the help though.