Runing the MFC program in Silent Mode.
-
Is there any way to run a MDI/SDI MFC application in silent mode and pass some files to it? Best, MJM
-
Is there any way to run a MDI/SDI MFC application in silent mode and pass some files to it? Best, MJM
Yes, they're called command-line arguments.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
-
Is there any way to run a MDI/SDI MFC application in silent mode and pass some files to it? Best, MJM
If I understand you correctly, in your app class' InitInstance() you would check if the program was given any command line arguments. If so, instead of your normal processing, you would pass these arguments to a function to do the work and then return FALSE. I am concerned that it is a bad idea as it gives the user no feedback and is left to wonder if the program is running, has finished, or something went wrong & never ran. Hopefully, I have misunderstood you and you want something else.
Please do not read this signature.
-
If I understand you correctly, in your app class' InitInstance() you would check if the program was given any command line arguments. If so, instead of your normal processing, you would pass these arguments to a function to do the work and then return FALSE. I am concerned that it is a bad idea as it gives the user no feedback and is left to wonder if the program is running, has finished, or something went wrong & never ran. Hopefully, I have misunderstood you and you want something else.
Please do not read this signature.
Avi Berger wrote:
I am concerned that it is a bad idea as it gives the user no feedback and is left to wonder if the program is running, has finished, or something went wrong & never ran.
If it's documented, then why not ? I could find a few GUI software that I use that simply do reporting but need to load them, press file open, click on a few options ans save-sa ... if I could simply call them with command line options that would speed up some tasks.
Watched code never compiles.
-
Avi Berger wrote:
I am concerned that it is a bad idea as it gives the user no feedback and is left to wonder if the program is running, has finished, or something went wrong & never ran.
If it's documented, then why not ? I could find a few GUI software that I use that simply do reporting but need to load them, press file open, click on a few options ans save-sa ... if I could simply call them with command line options that would speed up some tasks.
Watched code never compiles.
I would agree that some things would be more effective with a command line entry. GUIs are popular, habit forming, and not necessarily the best way to get things done. My concern is in my (perhaps wrong) interpretation of silent as totally silent. From a console you at least get the feedback of the next command prompt without a "command not found" error to let you know something was done and completed. A "somefile processed" message as well would be nice if provided. I have had some occasion to do general end-user support. When responding I was imagining how some people I have dealt with would react to this. In a GUI environment, they would expect a visual response to their action and would not check documentation for this. I was seeing one of them in my mind double clicking on an icon - nothing happens. (A shortcut can be set up to include command line params) Repeat several times. Call for help, "This software doesn't work". This is exactly how several people I've dealt with would react. Actually, I would want some feedback myself to know that the task was completed. Something could have gone wrong or I might have made an entry error. Let me try to improve my response as follows: This can be a useful, good idea in the right circumstances, but consider being automatic, but not totally silent. Consider providing a progress indicator display or an "I did it" dialog. The dialog can even be self closing after a time-out. Anyway, that's my thoughts. Make any sense?
Please do not read this signature.
-
I would agree that some things would be more effective with a command line entry. GUIs are popular, habit forming, and not necessarily the best way to get things done. My concern is in my (perhaps wrong) interpretation of silent as totally silent. From a console you at least get the feedback of the next command prompt without a "command not found" error to let you know something was done and completed. A "somefile processed" message as well would be nice if provided. I have had some occasion to do general end-user support. When responding I was imagining how some people I have dealt with would react to this. In a GUI environment, they would expect a visual response to their action and would not check documentation for this. I was seeing one of them in my mind double clicking on an icon - nothing happens. (A shortcut can be set up to include command line params) Repeat several times. Call for help, "This software doesn't work". This is exactly how several people I've dealt with would react. Actually, I would want some feedback myself to know that the task was completed. Something could have gone wrong or I might have made an entry error. Let me try to improve my response as follows: This can be a useful, good idea in the right circumstances, but consider being automatic, but not totally silent. Consider providing a progress indicator display or an "I did it" dialog. The dialog can even be self closing after a time-out. Anyway, that's my thoughts. Make any sense?
Please do not read this signature.
Let me hook in... I'll surely understand your point and agree with you, but also consider the possibility that there's no user behind! In my company, busy with machine to machine communication, it is deadly if a piece of code would raise a dialog like 'Work is done press Ok'. Nowadays people tend to think that computers are not of any use if there's no user behind.... The best way to do it (i think): create a interactive and a unattende mode for your program, the interactive mode with user-feedback, the unattended mode with logging feedback...
-
Let me hook in... I'll surely understand your point and agree with you, but also consider the possibility that there's no user behind! In my company, busy with machine to machine communication, it is deadly if a piece of code would raise a dialog like 'Work is done press Ok'. Nowadays people tend to think that computers are not of any use if there's no user behind.... The best way to do it (i think): create a interactive and a unattende mode for your program, the interactive mode with user-feedback, the unattended mode with logging feedback...
I'll agree with your point in turn. Since he was talking about what was a GUI program in the first place, I was assuming this was an environment with a user initiating the execution. If this is actually for unattended operation, as you say, my concern is misplaced. By the way, I don't think of computers only in terms of having a direct human user. I also work on computers with no user, keyboard, or display.
Please do not read this signature.