Make executable error (VB6)

Hello everyone!

I got a VB6 project thrown into may hands and finally got to a point I don't know what to do. I did not write the original code, although I am trying to improve it, but I'm new to Visual Basic, so I'm still figuring out lots of stuff.

The project is actually a group of 2, consisting mainly of an app project and a ActiveX dll project.
While developing, everything works ok, functions get called allright and I never get errors. However, when I tried to build an executable version, for eventually building an installer for the app using InstallShield, I got an error saying one of the functions (I added) couldn't be found. After trying that, the whole project would never compile again, stating an infinite number of errors when loaded. I had to revert to a backup (lucky I backed up...) and start over.
I decided to guess that maybe when running the program from the developer (VB) it uses the projects source codes directly, buy when trying to build the .exe, it will look for the .dll file instead, so I tried to build the .dll file before. That's when I got to the second boom, getting a linker error, "fatal error LNK1102: out of memory". The resulting .dll is a 4kb file (when the original was over 500kb)
Now the fun part... making the .exe file works, but the app itself crashes, obviously. So guessing again, the .dll build managed to create a list of function prototypes, but not the code itself? Which would partially confirm my first guess.
I'm not sure how to split the .dll class to make it smaller and avoid the out of memory issues.

Does anyone have some pointers on how to setup the project? Where to look for any key info, files I can/should trash, references? Code analisys?

Thank you very much! Regards,

Nikel

There is a tool called code anylizer from MS, I can't remember if it was included with VS or if I downloaded it from MS but it can go through your code and point out areas that may be questionable. Don;t know it this would be of any help.

Have you tried your new exe with the older build of the dll properly registered on the system?

Well, I've been doing exactly that. I didn't find a code analisys tool, but I downloaded a few other tools and spent the whole day fixing things according to tips from a migration tool to .NET

Off topic, but, Anyone ever used a migration tool?

I noticed I really dislike VB6's tolerance to variant declaration!!!! It allows some very wide (and dangerous) range of options that could blow everything up!

Anyway, no updates so far, I'll keep working. Thanks!

I had the name wrong, It is codeadvisor

http://msdn.microsoft.com/en-us/vbasic/ms789135

Maybe it will help.


Migration to .det is not very smooth, depending on the app you will likely be calling references to vb runtimes of the past in order to get the code to work and is pretty chunky, most apps would benifit from a re-write when going to dot net.

Yep, that's the one I used. It pointed a lot of "FIXIT"'s stating things about using Left$() instead of Left() and things like that, but not much about code flow. It's mostly migration oriented. I fixed all I could, still have a few things going around, like:

Dim f As Form
Set f = New frmMsgBox

'FIXIT: 'Message' is not a property of the generic 'Form' object in Visual Basic .NET. To access 'Message' declare 'f' using its actual type instead of 'Form'
f.Message Owner, msg, Buttons, ProcCallBack

I changed
Dim f as Form
for
Dim f as frmMsgBox

and it worked, but would that be ok?

-- OR --

'FIXIT: Declare 'fso' with an early-bound data type
Dim fso As Object
Set fso = CreateObject("Scripting.FileSystemObject")

What would the early-bound data type of an Object be?
Declaring this one as a FileSystemObject doesn't work =)

-- OR --

'FIXIT: Whenever possible replace ActiveForm or ActiveControl with an early-bound variable
PointID = Screen.ActiveForm.mId_Point

... er, what?

-- OR --

Dim f As Form

'FIXIT: Forms collection not upgraded to Visual Basic .NET by the Upgrade Wizard.
For Each f In Forms

So what should I do? How does the Forms collection work? How can I replace it?

-- OR --

'FIXIT: As Any is not supported in Visual Basic .NET. Use a specific type.
Public Declare Function MoveToEx Lib "gdi32" (ByVal hDC As Long, ByVal X As Long, ByVal Y As Long, lpPoint As Any) As Long

'FIXIT: As Any is not supported in Visual Basic .NET. Use a specific type.
Private Declare Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As Any, ByVal lpDefault As String, ByVal lpReturnedString As String, ByVal nSize As Long, ByVal lpFileName As String) As Long

This ones are my favorites! First, what's "As Any"? Would it be like a Variant? Second, how can I replace this if it's calling a library? It's not like I can check the code, but anyway, searching for a while, I found this:

For the first one, I'm following this:
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

The second one, MS support won't help since the prototype is not clear on the types (although it does say it's a name on the description box)
http://support.microsoft.com/default...kb;en-us;75639
So I'm replacing the argument list following this link. Let's just hope it works!
http://support.microsoft.com/kb/90988

----------

So much fun all this code-writing stuff =)

Also, I added functions to one of the projects (the .dll side) and the other side, the main app, is not seeing them. It seems like I need to add/update a reference to it. Do I have to do this manually? How?

I'm open to help and/or advice!

I'm using Visual Studio 6 with SP6 on Windows XP running as a VMWare virtual machine in Windows 7.

Thanks in advance!
And thanks to DataMiser for the help so far. By the way, I would LOVE to re-write the code, but so far I haven't made any progress in convincing the right people to let me hehe =)

Nikel

In the case of the first one above I typically use

Code:

---

Dim f as new frmMessageBox

---

This is supported in both VB6 and VB.Net without issue.

In the case of the FSO I avoid it in all cases, It works but it is a vbscript object which imo should be used only in VBScript. VB has much better internal methods that use less resources and are much faster, same is true with .net which has even more internal functions pretty much all of which are better than the FSO.

I'm not sure right off about the as any, I have ran into this but has been a while and my memory is unclear at present.

When you ran the code advisor was that on the exe or the DLL or both?

As for the app not seeing the new function in the dll does this mean you have been sucessful in building the dll since the first post?

I'm using FSO just to check if a File/Folder exists. I thought it was a rather complicated way of doing that, but apparently works. I'm guessing there is a much simplier way? On similar issues, I tried to create a folder after the FSO check returned false, but couldn't get it to work. I used mkdir with no success... nothing critical anyway, but bugs me!

I ran the Code Advisor on both the main project (the exe) and the dll. Sadly, it does not have a group of projects analysis option, but it doesn't matter since it does not analyse code but individual statements. As I said, it's migration oriented, so it doesn't care much about code optimization.

I fixed the app not seeing new functions. I was referencing the .dll file from the main project instead of the actual .dll project, and since the .dll file was never updated because of that other problem, it would never see them.
I still didn't fix the out of memory linker problem, but it's a local problem. Yesterday I tried compiling the .dll project on another computer (an actual Windows XP, not a VM) and it worked. I guess I could build the .dll file every now and then on the other computer and move it to mine to test the standalone app. I would have to try how the remote build .dll file works with the exe file, but I don't have the other computer today =(

I'll run some tests and update again later! Thanks DM!

If you need to check for the existance of a file or folder the VB internal DIR() function will do the trick. MKDir should also allow you to create any needed directories but if memory serves you must do it one level at a time.

In other words MKDIR "c:\Folder1\Folder2\Folder3" will fail if C:\Folder1\Folder2 does not exist already.

FSO is not a huge deal if used very little but it will comsume additional memory which would not be used by other methods.


Here is a little sub routine that creates a directory tree if it does not already exist. You may find it helpful.

Code:

---

Private Sub CreateDirTree(DirName As String)
Dim x As Integer
Dim NewDir As String
Dim tmpString As String

If Dir(DirName, vbDirectory) <> "" Then
    Debug.Print DirName & " Already exists"
Else
    Debug.Print DirName & " Does not exist Creating"
    For x = 1 To ParameterCount("\", DirName)
        If x > 1 Then
            NewDir = NewDir & "\" & ParameterValue("\", DirName, x)
        ElseIf x = 1 Then
            'NewDir = TargetPath
            tmpString = ParameterValue("\", DirName, x)
            NewDir = tmpString
            If Mid(tmpString, 2, 1) = ":" Then
                GoTo Bottom
            End If
        End If
        If Dir(NewDir, vbDirectory) <> "" Then
            Debug.Print NewDir & " Already exists"
        Else
            Debug.Print NewDir & " Does not exist Creating"
            MkDir NewDir
        End If
Bottom:
    Next
End If

End Sub

---

There are calls to 2 other functions these functions basically do a split operation on the string passed into them and then return either the number of elements or the value of an element. They are not included here but you should be able to get a good idea of how dir() and MKDir can be used to check for and create a directory or directory with subs if they do not already exist.

btw the reason this code uses the 2 functions not included is that it was written originally in an older version of VB where the Split() function was not present.