|
|
Koma Wang wrote: I want to set a 25 hours timer...
Have you tried setting a 60000ms timer and when the timer has "fired" 1500 times, you know that it has been 25 hours?
Another option would be to create a scheduled task within Windows and let it handle when to run the program.
"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
|
|
|
|
|
thanks !
I used Windows Task Scheduler instead.
|
|
|
|
|
Hi,
I often hear or read about Parent/Child relationship with regards to Process
but is there any relationship with regards to threads
For instance if Thread A AFXbeginThread B and Thread B AFXBeginThread C
if thread A goes away do Thread B and C still live as long as the process is alive
thankx
|
|
|
|
|
ForNow wrote: if thread A goes away do Thread B and C still live as long as the process is alive
yes
|
|
|
|
|
If you are using Nested Threads like NT as main thread & T1 & T2 are as two sub thread under NT, then the answer will be YES.
But, other than called it as parent-child relation, I would rather like to call it as ordered relation, like threads will execute,in an order they are placed in the program.
As threads are mainly uses systems resources, so one can not delete a thread until that gets completed.
NOTE: though using various time slashing algorithm one can switch between threads if he/she wants.
--Rupam
System Analysts
|
|
|
|
|
There is no parent-child relationship that I'm aware of, but there's one caveat: if the main thread dies (the thread that calls WinMain ) dies so does the entire process.
Steve
|
|
|
|
|
Is a CWinAPP so special or does the process need at least one thread alive
|
|
|
|
|
Every process has one main thread of execution. On windows threads are getting scheduled, not processes.
|
|
|
|
|
It's not CWinApp that's special, the "specialness" is at a lower level. When a process starts its initial thread calls WinMain[^]. This thread can create as many threads as it likes and they in turn can do the same, but as soon as the the initial thread exits the process is history. MFC is built on top of Windows, and the initial thread is the one that's generally going to be executing CWinApp 's methods. So yes, a process does need at least one thread to be executing: the initial one.
Steve
|
|
|
|
|
I am a college student, looking to participate in an open source project. The only experience I have is class work, and I want to start participating in "real world" programming. I was wondering if anyone could point me in the right direction to find a project I might be able to help with. Thank you for any advice you can give.
Jason
|
|
|
|
|
well ... it's kind of easy no ? just think a little bit : one word.
Linux
From that simple world you will find thousands of opensource projects you can put you hands into.
Choose the application domain you feel you will like the most (or want to learn the most), for example don't do 3D stuff if you don't like it, or scientific software if you like music producing)
or you your favourite search engine with keywords like "open source project"
Good luck.
Watched code never compiles.
|
|
|
|
|
www.sourceforge.net
Biggest Collection of OpenSource projects
|
|
|
|
|
You should find a project which you would like to use but is not exactly what you need. This way you will have motivation as well as new features which you can add to the system.
-Saurabh
|
|
|
|
|
While working with ListView I started adding case WM_NOTIFY to the parent window message loop.
Although it was empty, but when I ran the app all the columns that used to be populated are now empty!
What kind of problem could I be looking at?
|
|
|
|
|
Take a look at where you added this case entry to make sure it is not falling through the loop. Also review the function/block where you fill your columns.
It's time for a new signature.
|
|
|
|
|
Function/block is fine, after removing WM_NOTIFY everything returned as normal.
How can it be falling through the loop?
|
|
|
|
|
Fareed Rizkalla wrote: How can it be falling through the loop?
Not having Superman vision I have no idea. Try posting an extract of your code so people can see what you have done/are trying to do.
It's time for a new signature.
|
|
|
|
|
(1) is the case WM_NOTIFY followed by a break?
(2) are the WM_NOTIFY messages forwarded to the base / default window proc?
|
|
|
|
|
What parameters do I need to specify in order for the ComboBox to accept more text than the visible area has to offer?
|
|
|
|
|
Suppose a class in C++ has a pointer in it.
class
{
int*x;
}
Then what all precautions we need to take regarding handling the pointer?
|
|
|
|
|
There are two ways of dealing with pointer members:
Default Constructor
e.g. initialize to NULL or allocate memory
Destructor
free memory if allocated and the class "owns" the memory
Copy Constructor & Assignment Operator
Handle them correctly - e.g. free the memory allocated
it is good practice to use one class per unmanaged resource.
|
|
|
|
|
peterchen wrote:
it is good practice to use one class per unmanaged resource.
Since when?
I know it sounds good in theory and even I got carried away at first. Since they, I've discovered that encapsulating functionality is far more useful, even if that means you have a few handles and pointers to maintain. I have a specific class that I've done both ways; the latter is far more elegant and easier to understand/debug/maintain.
modified on Sunday, April 11, 2010 8:02 PM
|
|
|
|
|
Maybe I need to clarify: It is not fun to have multiple unmanaged resources as members of a single class.
Reasons:
First, writing the Constructors sucks. When allocating multiple resources in a single constructor, you have to deal with cleanup of a partially constructed class.
(This can be leveraged by some code layout - initializing all to NULL handles before allocating everything, and a separate cleanup function that is called on construciton failure and in the DTor.)
Second, you are encapsulating at the wrong level. When one class holds two file handles you are not only replicating code within the class. The bnext time you write a class holding a file handle, you will again have to implement/block the Default + Copy CTor, DTor and Assignment Operator for a properly behaving class.
In Practice:
I wrote "good practice", not "mandatory" or "the only way to avoid ridicule". I understand that each and every rule puts pressure on the final code. All code can ignore some pressure, good code uses the same constructs to deal with different types of pressure, but at some point the requirements will fight against each other - you can't always satisfy all of them perfectly. We only have cures, not panaceas.
For a large majority of my "need to manage some resource" needs I use CHandleRefT[^] - it isn't perfect, but it works well. The fundamental deviation from OO best practices is to wrap only the resource, not the operations. This weakens encapsulation, but immensely strengthens adoption: supporting a new type of resource is just a few lines without member-to-API forwarding, and the "managed" resource can be used transparently with most native code.
|
|
|
|
|
peterchen wrote: The bnext time you write a class holding a file handle, you will again have to implement/block the Default + Copy CTor, DTor and Assignment Operator for a properly behaving class.
If you choose to have copy constructors and assignment operators, you still have to write them with a class full of encapsulated objects.
The alternative is to block copy constructors and assignment operators, which is quite easy. I have quite a few classes where I do that.
(For the record, I've encapsulated a file handle and synchronization objects, though I don't always use them for various reasons; I make a decision on a case-by-case basis, based on what is best for that class, not on any rules.)
peterchen wrote: you have to deal with cleanup of a partially constructed class.
I can't remember the last time I even worried about that; I just write my code such that it's irrelevant AND so that a class always constructs. (I don't do this in C#, but I accept slow and bloated in C#, but not in C++.)
|
|
|
|