alreadyused
Well-known member
- Joined
- Jan 13, 2006
- Messages
- 70
First off I hope I am posting this to the right forum. Were using external apps and communicating through their dlls, so I think this is in the right spot.
We have a console app that automates printing; the user sends a list of requests, then the app retreives the docs, creates the appropriate class for that type of doc, does some work to it, then prints to the requested printer.
We have a main class that communicates with the other classes to perform the work (one finds/holds/tests the external app instances, one is a factory for creating the appropriate worker class, etc)
We have a sub main that launches the main class. We need the app to persist, and want the user to be able to type exit, but we also want to send the status to the console.
So this is what we had:
Up until recently, this was working fine. But then we added a VB6 app into the mix, and we started getting the non-pumping error. I immediately assumed that it was because of that loop and ReadLine. To me what it was saying is that were blocking the main thread and thats causing issues.
I guess at this point, its obvious that Im weak on threading, right? By adding a reference to System.Windows.Forms and then adding Application.Run() into the Do Loop, we have worked around it and the error goes away.
But, I have this nagging suspicion that this isnt the best way to do it and its going to sneak up and bite us later.
Is there a better way to do it? Or a tutorial I need to read/do?
-----------------------------
EDIT: I just found out that because of the Application.Run() statement, the loop is no longer effective. Thats not a big deal, it was only there to keep the application alive anyway.
So now the app persists until a ctrl+c, alt+f4, ...
I read something on here yesterday that when doing an Application.Exit(), it still tries to call the dispose methods, we just may not see it while debugging, but its not safe to rely on that. Im not calling app.exit, but Im assuming that the above are the equivalent to doing so?
So I still have the question of, does anyone have any suggestions on what would be better?
We have a console app that automates printing; the user sends a list of requests, then the app retreives the docs, creates the appropriate class for that type of doc, does some work to it, then prints to the requested printer.
We have a main class that communicates with the other classes to perform the work (one finds/holds/tests the external app instances, one is a factory for creating the appropriate worker class, etc)
We have a sub main that launches the main class. We need the app to persist, and want the user to be able to type exit, but we also want to send the status to the console.
So this is what we had:
Code:
Public Shared Sub Main(args() as String)
...
Dim myClass as new MyClass()
myClass.doSomeStuff
...
Dim doExit as boolean = false
Do
Dim s As String = System.Console.ReadLine()
If s.ToLower() = "exit" Then doExit = True
Loop Until doExit
finalize
...
End Sub
Up until recently, this was working fine. But then we added a VB6 app into the mix, and we started getting the non-pumping error. I immediately assumed that it was because of that loop and ReadLine. To me what it was saying is that were blocking the main thread and thats causing issues.
I guess at this point, its obvious that Im weak on threading, right? By adding a reference to System.Windows.Forms and then adding Application.Run() into the Do Loop, we have worked around it and the error goes away.
But, I have this nagging suspicion that this isnt the best way to do it and its going to sneak up and bite us later.
Is there a better way to do it? Or a tutorial I need to read/do?
-----------------------------
EDIT: I just found out that because of the Application.Run() statement, the loop is no longer effective. Thats not a big deal, it was only there to keep the application alive anyway.
So now the app persists until a ctrl+c, alt+f4, ...
I read something on here yesterday that when doing an Application.Exit(), it still tries to call the dispose methods, we just may not see it while debugging, but its not safe to rely on that. Im not calling app.exit, but Im assuming that the above are the equivalent to doing so?
So I still have the question of, does anyone have any suggestions on what would be better?
Last edited by a moderator: