question on the "Immediate Window"

[jolene_keagy]

This must be easy.. but I can't find an option to fix it.. When I start any VB project.. the 'immediate window' pops up every time.. without me requesting it. Is there a way to shut this off???
Thx!
jk

[dglienna]

If I close the immediate window before I close the IDE, the next time the IDE starts, the immediate window is NOT shown. There is also a checkbox under Docking Options under Tools -> Options, that will get rid of it for you.

[jolene_keagy]

Tried both those things already. The dockable option is just that.. just gives you the option to dock or not. I know I can close it and it will go away if I run the prog again.. but I open so many different programs in an 1 hour period (just learning vb.. studying a lot of different stuff), that it's driving me crazy that it always pops up..
I appreciate you looking though.
Any other ideas?
Thx,
Jolene

[dglienna]

just delete the .vbw file before you open a .vbp file, and a new .vbw will be created using your options.

I just tried it, and the immediate window did not open.

[Tec-Nico]

I know this will sound silly, but the Immediate Window is your friend. I would suggest to move it and adapt it to the size you prefer rather than closing it completely.

Now, I will show some pictures of how to do that.

Step 1. This is how the problem looks like (At least for me)... If yours doesn't look like this one then please tell me so.

[Tec-Nico]

Step 2. Drag the Immediate Window to the bottom, so it will look like in this picture (You could also drag it to the left or the right, but I believe it is better in the bottom)

[thegreatone]

This window never shows up on my VB, what it is used for ?

[Tec-Nico]

Finally, your Immediate Window should look like this last picture.

Note you can make it as big or as small as you want.

[Tec-Nico]

Press ctrl + g and the Immediate Window will appear.

This window is used for debug purposes. For example, lets say you are not sure if a certain function is being called, so you do something like this:

 Public Function IsNumber(strToCheck As String) As Boolean
   Debug.Print "IsNumber(" & """" & strToCheck & """" & ") is being called"
    IsNumber = IsNumeric(strToCheck)
 End Function

It can also help you see how things are going through a piece of code, to see if it is doing as you expected.

That's in general terms, of course.

[BuggyProgrammer]

You can also execute one-line code there, like: (? is short for Print, which prints text in the debug window )

?Mid(FileName,Instr(FileName,".")+1)

or

For i = 1 to 10:Msgbox i:Next

etc.

You need to either be in debug mode or IDE. Not while the program is 'Running'.

[dglienna]

I didn't think that it was in the way...

[szlamany]

I actually have a second monitor (17" flat screen) attached to my laptop so that the immediate window will have a place all it's own.

We use a DEBUG.PRINT statement at the top of each and every event, function and subroutine. That way the IMMEDIATE WINDOW prints a "constant" trace of the flow of the program as it runs. We put additional DEBUG.PRINT's into places where important things occur - so they are obvious as well.

Something like this:

Private Sub cmdState_Click(index As Integer)

Dim i As Long, j As Long, k As Long, x As Long, y As Long, z As Long
Dim s1 As String, s2 As String, s3 As String, s4 As String, s5 As String

Dim lngSS As Long, lngSE As Long, lngKeyDown As Long

Dim booAbove As Boolean, booBelow As Boolean, booNoPilot As Boolean

Dim intCAI As Integer, intFS As Integer

Debug.Print "cmdState_Click w/Index=" & Str(index)

On Error GoTo Error_Handler

Begin:

    x = Me.mintTabNo
    intFS = Me.mintFormState
    
    If intFS < 5 Then
        lngKeyDown = gfrmKeyDown(x)
        gfrmKeyDown(x) = vbKeyReturn
    End If
    
    Call SetState(Me, index + 1, intFS)

    If intFS < 5 Then gfrmKeyDown(x) = 0 'lngKeyDown
    
Rtn_Caller:

    If Not booNoPilot Then Call FocusPilot(Me, 0, 0, 0, (intFS))

    Exit Sub

Error_Handler:
    Call Fatal_Error(Err.Number, Err.Source, Err.Description, "cmdState_Click")
    Resume Rtn_Caller

End Sub

I've been coding for a living for 25 years now. All development that I do is done a couple of lines of code at a time, followed by setting breakpoints at the new code and using the immediate window and other debug techniques to verify that the code does in fact work.

There is nothing better then breaking at a new line of code, changing the value of some variables in the immediate window and then continuing to step through the code. You can test all kinds of conditions and walk away from that new code with it fully tested.

Recently we added some DOEVENTS at some bad spots in a program. We were able to compare the IMMEDIATE WINDOW from before we broke the program and after we broke the program (with WINDIF - a great little utility). We instantly found out what routine was no longer firing in the right spot and were able to pinpoint where the bad DOEVENT was added.

[Tec-Nico]

Nice tips, Buggy. I didn't know you could use the : in that way. I will make good use of them.

I would do as szlamany, but I don't have as many years programming and I don't have a laptop to spare and do that. But if I could, I would because it is a very good idea.

[westconn1]

szlamany,

i use the immediate window for debugging, but am always finding it in the way, how do you set it up to show in a different monitor?? i would like to display that and the locals window.

my debugging techniques are nowhere as good as yours, i keep stopping the program and stepping, when it doesn't seem right. i also sometimes write out to a log file in case the exe does things different than the ide.

rgds peter

[RobDog888]

To get any of the windows to display on your second monitor, just drag the
window to the other monitor, which will un-dock it. Windows remembers the
positions of your windows, so thats all there is to it.

HTH

[szlamany]

szlamany,

i use the immediate window for debugging, but am always finding it in the way, how do you set it up to show in a different monitor?? i would like to display that and the locals window.

my debugging techniques are nowhere as good as yours, i keep stopping the program and stepping, when it doesn't seem right. i also sometimes write out to a log file in case the exe does things different than the ide.

rgds peter

Stopping the program and stepping is a great technique - it's all about watching what you just coded actually perform. And in VB with the ability to edit code and continue - it's extremely powerful (I hear that VB.Net got rid of this - and VB6 was the first time I've ever experienced it - what a shame!).

As RD says, just use the dock/undock feature and move it to the other monitor (sometimes you have to use the OPTIONS menu to control this). Size it to fill that monitor and it sticks. When I boot the laptop at home without that monitor, it kind of uses the upper-right corner of the main display, and when I get back to work, it's home'd right in on the extra-monitor.