I have a VB6 app that compiles and runs fine (previous version).
I added code to the main form and a couple of classes and modules and it
compiles.
These are all interconnected and used in another app that works fine.
I was adding feature to this app.
With or without Properties/Advanced Optimizations all checked or not.
Compile with no errors.

However, when I try to start the compiled .exe it does nothing.
When I try to start the app in the IDE if fails at the third code line in
the Sub Main where I am setting the main form.

Previous lines are simple assigns.

Public fST As frmST

Set fST = frmST    ' frmST is the main form

I stepped through and it only gets to thei line and does not get into the
form.

Gives an unhandled win32 exception occurred in VB6.EXE [nnn]
Where [nnn] comes up with a different numbers every time.

So, I deleted all the temp files.
I disconnected all the AddIns.
Still nowhere.

The message also says that Just-In-Time debuging can be enabled from
Tools/Options/Debugging/Just-In-Time
There is no such option in the IDE.

I have around 330 MBytes of available physicall RAM and lots of virtual.
The app compiles to around 1.5 MBytes

Suggestions please.

Show quote Hide quote Try:

Set fST = New frmST

I guess I should have said that I already did try New.  Same results.
I know I am nearing the limit on controls for the form.
Unfortunately I have no easy way to see where I am at.
Although I would think that if I could compile, I have not actually reached
that point and I did not get the "too many controls" message.
And no,  MZ-Tools does NOT tell you that number, the control count includes
all Indexes of a control.
Is there another tool?
Maybe a tool that analyzes the source.
I do not know how to run a debugger so that leaves me without that in-depth
visibility.


Show quoteHide quote

Show quote Hide quote Here is code that counts the number of controls, and control names count,
but I doubt that you reached that limit(254 control names, but you can have
more as control arrays).

I am not sure what are you trying to do, but try New, and also fST.Show,
because forms are not shown automatically. The code below counts the number
of controls and control names by analyzing the header. Each control is
listed separately, including those who are part of control arrays with the
word "Begin ControlType ControlName". The header ends with the word "End" by
itself in one line. The code ignores properties contents, such as Caption
and Text properties, including multiline texts, which is not saved in the
header, but in FRX file.

Option Explicit

Private Sub Form_Load()
    Debug.Print "Control names count: " &
GetControlNamesCount("C:\Test\Form1.frm")
End Sub

Private Function GetControlNamesCount(ByRef sFilename As String) As Long
    Dim f As Long
    Dim sLine As String
    Dim sLineNoSpace As String
    Dim c As Long
    Dim oNamesCollection As New Collection

    f = FreeFile
    Open sFilename For Input As f

    c = -1 ' Start from -1 because the form itself doesn't count as a
control
    Do While (Not EOF(f)) And sLine <> "End"
        Line Input #f, sLine
        sLineNoSpace = Trim(sLine)
        If Left(sLineNoSpace, 6) = "Begin " Then
            Debug.Print sLine
            c = c + 1
            On Error Resume Next
            oNamesCollection.Add sLineNoSpace, sLineNoSpace
            On Error GoTo 0
        End If
    Loop

    Close f

    Debug.Print "GetControlNamesCount: Total controls " & c

    ' Add -1 because the form itself doesn't count as a control
    GetControlNamesCount = oNamesCollection.Count - 1

End Function

It is probably time you learned.

Not really being a smart-a** it is just that there comes a time in every
programmer's life when they need to learn how to use a debugger. Within the
IDE one can do a lot with the adroit use of breakpoints, Debug.Prints,
MessageBoxes, etc. but there always comes a time when errors occur just
slightly out of sight. lol

First step is to instrument a just-in-time debugger.
Try installing Dr. Watson - Use the run command to launch "DrWtsn32".
Click on Help to learn how to use it.
To instrument Dr. Watson type "drwtsn32 -i" then run your program.

Dr. Watson should help narrow down the problem.

[The type of message you reported is also symptomatic of an invalid or
inappropriate JIT Debugger. But no need to go there yet. lol If you have
trouble instrumenting Dr. Watson, report back. Have you installed one of the
..Net Framework development platforms lately? What O/S are you using?]

For a more robust debugger I suggest you download the WinDbg appropriate for
your operating system.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
This tool is frankly over-whelming for anyone at first. But note you don't
have to know everything to use it. Often just the ability to identify which
component is the troublemaker is enough.
You can also use WinDbg as a JIT.

Oh, while you are in a downloading mood navigate over to SysInternals:
http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx
Download the suite.
Again most of this will be greek, but it will all come in handy sooner or
later.

-ralph

Hmmm. DrWtsn32, WinDbg, and SysInternals.

Good stuff there Ralph, think I'll do some downloading myself.
Thanks for the excellent insight.

Then you may also be interested in the following API Calls

Private Declare Sub DebugBreak Lib "kernel32" Alias "DebugBreak" ()
Will automatically cause a breakpoint exception (int 3) and signal WinDbg
(or any active debugger) to launch.

Private Declare Sub OutputDebugString Lib "kernel32"
    Alias "OutputDebugStringA" (ByVal lpOutputString As String)
Will output a string to SysInternal's DebugView (or WinDbg).

Microsoft's documentation is a bit terse - "Just the facts, mdm!"
Google for "WinDbg Tutorial" for several fast-track guides for using WinDbg
(and JIT/Dr. Watson).

hth
-ralph

More tools for the toolbox, Thanks Ralph.


Show quoteHide quote

Show quote Hide quote Why are you creating a new object for a form that already exists?

All you need in the sub main to make the form display is:

frmST.Show

None of this:

Public fST As frmST
Set fST = frmST    ' frmST is the main form

is needed.

Thanks for the suggestion, but that failed at frmST.Show too.
All the code ran up to the last line in Sub Main which is frmST.Show

Why not? seems more "objecty", force of habit, nobody said not to ...
Any of these a good excuse?

What harm does it do?
Still learning ...

Show quoteHide quote

One important reason; it adds more room for error....

LFS

<snipped>
<snipped>
Show quoteHide quoteUnnecessary but useful, especially for a situation like this.

Whatever the problem is, it is caused by something that occurs during the
several stages a Form goes through on its way to being displayed. Without a
Sub Main it is very difficult to trap (or rather 'hold' a program at a
particular point).

Also, the OP isn't creating a "new object for a form that already exists".
All the OP is doing is providing another reference variable. The inherent
Form reference variable is nothing more than a hidden declaration that looks
like this ...
      Public frmST As New frmST

-ralph

Could you elaborate on that? "Interconnected and used in another app"? What
is "interconnected and used in another app" and how? Is this a straight up
EXE project or an ActiveX EXE, DLL? Or are the modules shared among numerous
projects?

The code is not easily added incrementally.
It has to be woven in to the new app that is already quite large.
Approaching the max number of controls on my main form.
I have gone through it and reduced the number of unique controls so I have
room to add theis code again now.
The code is being used in another app without problems.
Maybe I will get lucky or smarter this time.
Either way I win.

Show quoteHide quote

When I saw "interconnected and used in another app" I thought perhaps you
might be dealing with binary compatability and a broken interface. If it's a
matter of sharing code/modules between projects, I have found Visual Source
Safe to be a great tool for that.



Show quoteHide quote

Are all of these projects the same type? All ActiveX, or all Standard EXE?

If there are public classes shared between standard EXE and ActiveX
EXE/DLL/OCX projects, then VB6 would auto change Instancing property to
Private when you load the standard EXE project. A warning appears when this
happens, and you are prompted to save during exit even if you didn't change
a thing. If you open the source file with Notepad, you would see a hidden
text header at the beginning of the file. VB6 could change these attributes
when switching between ActiveX and non-ActiveX, and that's way you are
prompted to save. Don't edit these values in Notepad.

When you later load the ActiveX EXE/DLL/OCX project; which use the same
classes source, VB6 would find that Instancing property value has changed to
"Private"(assuming that in the ActiveX it was set to something else, like
Multiuse), and would complain about binary compatibility, so you have to
change Instancing property every time you switch between these projects, or
use separate files.

GW-Basic
Help with a bit of maths
Anyone know of a good Help Authorizing Tool
Create Icon File From Resource
Getting pixels from EMF (StdPicture)
GetObject with VB6 ActiveX exe
Prohibit Paste
Changing a property on a control
Vista and AutoRedraw
Phone system integrated in vb app