|
I tried taking the .cpp file that I wrote it in and adding that to my project file list. I also put #include "stdafx.h" in the header of my .cpp program. When I build/compile the .exe Project file it says no errors, but when I try to execute it, nothing comes up on screen. Should I be linking the .cpp program file into another Project File(using Public)? Maybe there are too many Source files now that I added my .cpp program to the source file list? Maybe it is not possible to incorporate a QuickWin.exe program into a Windows App. Project? My books do not tell me how to do this. Can I just copy and paste the code into the Project .CPP file? Any help thanks.
|
|
|
|
|
JFSabastian wrote: ...when I try to execute it, nothing comes up on screen.
As opposed to what?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
What I should come up on the screen is a spreadsheet grid from the Project code and then I was hoping my program would run and ask the user a series of questions, it is a series of questions and numerical answers. Then it asks the user if he wants to quit the program and it exits. Both the spreadsheet grid(AppStudio) and the ABV.CPP program were created in Visual C++, but the spreadsheet grid is a Project and the ABV.CPP is a C++ program I wrote. I just want to incorporate that C++ program into the Spreadsheet Grid Project so I can show the user his data and maybe a chart. I would also like to have dialog created in AppStudio as opposed to my MSDOS black screen, white letters ABV.CPP program. Is that possible? Could I cut and paste my code into the project somehow or can I simply link the program to the project?
|
|
|
|
|
JFSabastian wrote: What I should come up on the screen is a spreadsheet grid
Using printf() , cout , or something else?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Hi,
I am trying to create a console program that uses MFC framework. More specifically.
1. The user would input commands/options/etc. into the console. Essentially a shell.
2. The shell will parse the command and send the information to a dll I wrote that will format the command and send to an external hardware.
3. The hardware does whatever and sends result/update, which is received by another thread and the message is formatted and sent up to a pipe.
4. I first wanted to use another console screen to display the message from the pipe, but I found out an application can't have more than 1 console screen. So I decided to use MFC to create a window to simply display the message. I have a class derived from CWinThread to do this, but I am not sure how to tie in the frame/document/view without using the document template. All the MFC documentation/references all state that I need to use document template, but since AddDocTemplate is member of CWinApp not CWinThread I am not certain how I can associate frame/view/document.
I am using VC++ 6.0 so I guess that means I am using MFC 6.0
Is what I am trying to do not possible? and should I try a different route like creating a separate application to display the messages on the pipe?
Thanks for any help.
|
|
|
|
|
Hi.. I'm using visual c++ v9.0 express. When I try to run the executable in other machine ( that doesn't have visual c++ isntalled and with framework 2.0) the program does not run. It says that the problem could be solved by reinstalling the program.
Can I solve this?
Thank you.
"Failure is always an option."
|
|
|
|
|
FrankMookie wrote: Can I solve this?
Yes. See here.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
thanks!
"Failure is always an option."
|
|
|
|
|
I am learning Design Pattern and who can give me a easy example
I write some demo but I think they are not good so I wanna get some good
one that can make me understand the pattern better.
Thanks a lot!~
|
|
|
|
|
This is a meaningless question. Which pattern ? I suggest buying a good book and reading on both patterns, and their examples.
Christian Graus
No longer a Microsoft MVP, but still happy to answer your questions.
|
|
|
|
|
One more question
Product
+Method() +FactoryMethod()
| |
| |
| |
ConcreteProduct<-------------ConcreteCreator
+Method() +FactoryMethod()-----return new ConcreteProduct
In the demo code of Factory Pattern they use return to new
a ConcreteProduct object
<br />
Factory* fac = new ConcreteFactory();<br />
Product* p = fac->CreateProduct();<br />
what about using a member variabal of Creator to control Creator's behavior
like:
<br />
Product* p = new CreateProduct();<br />
Factory* fac = new ConcreteFactory(p);<br />
and use like "fac->_p->method()" to call different subclass member funtion
is it good or not to use a abstract class object as member variabal to control its behavior ???
|
|
|
|
|
|
Thanks
i am new with Disign Pattern
It's so helpful
|
|
|
|
|
I'm using ParseCommandLine to read command line arguments. I give the command line in debug mode with Project->Settings->Program Arguments. But ParseCommandLine thinks there are no args. I've seen the contents of m_lpCmdLine, and it correctly shows the args as I've given them.
So I step into ParseCommandLine, and it goes here:
void CWinApp::ParseCommandLine(CCommandLineInfo& rCmdInfo)
{
for (int i = 1; i < __argc; i++)
{
LPCTSTR pszParam = __targv[i];
BOOL bFlag = FALSE;
BOOL bLast = ((i + 1) == __argc);
if (pszParam[0] == '-' || pszParam[0] == '/')
{
bFlag = TRUE;
++pszParam;
}
rCmdInfo.ParseParam(pszParam, bFlag, bLast);
}
}
But it never enters the cycle - __argc is 0.
Interestingly, __argc is not a variable but a function, for argc it goes here
_CRTIMP int * __cdecl
AFNAME(__argc) (void)
{
return AFRET(__argc);
}
And ParseCommandLine works in another project from which I copied/pasted the code.
What might be causing this problem?
Thanks.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
sashoalm wrote: But it never enters the cycle - __argc is 0.
What should it be? Have you looked at __argv[0] et al?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
The command line was like this
"C:\Path\File1.pdf" "C:\Path\File2.pdf" "C:\Path\File3.pdf" "C:\Path\File4.pdf"
so __argc should be 4
And CWinApp::m_lpCmdLine shows the command line as it should be. Why ParseCommandLine doesn't work when the command line correctly reaches CWinApp::m_lpCmdLine?
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
But what does __argv[0] , __argv[1] , ... look like? What does your InitInstance() method look like?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
class CommandLineParser : public CCommandLineInfo
{
public:
virtual void ParseParam( LPCTSTR lpszParam, BOOL bFlag, BOOL bLast )
{
...............
}
};
BOOL CMyWinApp::InitInstance()
{
AfxEnableControlContainer();
#ifdef _AFXDLL
Enable3dControls();
#else
Enable3dControlsStatic();
#endif
...............
CommandLineParser parser(m_aFileList);
ParseCommandLine(parser);
...............
return FALSE;
}
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
What happens if you try not using your CommandLineParser class
(just to test)...
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
I tested this by setting the Project Settings/Configuration Properties/Debugging/Command Arguments
to C:\Path\File1.pdf C:\Path\File2.pdf C:\Path\File3.pdf C:\Path\File4.pdf
and stepped into ParseCommandLine(). All four parameters are fine.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I added this code to my InitInstance,
int argc = __argc;
char* arg1 = __argv[0];
char* arg2 = __argv[1];
char* arg3 = __argv[2];
CommandLineParser parser(m_aFileList);
ParseCommandLine(parser);
and the count and the arguments were correctly shown when debugging. But when I step into ParseCommandLine, the arguments are wrong there (they caused an access violation so they must be NULL)!
Is this a linker problem? I use MFC as a DLL.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
So have you tried this instead:
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo); to eliminate the possibility that your CommandLineParser class is causing problems?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Yes, I've tried, but arguments are still wrong in ParseCommandLine. I think it might be a linker problem. The MFC dll is linked to a different CRT than the exe. Is that possible and can I do something about it?
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
sashoalm wrote: The MFC dll is linked to a different CRT than the exe.
I hope you know what you're doing there.
For more info on what you can/can't do with MFC DLLs:
Kinds of DLLs[^]
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
No problem there. We're using vc6 with mfc 4.2. You'd have to be running Windows 3.1 not to have the dlls (ok Windows 95)
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
I have no idea what you're talking about.
I'm talking about mixing CRT libraries between DLLs and EXEs.
I'm not sure what a DLL has to do with this anyway, unless your InitInstance
is in the DLL, in which case the commandline stuff will probably fail
if the DLL is using a different CRT.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|