S
steveeisen
I'm a long-time VB6 programmer in a shop that is mostly moving to VB
..NET 2005. And I'm confused about coding the start of solutions for
unattended operations.
Much of what I write is old-time batch. Such programs are started from
a scheduler and run on a server, cycling through a mass of data,
without human intervention. No form should show on the server monitor,
although an invisible one may be needed to support the Winsock or other
control.
In VB6, I usually have a Main routine in a standard module as the
startup. But in a VB 2005 Windows Application, the startup has to be a
form, even if you don't have any intrinsic need for one.
I briefly looked into console applications, but never need a DOS-type
window. And console applications seem out of the question because they
require giving up ApplicationEvents.
Code like this does work to turn a Windows Application into what I am
used to:
Public Class MyUselessForm
Private Sub MyUselessForm_Load(ByVal sender As System.Object, ByVal
e As System.EventArgs) Handles MyBase.Load
Main()
End Sub
Sub Main()
' do the real processing starting from here
End
End Sub
End Class
However, there must be something slicker. Before I start using the
above many times, does someone have a better idea? And, no, going back
to COBOL won't be better
Steve Eisenberg Pennsylvania U.S.A.
..NET 2005. And I'm confused about coding the start of solutions for
unattended operations.
Much of what I write is old-time batch. Such programs are started from
a scheduler and run on a server, cycling through a mass of data,
without human intervention. No form should show on the server monitor,
although an invisible one may be needed to support the Winsock or other
control.
In VB6, I usually have a Main routine in a standard module as the
startup. But in a VB 2005 Windows Application, the startup has to be a
form, even if you don't have any intrinsic need for one.
I briefly looked into console applications, but never need a DOS-type
window. And console applications seem out of the question because they
require giving up ApplicationEvents.
Code like this does work to turn a Windows Application into what I am
used to:
Public Class MyUselessForm
Private Sub MyUselessForm_Load(ByVal sender As System.Object, ByVal
e As System.EventArgs) Handles MyBase.Load
Main()
End Sub
Sub Main()
' do the real processing starting from here
End
End Sub
End Class
However, there must be something slicker. Before I start using the
above many times, does someone have a better idea? And, no, going back
to COBOL won't be better

Steve Eisenberg Pennsylvania U.S.A.