passing argument

If the app is using MFC correctly you should be able to do this:

MFCApp.Exe "Full\Path\To\File.txt" or whatever the exe and file names are.

BTW, that's if you wanted to pass a file name.  If not, specify what you are tyring to pass to this list and I'll be glad to help.

hiap_ho:
  You can do it just as one does for a console app.  
   To pass parameters, Go to Project, Settings, Debug tab, and enter your data into the Program Arguments edit box.
   Now the hard part.  To retrieve these parameters, add a message handler for the App class's InitApplication.  In this handler, you can retrieve the variable m_lpCmdLine which will be the parameters you entered in the Program Arguments box.
   Glenn

hiap_ho:
   You can also pass parameters to an MFC app via Start,Run
   At the Run dialog box, if, for example, you enter
   FULLPATH\myApp.exe 17
then m_lpCmdLine will be the string "17".
   I just tried it out for an MFC Dialog-based application - works perfect.
 
   Glenn

GlennDean, can you explain more about how to retrieve the argument passed ? NT, Gleen comment is closer to what I want to do. Sorry if my question is a bit confusing.

hiap_ho:
   Can I assume you know how to add a handler for InitApplication?  If not, let me know.  
   m_lpCmdLine is a member of the base class of your application of type LPCSTR.  That string simply contains all the parameters passed to your app. If you entered, eg., 17 0 in the Program Arguments box the string is "17 0"
   Glenn

what should I write in InitApplication handler ?
Mikeblas, I cannot even get the program to accept any argument, what ever argument I put in, the program will give me error.
Let say the program name is program.exe
I would call
program.exe try
it will then give me, error cannot find try in the directory.

what should I write in InitApplication handler ?
Mikeblas, I cannot even get the program to accept any argument, what ever argument I put in, the program will give me error.
Let say the program name is program.exe
I would call
program.exe try
it will then give me, error cannot find try in the directory.

 In your InitApplication, you process the m_lpCmdLine (only you knows what type of info is passed and what you'll do with it).
  From your above comment, it sounds like you're trying to run the app the Run.  You need to type in the full path!
 

I have type the full path but it will always give the the respon that the program cannot find the argument. The exact error will be
fullpath/try is not found.

does not really solve my problem. However my problem is solved now after trial and error, I'll still give the point to mikeblas. I just need to modify the open document file to not open anything to enable my program to accept argument. Thanks all

> program.exe try
 > it will then give me, error cannot find try in the directory.

Oh!  That's something of a different question.

If you've got the stock MFC app setup (as, AppWizard would emit), then your CWinApp::InitInstance() override has code that tries to process arguments on the command line.

As it comes from the AppWizard, an MFC app will have code in it that tries to take any arguments passed to it and treat them as file names that should be opened as the app begins running.  That's why you get the file not found errors.

That code also tries to handle some different options to allow for smooth shell integration and activation via OLE.

The three lines of interest are these, emitted by AppWizard and placed in your app's InitInstance() override:

   CCommandLineInfo cmdInfo;
   ParseCommandLine(cmdInfo);

   if (!ProcessShellCommand(cmdInfo))
      return FALSE;      


ParseCommandLine() takes the m_lpCmdLine member of CWinApp and tries to chop it up. It looks for the filenames and different options that might be presented, and sets member data of the object to reflect those options.

The call to ProcessShellCommand() tries to actually act on those settings. It's these three lines, in concert, that cause your app to interpret your command-line for you.

If you want to forego the DDE, OLE, and shell integration, you can just tear the lines out.  If you want to keep that integration, you'll need to find a way to provide your option so that it's identifiable to parsing code you write yourself. Have your parsing code work in concert with the call to ParseCommandLine() to provide a CCommandLineInfo that both gets valid information back to MFC and gets you the parameter you'd like to have.

If you want, you can derive your own class from CCommandLineInfo and override the ParseParam() member to make the modifications easier and more encapsluated.

..B ekiM

Wow!  I don't think I've ever received a "D" before!

..B ekiM

A D on a 3, lets see, how many points was all that trouble worth after all?

Sorry B ekiM, I didn't see your answer on Wednesday, February 09 2000 - 08:39AM SGT. Thanks anyway, and that also doesn't explain the problem I encountered, I found out why it happened, thanks for all your help. If only I can grade you again. Sorry. I know you try to help a lot.

Anyway, maybe my question is not clear enough, to think of that I think, I'm on the wrong, can you tell me how can I make it up to you ?

NT_Programmer> D on a 3, lets see, how many points was all that
 NT_Programmer> trouble worth after all?

Well, even if it was worth 3000 points, it still wouldn't pay the mortgage.  But even Experts still deserve _some_ pride.

 haip_ho> that also doesn't explain the problem I encountered,  

Given what you've shared with us here, it unquestionably does.

Good luck with your project.

..B ekiM

I'm really sorry, I know I did a terrible thing to you, if only I can make it up.

Anyway it's 30 point I gave, not 3