0

I have a console application that shows latest activities & status on its console. The application is heavily threaded & performance is the major concern. No user interactivity is required. Due to a recent case, ive been asked to migrate it to a win form application.

Initial post -> How to programmatic disable C# Console Application's Quick Edit mode?

So to encounter the problem, I have used Application.Run(ApplicationContext context) so to start a message loop in my console application so that i can hook and trap mouse events and can reset quick edit mode at runtime. I have also deleted a Console's default menu item "Edit" that emerges on right click so not to allow the user to Mark/Copy/Paste.

I want to know what should be the optimal solution, migrating to win form or console app (considering changes i made). Also i need to call Invoke every time in order to put the task in UI's queue so to print the message if migrated to winform.

Community
  • 1
  • 1
Himanshu
  • 507
  • 1
  • 6
  • 10
  • 2
    Did I get you right - the **only** reason for migrating to Winforms is that you want to **prevent** the user to interfere with the output? So you are adding a GUI to the application because you really **don't** want one? Sounds wired. – Doc Brown Dec 01 '12 at 10:23
  • exactly !! :) It happened once, our application was live and Console halts because of entering quick edit mode. – Himanshu Dec 01 '12 at 10:27

2 Answers2

2

WinForms would definitely give you more flexibility in what you can do with the UI.

In terms of performance, you really need to be doing a lot of UI updates in order for performance to be a concern. It sounds like that will not be the case since you're currently getting it done with a console application. Most of the time, the UI performance is affected not because the UI thread can't keep up with the updates, but because non-UI stuff (e.g. file IO, database queries, etc.) is done within the UI thread.

Eren Ersönmez
  • 38,383
  • 7
  • 71
  • 92
1

I would consider to change your application so that it streams it's output into a logfile, a lightweight database or a Windows event log instead to the console. Thus your application won't need a console or UI at all and can be alternatively run as a service. If someone wants to see that messages, give him a separate (probably Winforms) program to view the latest output, or if you use the Windows event log, he can just use the Windows Event viewer to check the output of your program.

So you neither have to migrate you application to Winforms, nor do some ugly console hacks.

To process log files, the Microsoft log parser may be of interest for you.

Doc Brown
  • 19,739
  • 7
  • 52
  • 88
  • Thank you, that's useful intel. In App, Logging is also done along with printing some critical events messages on Console UI. A minimum of console or a ListView is essential to view some real time critical events. – Himanshu Dec 01 '12 at 12:18
  • @Himanshu: I guess that is just some superstition. If those "time critical events" are monitored by a human, the time constraints low, and there is absolutely no reason why the event display cannot be done in a separate application, getting the data from the log. – Doc Brown Dec 01 '12 at 16:54
  • yes you are right that can be a optimum solution with a separate log viewer app to display the data coming from logs. – Himanshu Dec 01 '12 at 18:05