|
While it is possible, you typically don't draw directly on dialog boxes. What exactly are you trying to do?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
So....did you ever get this working?
Are you using MFC or straight Win32 APIs?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
ya I got it to work got a piece of code from another forum and modified it to fit the project. Thanks for asking.
|
|
|
|
|
Hi all,
How to set MPEG Encoder Filter Properties (DirectShow Filter) using VC++ like,
Audio Bitrate, Video Bitrate, MPEG Type & Field Encoding
How to use Encoder API?
Thanks & Regards,
Aniket Salunkhe
|
|
|
|
|
How do I change the directory beforehand in a File Open dialog? It always goes to My Documents on runtime.
|
|
|
|
|
check out lpstrInitialDir member of the OPENFILENAME structure. See documentation http://msdn2.microsoft.com/en-us/library/ms646839.aspx[^]
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CFileDialog dlg(TRUE,NULL,NULL, OFN_ALLOWMULTISELECT|OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, NULL, NULL );
dlg.m_ofn.lpstrInitialDir = Folder_path; //Give the Folder Path here
//Then give DoModal()
dlg.DoModal();
Thanks and Regards.
SANTHOSH V
|
|
|
|
|
|
Hi Friends,
I want to know, What is the Disadvantage of Multiple Inheritance.
Thanks and Regards.
SANTHOSH V
|
|
|
|
|
That some languges, like Java, hasn't.
Seriously there are gotchas in multiple inheritance, for instance, name clashes and the dreaded diamond. See , for instance http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8[^]
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
With MFC, there's the problem of having more than one CObject -derived parent.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hello all
I am using _beginthread for creating multithreading application.
i want to know that how to pass argument list to hour thread calling function.
i am able to pass one value in this list but now i want to pass multiple arguments to the Thread calling function.
Anybody know this?
Thanks in advance.
Manish Patel.
B.E. - Information Technology.
|
|
|
|
|
You can't do that directly. But one indirect way to do it is to create a structure that contains all your data and pass the pointer to this structure to the function.
A better way to deal with it in OOP is to start the thread from within a class and pass the this pointer to the thread function. Then in your function, you can cast it back to a class pointer and call some public method of your class.
|
|
|
|
|
I want to pass this as well as author local variables of function also.
I am giving below a code sample.
void threadFunction(void *argList)<br />
{<br />
_endthread();<br />
}<br />
void className::methodName()<br />
{<br />
int x = 100;<br />
_beginthread(&threadFunction, 0, )<br />
}
Manish Patel.
B.E. - Information Technology.
|
|
|
|
|
if the thread nees to access className data, then pass this pointer inside the method.
void className::methodName()
{
int x = 100;
_beginthread(threadFunction, 0, this)
}
then you have to cast the pointer inside the thread function, i.e.
void threadFunction( void *p )
{
if ( ! p ) return;
className * pClass = (className *) p;
pClass->m_count++;
...
}
please note: this way you can access all of the (public) class data member, but you cannot access method local data.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
But i want to access local variable of function itself also.
in code x as well as class pointer also.
How can i do it?
Any idea?
Manish Patel.
B.E. - Information Technology.
|
|
|
|
|
Well, as it stands you cannot.
But what about changing a bit you design?
I mean do you really need x as local variable? Cannot it be a class one?.
Or, from an opposite point of view, do you really need to access the entire class? If you need to access a subset of class data, plus some local vars, then you may package that all inside a struct and pass the struct pointer to the thread function.
BTW In fact there is a direct solution of your problem, and it is so ugly that I cannot resist the temptation to post it :
[modified afterwards Cedric Moonen reply :-O ].
class className;
struct MyUglyThreadArg
{
className * pClass;
int * px;
};
class className
{
...
MyUglyThreadArg muta;
void methodName()
{
static int x = 100;
muta.pClass = this;
muta.px = &x;
_beginthread(&threadFunction, 0, &muta);
}
...
};
void threadFunction( void *p )
{
if ( ! p ) return;
MyUglyThreadArg *pMuta = (MyUglyThreadArg *) p;
className * pClass = (className *) p->pClass;
pClass->m_count++;
*(pMuta->px) = 200;
...
}
Please, please, don't do that!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
modified on Friday, December 14, 2007 6:59:21 AM
|
|
|
|
|
Not only is it ugly but it is also buggy: there is a big race condition there. When your function that spawns the thread exit, the muta structure will be destroyed. So, in your thread function you will access memory that has been freed. This will not occur all the time, only if the methodName function exit before the thread function access the variable. This is of course totally unpredictable.
|
|
|
|
|
You're perfectly right.
I've fixed it, to same extent (hazard now applies to further call to methodName , i.e. not thread-safe).
Interesting enough, your suggestion:
Cedric Moonen wrote: A better way to deal with it in OOP is to start the thread from within a class and pass the this pointer to the thread function. Then in your function, you can cast it back to a class pointer and call some public method of your class.
is hazardous too: the bug coming out if the class instance goes out-of-scope while thread function is running.
I've used a lot such (your) scheme with the implicit precondition that class instance remaining alive while thread is running.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: is hazardous too: the bug coming out if the class instance goes out-of-scope while thread function is running.
Not if you take care of that in the destructor . You 'end' the thread in the class destructor (signal an event or a flag) and wait (with WaitForSingleObject) until the thread terminates nicely and then you exit the class destructor. In that way, you will never access an invalid object in your thread method.
|
|
|
|
|
Good point, indeed.
Anyway, there's a caveat: if you use the scenario that breaks my modified ugly code
Cedric Moonen wrote: That's not very usefull: it is kind of a snake that bites its own tail. You pass in a structure which contains a pointer to the class which itself contains the structure. So, what's the point ? So, you still can't pass different 'x' values to different threads (here again, potential race condition). Because I suppose if the OP wanted to do something like that was because he plans to start several threads and pass some specific information to each of them along the this pointer.
it breaks your code too (unless he starts one thread per class instance).
BTW I think he wants to start a single thread hence your solution is good (I think also he probably needs read-only access to local variables).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
A reply to your modifications
That's not very usefull: it is kind of a snake that bites its own tail. You pass in a structure which contains a pointer to the class which itself contains the structure. So, what's the point ? So, you still can't pass different 'x' values to different threads (here again, potential race condition). Because I suppose if the OP wanted to do something like that was because he plans to start several threads and pass some specific information to each of them along the this pointer.
There is a workaround that but which is ugly too: create the structure on the heap and delete it inside the thread function.
|
|
|
|
|
Cedric Moonen wrote: Because I suppose if the OP wanted to do something like that was because he plans to start several threads and pass some specific information to each of them along the this pointer
The above scenario breaks your code too (unless he starts a single thread per class instance).
Cedric Moonen wrote: There is a workaround that but which is ugly too: create the structure on the heap and delete it inside the thread function.
This is useless if he needs write access to method local vars (but why should he need it?).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: The above scenario breaks your code too (unless he starts a single thread per class instance).
Sure. But hey, we both said this kind of code was totally ugly .
(I also *suggested* something like that in my first post but I didn't insist on it because I thought that was too ugly to be posted )
|
|
|
|
|
Thread management is not trivial. You need to have a clear understanding of what is involved in order to use them effectively. Simply using a class pointer as the thread argument can lead to trouble; as has been mentioned, consider,
class gladiator
{
gladiator() {}
virtual ~gladiator()
{
_beginthread(&threadFunction, 0, this);
}
static void threadFunction(void *pargList)
{
if (!pargList)
return;
gladiator * pActor = static_cast<gladiator *>(pargList);
_endthread();
}
};
This highlights that the owner of a thread needs to manage the thread lifetime. There are numerous ways to do this but if you use the class object then the class should hold on to the handle returned by _beginthread and insure proper thread termination before object destruction.
class gladiator
{
gladiator()
: m_bThreadAlive(false),
m_bStopThread(false),
m_hThread(-1)
{
m_hThread = _beginthread(&threadFunction, 0, this);
}
virtual ~gladiator()
{
shutdown();
}
protected:
bool m_bThreadAlive;
bool m_bStopThread;
HANDLE m_hThread;
virtual void shutdown()
{
if (m_bThreadAlive) {
do {
m_bStopThread = true;
} while (m_bThreadAlive);
}
}
static void threadFunction(void *pargList)
{
if (!pargList)
return;
gladiator * pActor = static_cast<gladiator *>(pargList);
pActor->m_bThreadAlive = true;
while (!pActor->m_bStopThread) {
}
pActor->m_bThreadAlive = false;
_endthread();
}
};
Note, the destructor for the gladiator class has a potentially endless while loop. A bug in the threadFunction while loop may prevent it from exiting properly. This is why the thread handle is needed to force the thread to exit if it fails to respond to the request to terminate (m_bStopThread). You can use whatever condition you want in shutdown() but it has the final say on the thread lifetime,
void shutdown()
{
if (m_bThreadAlive) {
m_bStopThread = true;
long lCoundown = 10000L;
do {
if (--lCoundown < 1L) {
if (!TerminateThread(m_hThread, -1)) {
}
m_bThreadAlive = false;
}
} while (m_bThreadAlive);
}
}
Threads have potential problems with concurrent data access as well (see EnterCriticalSection, etc.) and you probably want to look at using events (see CreateEvent, etc.) to communicate.
|
|
|
|