|
In project-->Settings-->General
For MFC: Use MFC in shared DLL.
Then in the start of main():
if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
{
cerr << _T("Fatal Error: MFC initialization failed") << endl;
return 1;
}
else
{
}
That should do it...
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
using C++
Ask the user to input his date of birth (dd/mm/yyyy), preform error checking for the input and if there's an error ask the user to input the date of birth again,, then calculate the 10,000 days anniversary in (AD & BC) formats then display the new date of birth on the screen.
thank you.
|
|
|
|
|
Sounds like you need to do your own homework
|
|
|
|
|
come on bro it's due tomorrow and i'm new in using C++
it's a major assignment ... plz
|
|
|
|
|
Major assignment, due tomorrow and you haven't yet started?
Get your act togeheter or please look for another field of work.
(Posts like these really pisses me off, sorry)
|
|
|
|
|
Stefan Pedersen wrote:
Major assignment, due tomorrow
If this is a major assignment, I'll have to go back to school again. I used to write this kind of code in my sleep
Michael
Fat bottomed girls
You make the rockin' world go round -- Queen
|
|
|
|
|
LOL... his words, not mine.
|
|
|
|
|
looks like you'll have to find a sucker somewhere else.
Jason Henderson start page ; articles
henderson is coming
henderson is an opponent's worst nightmare
* googlism *
|
|
|
|
|
I have a question for you. I can write the code you need in about 15 minutes. However, if I do, what will you do when your next assignment is due, the one that assumes you learned this stuff ? Are you going to pay me to do your homework between now and graduation ? Or do you expect me to do it for free ? What about when you start your job, and you know nothing because you were too busy getting drunk to learn this (basic) stuff ? There are three possibilities here.
P1. You were too lazy to go to class/pay attention.
Solution: come clean ( or fake major illness ) and hand it in late. IF you try to do this yourself and get stuck, people here will be glad to help. We just don't 'do' homework for lazy people.
P2. You are too stupid to program computers
Solution: become a plumber
P3. Your teacher is inadequate.
Solution: If this is the case, your fellow students will be as clueless as you, so go together to the administration of the school and complain.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
You need to provide more information.
What GUI library are you using? Is it a Windows app? The input side would be straight forward using an MFC CDialog class and the DateTime picker common control. (Although it won't support BC formats as Windows is limited in its time ranges)
The COleDateTime and COleTimespan class will do the maths on the entered date for you.
Michael
Fat bottomed girls
You make the rockin' world go round -- Queen
|
|
|
|
|
it is a win32 application using visual C++
|
|
|
|
|
if doing a console app, use cin and store the data to a std::string or CString. Parse the string using '/' as the delimiter, and put the day, month, year into their own variables. Do all the logic and math, put a new string back together using sprintf() or CString::Format(), then use cout or printf to display the results.
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
LOL - I guarentee that you've both told him what to do, and told him nothing
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
Christian Graus wrote:
I guarentee that you've both told him what to do, and told him nothing
sounds like Microsoft help. LOL no offence, just kidding.
|
|
|
|
|
hello,
how can i kill/terminate a 16-Bit process creates with Createproces(...).
With 32-bit processes I can call EnumWindows() but with 16-bit there is no result.
How can I solve it?
|
|
|
|
|
You may use ExitProcess coupled with GetExitCodeProcess , or CloseHandle , or ... Just make a search for CreateProces s in the MSDN, thy give you a bunch of solutions.
~RaGE();
|
|
|
|
|
I tried to search in MSDN before i hat posted.... nothing about terminating an 16-Bit process. The problem is, CreateProcess give me no ProcessID, ProcessHandel, .... (because of 16-Bit)
|
|
|
|
|
Hi All,
I'm having a serious performance issue and I'm hoping I can get some help here. Here's what I have:
I have a C++ dll that creates a dialog box for displaying graphics. This dll uses STL vectors and maps to maintain the data passed in. I then use OpenGL to generate the graphics that are displayed in the dialog window.
At the moment I am generating a WM_TIMER message to pump the dll with data. But, the application is a CPU HOG, and pins the CPU when ever I start pumping messages . This is not acceptable as I'm sure you may know. In addition, I NEED to be updating the screen at a rate of 30-50 frames per second, and I don't think a WM_TIMER message will allow me to update at that rate.
Any ideas? Any suggestions? Comments?? I'm really stumped with this one.
Thank you in advance.
|
|
|
|
|
Instead of WM_TIMER, what about a separate thread to manage the data when another thread manages the display ? it would suppress the "synchronization" between data managment and display.
You may also use some OpenGL tricks to improve the framerate, as the use of resident textures for example. However, if the framerate must raise a certain limit, it would be perhaps more careful to test first if it's possible according to the available hardwares, or it could get strange on graphically slow computers.
HTH,
I hurt so bad inside
I wish you could see the world through my eyes
It stays the same
I just wanna laugh again
|
|
|
|
|
KaЯl wrote:
Instead of WM_TIMER, what about a separate thread to manage the data when another thread manages the display ? it would suppress the "synchronization" between data managment and display.
Currently, even though the dialog is in a dll, I am using MFC MDI as a wrapper around the whole thing.
So in essence what you are saying is; Instead of using the WM_TIMER message, create a thread that just performs a basic loop, getting the data and updating the display, and the update rate will be what ever the CPU slice is for that particular thread?
KaЯl wrote:
You may also use some OpenGL tricks to improve the framerate, as the use of resident textures for example.
What kind of tricks can I use in OpenGL?? I'm not super familiar with it. What do you mean by using resident textures?? What other tricks would help improve frame rate? I should be able to figure them out if I have a direction to head in.
KaЯl wrote:
However, if the framerate must raise a certain limit, it would be perhaps more careful to test first if it's possible according to the available hardwares, or it could get strange on graphically slow computers.
I always test, but in this case I did not write this code base. I was only left to deal with it.
Once again, thank you.
Dan Willis
|
|
|
|
|
|
Sorry,
I am using NT-based Operating systems. I.E. NT 4.0, Win2k, XP (home & Pro)
Dan Willis
|
|
|
|
|
groover4life wrote:
So in essence what you are saying is; Instead of using the WM_TIMER message, create a thread that just performs a basic loop, getting the data and updating the display, and the update rate will be what ever the CPU slice is for that particular thread?
wait, wait, wait... Use the loop in the thjread for data mainpulation only, and pump custom messages out of the thread to the UI thread and handle the redraw and stuff in the UI thread as a message handler. I've had very bad experiences when trying to access stuff outside of my own little thread, but the PostMessage thing works very well. NT should get you pretty accurate down to around 10ms or so, so that is about a 100Hz refresh. (You'll need to do a Sleep(10) or whatever to delay the thread.) Make sure you aren't doing very time consuming stuff here either, as that will begin to affect your performance. Remember, NT is not an RT OS, so you are at the mercy of other higher priority things on the PC. There are some articles around here about using multimedia timers for better precision, but I haven't used any of them yet.
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
Nitron,
This seems like a viable solution to my performance issue. I believe I will take this approach, then go back into the OpenGL code and see what I can do to optimize there. At least I don't need it to be real time as Windows is not a RTOS, but it should give me the refresh rate which I need.
Also, Do you think it will hurt having to access my document object to dump the data into? I don't have to manipulate the data alot.
do you think this will also help my CPU HOG issue as well? I may have some more questions once I design and implement this method (will take me most of the afternoon as the application is pretty complex in nature).
Thank you so much for the suggestions and comments. Keep 'em coming! Whoo Hooo!
Dan Willis
|
|
|
|