A silly question about getting a program to run

[twgonder]

As mentioned in many of my posts, I come from a mini/mainframe background.


There you write a program in a text editor, compile it and run it.
There were files (like a table) and items (like a record). Each program was an item in a file.
(A line of code was an "attribute" in the item, kind of like a record in an MS file.)
My version of business BASIC called subroutines, either in the same file or to a "cataloged" file. There were no functions as I recall.

You wrote a MAIN program that could then call subroutines, and if needed, these subroutines could pass variables back.
With these commands you created, compiled and ran your program from TCL (a OS command prompt).

Ed filename itemname
Compile filename itemname
Run filename itemname.

Simple enough.

Now here I am in VBA in Access, trying to test code and how things work.
I've got the common stuff figured out as to writing, compiling, decompiling and running code from forms and reports.

But I'm stumped as to the best way to just write some MAIN type code and run it.
First, is there such a thing as a MAIN program in this environment, or is everything a sub or function?
How does one easily test a bit of code, write it as a sub or function and then call it from the immediate window?
Or do most have a simple form with one simple command button to initiate code and test it? If so, do you just put a STOP as the first line to see/step through what's going on?

In other words, I'm not used to having a layer (other than the OS) sitting between me and my code, and I think to start with a MAIN and not subs.
What is best for developers here in Access that want to see behind the curtain without all the foreground stuff cluttering things up?

[ranman256]

try to write AS LITTLE CODE AS POSSIBLE. Most everything a user needs to do can be done with forms , tables,queries, & macros.

Ive seen hundreds of vb code lines written when instead a table could be bound to a combo box, or list. Hours wasted.
Access is for quick development.

Now using vb code you can get some extra things that Access cant normally grab or render.
yes, the immediate window is good for testing. use the breakpoints. hoover over variables to make sure they are assigned correctly.

make sure the DB is split. The frontend for code & forms & reports, the backend for tables.

[orange]

The big difference between your BASIC and Access, is that Access is event driven.

There may be better articles, but that link should be sufficient as far as concept goes.

I also came from Fortran IV and V, PL/1, COBOL...

You may get more insight and perspective by reading a few posts (especially Pat Hartman) in this thread.

[isladogs]

Access is indeed a rapid application development (RAD) tool.
Whilst I would agree about not writing code for its own sake, I would strongly advise against using macros.
Macros are very limited in scope and hard to debug. VBA is much more powerful and the time needed to learn the basics is no greater than the time needed to learn macros

[twgonder]

Thanks for all the great advice and links. I've looked at macros, and don't like them much, being an old-school coder.
I'll check out the links.

[CJ_London]

call subroutines, and if needed, these subroutines could pass variables back.

subs can pass variables back if required - but not as convenient as functions

when you provide parameters to either a sub or function they can be declared as byVal or byRef. The default is byRef. Note in VB it is the other way round so if googling/binging around this subject take note as to whether the author is talking VB or VBA.

byVal means a value is passed, byRef means a pointer is passed. So with byVal your sub can change the value and it won't be passed back. byRef on the other hand is changing the value as directed by the pointer.

e.g.
for byRef
dim A as integer
A=1
mysub(A)
debug.print A 'prints 2

sub mysub(byRef x as integer) 'or sub mysub(x as integer)

debug.print X 'prints 1
x=x+1
debug.print X 'prints 2

end sub

for byVal
dim A as integer
A=1
mysub(A)
debug.print A 'prints 1

sub mysub(byVal x as integer)

debug.print X 'prints 1
x=x+1
debug.print X 'prints 2

end sub

But I'm stumped as to the best way to just write some MAIN type code and run it.

write your code in a standard module, not a form/class module

First, is there such a thing as a MAIN program in this environment

No

or is everything a sub or function?

yes - although without wishing to confuse the issue there are also the get/let/set properties used in class modules

Or do most have a simple form with one simple command button to initiate code and test it?

depends what you are developing - code in standard modules can be started from the immediate window or for those without parameters by clicking somewhere within the sub or function on a valid code line (i.e. not a blank line, dim or comment) and hitting F8 to step through the code or F5 to run the code in its entirety.

If so, do you just put a STOP as the first line to see/step through what's going on?

if you want to stop the code at a particular line of code you can use stop or insert a break point. There are a number of ways to do this - you can select the line and click in the grey bar to the left, or hit F9, or go to debug on the menu and toggle breakpoint.


There is also a more targeted approach you can use using debug. in addition to print, there is also assert. With this you put in a calculation that will return true or false - The logic seems about face, but the code will stop when the return is false. e.g.

copy paste this function to a standard module

Function testAssert()
Dim i As Integer


    For i = 0 To 9
        Debug.Assert i <> 5
    Next i
End Function

when run the code will stop when i=5 because from 1 to 4, i<>5 which is true. but 5<>5 is false, so the code pauses. As I said a bit about face! You can continue running the code by hitting F8 to step to the next line or F5 to continue to the end

can be very useful when iterating though something like a recordset or an array - or just a loop such as above.

The other thing you can do once code is paused is to click on a code line further on in the code and hit ctrl-F8 - code will run to this point and pause again.

Finally you have the Watch window (on the menu View>Watch Window, open it and right click on the watch window and select Add Watch - in the above example use i. As you step through the code, the value increments (in this case on the next i line)

Or you can use the Locals window for more information. But really only worthwhile if you are stepping through the code

[twgonder]

...there is also assert. With this you put in a calculation that will return true or false - The logic seems about face, but the code will stop when the return is false. e.g.

copy paste this function to a standard module

Function testAssert()
Dim i As Integer


    For i = 0 To 9
        Debug.Assert i <> 5
    Next i
End Function

Yep, that's our beloved Microsoft, they got to do everything backasswards from what's worked for fifty years before. I often wonder, was it just lack of experience in the early days of MS, not invented here mentality, or did they have a big meeting and group decide to F with us for fun?

[CJ_London]

guess the logic is 'stop when a condition is not met'

[twgonder]

guess the logic is 'stop when a condition is not met'

Yea, but do you think like that, 99% of the time, when you're debugging?

So, we'll now do this when we want to debug for a positive condition?:
Debug.assert not(i=5 or i=7) ' to expand on your original condition

Thank goodness they started teaching us truth tables in math class some 50 years ago! Someone in education was thinking way ahead to MS days.

[CJ_London]

depends on what needs to be done. 'not' is often used e.g.

if not rs.eof then
'not true code

If you find assert difficult to work with you can just use

if i=5 then stop

[Micron]

All great info - just a comment on the use of break points and macros. I have found that sometimes break points don't remain in place when I want them to. Can't recall exactly under what conditions, but probably was in testing code called by auto exec macro (which is about the only type of macro that is used by coders). I guess shutting down the db was removing the break points. So Stop statement is sometimes useful but perhaps is a bit misleading because in most cases, it's really suspending, not stopping. At least that's my take on it.

Re: Debug.Assert booleanexpression

Conditionally suspends execution when booleanexpression returns False at the line on which the method appears.