|
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 CreateProcess 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
|
|
|
|
|
groover4life wrote:
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?
My idea is this one: One thread updates the data periodically (using an infinite loop with a call to SleepEx in it, to allow the OS to activate another thread, especially important with Win9X OSs), another thread displays these data periodically too (with a timer for example), but asynchronously with the first one. Data protection is then required between the two threads, for example by using a mutex.
It enables to smooth the CPU consumption.
groover4life wrote:
What kind of tricks can I use in OpenGL??
There are plenty technics, you should perhaps refer to the OpenGL Red and Blue Books. You may also find some rules to follow on this page[^]
FYI, I call resident textures bitmaps you may "upload" in the video memory of the video card. Using this instead of standard RAM may fasten a lot the rendering, according to the capacity of the video card and the use of textures by the application.
groover4life wrote:
I always test, but in this case I did not write this code base. I was only left to deal with it
What I meant was that you should be careful the end users of your application may have a computer less powerful than yours, so you should probably have to envisage this case.
HTH,
K.
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:
I always test, but in this case I did not write this code base. I was only left to deal with it
What I meant was that you should be careful the end users of your application may have a computer less powerful than yours, so you should probably have to envisage this case.
LOL! Thanks! But I doubt that my company's clients will have a machine slower than a P-3 450 which is what I'm using for my development.
Dan Willis
|
|
|
|
|
When dealing with OpenGL, GPU is often more important than CPU 
Following the video card, the framerate may vary considerably (i've still experienced a variation from 1.5 fps to 50 fps !)
I hurt so bad inside
I wish you could see the world through my eyes
It stays the same
I just wanna laugh again
|
|
|
|
|
Hi,
I need to draw some text rotated 90º in the screen, for that, what I did is to transform the normal font, and call ExTextOut...
...But I have a problem, with multiline text... with DrawString was now problem give a rect and make the text fit there... but it seems that DrawString doesn't work for rotated text, and does ExTextout support this ?
Thanks in advance, Greetings
Braulio
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
