Re: Page Break in Excel from VB 2005

On Jul 11, 5:37 am, "Stephen Plotnick" <the...@xxxxxxxxxxxxx> wrote:
Seth,

The page break is now working, thanks.

I'm going to start to move the public variables. Is there a reason not to
keep them there? It seems so much easier:)

The reason I did not have the spread*** visible is because this program is
going to run a couple hundred times in a day and the time to open and close
excel itself would be very time consuming. After each run an E-mail is
created with the XLSX and the PDF. You mention a possible memory leak. Is
that a normal concern here?

I did not post the entire program because it is almost 2000 lines long. The
generate lines rountine has many sub routines.

Once again thanks for you efforts. I just can't believe I struggled so long
with what should be something simple like a page break. I'm doing all kinds
of conditional fomratting, etc. without an issues. I guess my first VB
program is more of a learning experience. I've been writing COBOL programs
forever:)

Thanks,
Steve"rowe_newsgroups" <rowe_em...@xxxxxxxxx> wrote in message

news:1184100961.973490.262380@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The generate_rtn is a routie that checks a line counter and based on the
value calls another routine. I have around 40 lines in a text file that
is
being created from another program and I build rows in the spread***
based
on the lines in the text file.

You'll need to add the line counter back then and pass it as a
parameter to the Generate_Report method. I removed it as I didn't see
the point to it at the time (though I guessed it had something to do
with the Generate_Report method)

Thanks,

Seth Rowe


You mention a possible memory leak. Is
that a normal concern here?

Any COM interop project concerns me, as it isn't handled by the
framework's garbage collector. But here my main concern was just
having invisible copies of excel running if the project errored out.

Consider this code:

Sub Main()
Dim excel as new Excel.Application()
Throw New Exception()
End Sub

This would create an excel application and then error out and quit.
The problem is that is you look at the taskmanager you will have a
"excel.exe" running. In a live environment the user might think "maybe
I did something wrong" and run the app again - boom another copy
running. After 12 times the user calls IT complaining of massive
slowdowns, then the IT guy comes after you :-)

I'm going to start to move the public variables. Is there a reason not to
keep them there? It seems so much easier:)

While there is nothing "illegal" about using public variables, it can
be dangerous. One of the foundations of OOP (object orientated
programming) is that of encapsulation. Encapsulation is basically the
idea that an object should be self sufficient and not require or
modify any outside objects - any thing the object needs should be
given it's own copy. This concept prevents problems (particularly in
multithreaded solutions) where variable are modified in unexpected
ways. So while it might not be necessary here, it can/will be a huge
time saver it other projects as these types of errors are some of the
most difficult to find and fix. Also, after you get used to
encapsulated programming, it will be much easier than using and
maintaining the public variables.

Thanks,

Seth Rowe

.