|
minkowski wrote: So basically, anything that is in the for loop is only executable by 1 thread
Yup.
minkowski wrote: If so, what if I have some member functions for a class, say a get() and a set() and I only want one thread at a time to access either of them
Same sort of thing - using the same threading classes as before:
class MyClass
{
void SetMyObject(SomeClass const& value)
{
boost::mutex::scoped_lock lock(objectMutex);
myObject = value;
}
SomeClass SetMyObject() const
{
boost::mutex::scoped_lock lock(objectMutex);
return myObject;
}
private:
SomeClass myObject;
boost::mutex objectMutex;
};
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
So from your example, say one thread accesses the SetMyObject() , given that there is a lock in the function, it will also lock the GetMyObject() blocking any other thread from calling?
This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct?
Thanks again for your help.
|
|
|
|
|
minkowski wrote: So from your example, say one thread accesses the SetMyObject() , given that there is a lock in the function, it will also lock the GetMyObject() blocking any other thread from calling?
Yes
minkowski wrote: This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct?
Sort of - any function that attempts to acquire (lock) the mutex will be serialized, as only one thread can acquire the mutex at a time. So, that means if you have a group of functions that acquire the lock, only one of that group can be executed concurrently.
There are other sorts of locks that may better suit different situations (semaphores, read-write locks) - part of learning how to design multi-threaded systems is knowing which sort of synchronisation mechanism to use.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hey thanks for that, it tidied up some of my uncertainties.
I was wondering how C++ knows to lock the other member function if one is being accessed by another thread. In the thread constructor itself you pass in either a function pointer or overloaded operator() in your class. So for the case of an object, there must be some reference to the this pointer for the object for it to know to lock the other member functions if a lock is in place from another thread. Was wondering if this is correct?
Thanks for any information.
|
|
|
|
|
minkowski wrote: I was wondering how C++ knows to lock the other member function
It doesn't.
The locking is contained within the mutex implementation. When you acquire a mutex, you either get retun immediately with ownership of the mutex, or your thread waits inside the OS until you do get ownership.
minkowski wrote: Was wondering if this is correct?
As explained above, no 
Can I suggest you read up on how mutexes[^] work[^]? That should maybe make things a bit clearer...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Oh I see, so since its the same lock object ( objectMutex from your example in the get() and set() functions) of course it will be locked?
|
|
|
|
|
That's it. So, as each instance of MyClass has a separate instance of objectMutex, you can access different instances of MyClass concurrently on separate threads, but not the same instance (because the mutex will stop you).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Ah excellent. Makes sense! Thanks for your time (and patience!)
|
|
|
|
|
My pleasure
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hello,
Does anyone know of a way to disable the "What's This?" menu (appears after right-clicking on certain items)? I would like to disable it on my "Save As" dialog. I've created a class for the dialog and it is inherited from the CFileDialog class. I have looked at many places on the internet, but I'm unable to find what I need. Any ideas on this would be appreciated.
Regards,
Mike
|
|
|
|
|
Sounds like you need to remove the WS_EX_CONTEXTHELP style.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
In the OnInitDialog function of my class derived from CFileDialog, I have the following:
GetParent ()->ModifyStyleEx(WS_EX_CONTEXTHELP, 0);
The only difference I noticed was that the question mark button, which is normally located to the left of the close button (the X), disappeared. The What's This? is still showing.
Regards,
Mike
|
|
|
|
|
I guess I misunderstood what you were after. I do not know of a way of removing that little context menu. I guess you could try hooking the Save As dialog and then intercepting the right-click message.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
// ----------------------------------------------------------------------------------------------
// myfiledialog.h
// ----------------------------------------------------------------------------------------------
#pragma once
#include "afxdlgs.h"
class CMyFileDialog :
public CFileDialog
{
public:
CMyFileDialog(void);
~CMyFileDialog(void);
virtual BOOL OnInitDialog();
};
// ----------------------------------------------------------------------------------------------
// end myfiledialog.h
// ----------------------------------------------------------------------------------------------
// ----------------------------------------------------------------------------------------------
// myfiledialog.cpp
// ----------------------------------------------------------------------------------------------
#include "stdafx.h"
#include "myfiledialog.h"
#include "resource.h"
CMyFileDialog::CMyFileDialog() : CFileDialog(FALSE,0,0,OFN_EXPLORER|OFN_PATHMUSTEXIST|
OFN_HIDEREADONLY|OFN_LONGNAMES|OFN_OVERWRITEPROMPT| OFN_CREATEPROMPT)
{
}
CMyFileDialog::~CMyFileDialog()
{
}
BOOL CMyFileDialog::OnInitDialog()
{
CFileDialog::OnInitDialog();
GetParent ()->ModifyStyleEx(WS_EX_CONTEXTHELP, 0);
return TRUE; // return TRUE unless you set the focus to a control
}
// ----------------------------------------------------------------------------------------------
// end myfiledialog.cpp
// ----------------------------------------------------------------------------------------------
I hope this helps.
Regards,
Mike
|
|
|
|
|
Just out of curiosity, why derive a class from CFileDialog rather than just create an instance of it?
UINT_PTR CALLBACK OFNHookProc( HWND hdlg, UINT uiMsg, WPARAM wParam, LPARAM lParam )
{
return 0 or 1;
}
CFileDialog fd(FALSE, 0, 0,
OFN_ENABLEHOOK | OFN_EXPLORER | OFN_PATHMUSTEXIST | OFN_HIDEREADONLY | OFN_LONGNAMES | OFN_OVERWRITEPROMPT | OFN_CREATEPROMPT);
fd.m_ofn.lpfnHook = OFNHookProc;
fd.DoModal();
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
The application I'm working with uses a CFileDialog format, except for 2 buttons that have been added to the dialog. This is the reason for deriving from CFileDialog.
Anyway, after trying your code, I'm still seeing the "What's This?" menu. When I debug your code, and set a breakpoint in OFNHookProc, the breakpoint is reached several times, but is never reached when I click on a button using the secondary mouse button. When I click on a button using the secondary mouse button, the "What's This?" menu appears. I tried both return values (0 and 1 from function OFNHookProc) with no success.
Regards,
Mike
|
|
|
|
|
Michael Adamus wrote: Anyway, after trying your code, I'm still seeing the "What's This?" menu.
I simply provided you a starting point. You'll need to do some research in order to fill in the blanks. There are no guarantees that this will work, but at least you'll have found one more way that doesn't. You can use Spy++ to see the relationships of that dialog. The hook procedure is actually for the child dialog of the main dialog. You can even customize the child dialog by providing your own template.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
OK, thank you for your time and effort. Hopefully, I'll be able to figure out how Spy++ works by doing my own research.
Regards,
Mike
|
|
|
|
|
Hello all,
I have an application in MFC single document and i want to put a ".jpg" picture as a background and over there, want to drawing some handwriting text. Background always fixed, handwritten text always change when i open a text file. Text file contains some pixel value, and i draw some text depend upon that values.
Please help me.
Thanks to all
Shaheen
|
|
|
|
|
Hello.
First of all, have you read this[^] yet? If no, do it now, if yes, you should know by now that if you don't ask specific questions then you are not likely to get usefull answers. Noone will tell you here how to write an application that will perform what you want. Try to do it and when you get stuck with it, come here and ask, "i did this and that and this and that happens, any ideas why and how to do it right?" instead of "Hey, i want to write a program, so tell me how.". Good luck with your project.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Shaheen.India wrote: I have an application in MFC single document and i want to put a ".jpg" picture as a background...
Does this help?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
I use a window with horicontal+vertical ruler from COXRuler and COXRulerOrganizer class (Ultimate Toolbox).
Both start in the left upper corner with the origin. The values on the horicontal ruler grows from left to right. I need a possiblity to change the origin from the horicontal ruler to the right side, so that the values grows from right to left.
It would be a great help for me, if there is somebody with more experience or an idea for a workaround.
Coach Greg
|
|
|
|
|
I'm trying to take an existing class and add a member function to it. Something like this:
class baseclass {
public:
baseclass();
baseclass(int i);
~baseclass();
public:
int a() {
int b() {
}
class derived : public baseclass {
public:
derived() : base();
derived(int i) : base(i);
public:
int sum() { return baseclass->a() + baseclass->b(); };
}I know I have to explicitly declare the constructors, but I'm under the impression that a() and b() are inherited without further effort. Which means if I create an object derived d, then int i = d.a(); is a valid expression.
Do I have to "explicitly inherit" a() and b() in order to use them in sum() ?
I've been all over the documentation and the articles here, but can't seem to track this down.
More nooB questions, I know - any help is appreciated.
MZR
|
|
|
|
|
no need to any further steps. as you've publically inherited from base class, the public and protected attributes and functions are part of derived class.
<blockquote class="FQ"><div class="FQA">Mike the Red wrote:</div>int sum() { return baseclass->a() + baseclass->b(); }; // I DO know it's not done like this...</blockquote>
It should be
int sum() { return baseclass::a() + baseclass::b(); };
is it really not possible for you to call d.a()? what's the problem you're facing?
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
Mike the Red wrote: Do I have to "explicitly inherit" a() and b() in order to use them in sum() ?
I've been all over the documentation and the articles here, but can't seem to track this down.
What's wrong with:
class baseclass
{
public:
baseclass(){}
baseclass(int i){}
~baseclass(){}
public:
int a() {return 1;}
int b() {return 2;}
};
class derived : public baseclass
{
public:
derived(){}
derived(int i):baseclass(i){}
public:
int sum()
{
return a() + b();
}
};
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
