Stone Wall
Bee
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.
Nobody
news:72E9EBED-5C56-4B0B...@microsoft.com...
Try:
Set fST = New frmST
Bee
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.
Steve Easton
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.
--
Steve Easton
Nobody
>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.
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
Bee
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 ...
Larry Serflaten
"Bee" <B...@discussions.microsoft.com> wrote
> What harm does it do?
> Still learning ...
One important reason; it adds more room for error....
LFS
Desi
> These are all interconnected and used in another app that works fine.
> I was adding feature to this app.
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?
Ralph
"Steve Easton" <ad...@95isalive.com> wrote in message
news:eySmcO63...@TK2MSFTNGP06.phx.gbl...
>
> "Bee" <B...@discussions.microsoft.com> wrote in message
> news:72E9EBED-5C56-4B0B...@microsoft.com...
> >
> > 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.
> >
>
> 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.
>
Unnecessary 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
Ralph
> 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.
>
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
Desi
Good stuff there Ralph, think I'll do some downloading myself.
Thanks for the excellent insight.
Ralph
"Desi" <nos...@thanks.net> wrote in message
news:ODY7vwI4...@TK2MSFTNGP06.phx.gbl...
> 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
Bee
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.
Desi
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.
"Bee" <B...@discussions.microsoft.com> wrote in message
news:6209E531-856C-4890...@microsoft.com...
Desi
> Then you may also be interested in the following API Calls
> -ralph
Nobody
> These are all interconnected and used in another app that works fine.
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.