Question Showing feedback in a self-running application

[vali1005]

Hello everyone!

I am looking for suggestions on how to see what an application is doing(by way of components attached to the main form, be it labels or Status Bar), when that application runs without any input action from the user.


To explain in more detail:

I have an application(just one form), that executes several subroutines, depending on what buttons the user is pressing. These subroutines show the progress of their code through messages in a label attached to a StatusStrip component.
I have been asked to implement in this application the ability to execute the above mentioned subroutines in an "unsupervised, no user input required" mode. So, basically, based on the value of some command line parameters, the application should execute the same code that gets run when the user does work with the application.
Ideally, I would like to be able to see, in "unsupervised" mode, the messages shown by the StatusStrip component when the application runs in "supervised" mode. But, so far, it seems the only workable avenue of implementing "unsupervised" mode is to place the "autorun" code in the Form_Activated(...) event. Looking at my legacy VB6 applications for which I have implemented this kind of functionality, I noticed that I had placed the "autorun" code at the end of the Form_Load() (with the restriction that I wouldn't be able to close the application, since the program would get upset if I would attempt to close it in its Form_Load(...) event). If wanting to see the visual feedback in such type of execution mode is a very non-trivial task, I don't have a problem giving up on it, but I would sure like to know if there is a much better way("the right and proper way') to do "unsupervised" mode.

So, is it possible in VB.NET 2005 to achieve this kind of functionality in a much more streamlined and elegant way, when compared with VB6? If "Yes", how? Ever since I started working with VB.NET, I have hoped that, when I would get to the point where I would have to convert/implement this type of feature, there would be a more intuitive way of doing this, but, so far, it seems the only reasonable thing to do is just to replicate line for line what I did in VB6.

Thank you!

 

[Tom]

I may be misunderstanding what you asking but wouldnt a stacktrace display what you want?

 

[vali1005]

I may be misunderstanding what you asking but wouldnt a stacktrace display what you want?

I am using a StatusStrip because I am showing custom messages about what the application is doing, like "Processing input files", "Parsing record 3 out of 2100" or "Calculating output values". The problem is that the Activated(...) event is fired before the Shown(...) event, so, if the "unsupervised" code is placed in the Activated() event, when the "unsupervised" code executes, none of these messages on the StatusStrip can be seen, since the form is not shown yet. When the application is in "supervised" mode, it gets to the point where its form is fully painted and is awaiting an action from the user.

So, my question is, where can I place code that gets run just based on the value of a command line parameter(and is able to also close the application), and, at the same time, being able to see the fully painted form, rather than what gets drawn before the Shown() event?

 

[Tom]

OK, there's lots of different options to keep a recorded history.

One option/suggestion, instead of a status bar which you have to keep overwriting one line, change it more into more of a multi-line log.

This could be implemented many different ways but for example in the VB development area, at the bottom of the screen you can see different docked panel windows (Command window., Immediate window, Error List etc). You could add whatever controls you want and have your coding just keep adding new lines of text to the control.

When the form load completes, you can then scroll the control to view its actions.

~~~~~~~~~~~~~~~~

Another option, just append your line statements to a file or even something in memory like an array. And then offer an option such as a Viewer Button that will open a new form that will display the results.

Does this meet your request/needs?

 

[Tom]

Don't know if you want to get this carried away but yet another option is to write each statement as a database table record, and then bind a control to display the results.

 

[vali1005]

So, my question is, where can I place code that gets run just based on the value of a command line parameter(and is able to also close the application), and, at the same time, being able to see the fully painted form, rather than what gets drawn before the Shown() event?

Ok, then, the above quoted functionality, is it not possible to be achieved?

If I want to execute subroutines just based on the value of a command line parameter, are the Load() and Activated() events my only 2 options for placing that code?

I just realized, as an answer to my initial post, I can place a Timer component on the form, and, if the program is loaded in "unsupervised" mode, I will have the Timer run the "unsupervised" code from its event. This should take care of fully painting the form as well as being able to close the application when the execution of the "unsupervised" code is done.

And I agree on the execution log file, that will definitely be a feature of the application, what I wanted was to be able to give updates on what's going on while the application runs(since it closes itself after it has finished the execution of the "unsupervised" code)

 

[JohnH]

So, my question is, where can I place code that gets run just based on the value of a command line parameter(and is able to also close the application), and, at the same time, being able to see the fully painted form, rather than what gets drawn before the Shown() event?

Nothing gets drawn before the Shown event... Solution is easy, use multithreading, read some tutorials about it. BackgroundWorker component is the first choice for beginners, throw one on your form (with WorkerReportsProgress option True) and add this sample code:

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    Dim args() As String = Environment.GetCommandLineArgs
    If args.Length > 1 Then
        Me.BackgroundWorker1.RunWorkerAsync(args(1))
    End If
End Sub

Private Sub BackgroundWorker1_DoWork(ByVal sender As System.Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles BackgroundWorker1.DoWork
    Dim command As String = CStr(e.Argument)
    If command = "count to 3 and close" Then
        Me.BackgroundWorker1.ReportProgress(0, 1)
        Threading.Thread.Sleep(1000)
        Me.BackgroundWorker1.ReportProgress(0, 2)
        Threading.Thread.Sleep(1000)
        Me.BackgroundWorker1.ReportProgress(0, 3)
        Threading.Thread.Sleep(1000)
        e.Result = "close"
    End If
End Sub

Private Sub BackgroundWorker1_ProgressChanged(ByVal sender As Object, ByVal e As System.ComponentModel.ProgressChangedEventArgs) Handles BackgroundWorker1.ProgressChanged
    Me.StatusLabel.Text = CStr(e.UserState)
End Sub

Private Sub BackgroundWorker1_RunWorkerCompleted(ByVal sender As Object, ByVal e As System.ComponentModel.RunWorkerCompletedEventArgs) Handles BackgroundWorker1.RunWorkerCompleted
    If CStr(e.Result) = "close" Then
        Me.Close()
    End If
End Sub

It is also possible to get the command line arguments in Shown event, run code synchronously and close form from there, but threading is the way to go if you run work for some time and reports to UI.