|
Hello,
it took me a while to figure it out how this class works. Here is a sample in Managed C++:
ManagementObjectCollection ^c = query("Win32_DiskDrivePhysicalMedia");
for each(ManagementObject ^o in c)
{
DeviceInfo ^device = gcnew DeviceInfo();
ManagementObject ^media = gcnew ManagementObject(o["Antecedent"]->ToString());
ManagementObject ^disk = gcnew ManagementObject(o["Dependent"]->ToString());
Object ^temp = disk["Manufacturer"];
if(temp) device->manufacturer = temp->ToString();
temp = disk["Model"];
if(temp) device->model = temp->ToString();
temp = media["SerialNumber"];
if(temp) device->serial = temp->ToString();
list_->Add(device);
}
The class Win32_DiskDrivePhysicalMedia only contains references to the Physical Media and Disk Drive objects. You must, then, instatiate both objects to access their properties individually.
Regards,
Paulo
|
|
|
|
|
Are there any caveats in using ::WaitForSingleObject(…) with CMutex? MSDN article for ::WaitForSingleObject(…) says that it’s possible to use it with a mutex. However, the program hangs, when I try to Lock() the mutex.
Mutex is constructed together with a resource that it guards. The constructor for CResource is called in the main thread. Interestingly, the call to Lock() in the constructor succeeds.
CResource::CResource()
: m_mtxParse(FALSE)
{
m_iData = 0;
}
Then the pointer to the resource object is passed to two (2) worker threads that manipulate and read the guarded data through two (2) methods.
called only by the 1st thread
void CResource::IncrementData()
{
m_mtxParse.Lock();
for (int i = 0; i < 10; ++i)
{
++m_iData;
::Sleep(100);
}
m_mtxParse.Unlock();
}
called only by the 2nd thread:
int CResource::GetData()
{
::WaitForSingleObject(m_mtxParse.m_hObject, INFINITE);
return m_iData;
}
So, what are the limitation for ::WaitForSingleObject(…) with CMutex?
1. The purpose of mutex is to allow only one thread at a time to execute a certain code and to block all othre threads. I positively can make the mutex work this way, if I don't call ::WaitForSingleObject(...) on my mutex. Why does ::WaitForSingleObject(...) screw up the call to CMutex::Lock()? That's what's bugging me!
2. If I understand the ::WaitForSingleObject(...) correctly, it should be able to wait for a mutex. So I can make another thread (which never even tries to execute the code protected by the mutex) to wait until the other thread is done. I had acheived this functionality with CEvent, and I can, probably use a combination of CEvent and CMutex. But, I think, I should be able to wait for a CMutex and I don't need CEvent.
Do I have a wrong understanding of CMutex and ::WaitForSingleObject(...)?
If I have the right understanding, what's wrong with my code?
Cheers,
Nick
P.S. If you want to post an alternative solution (e.g. use CEvent instead of CMutex), please be so kind and do so only after you explain why the present approach will not work. I’m asking you to do this, because primarily I want a direct answer to my direct question. I’m learning multithreading, so my interest is academic (not commercial). I also know about some of the alternative solutions already. Thanks!
|
|
|
|
|
Your second thread isn't releasing the mutex which it has taken ownership of by calling
WaitForSingleObject()...
int CResource::GetData()
{
::WaitForSingleObject(m_mtxParse.m_hObject, INFINITE);
int RetData = m_iData;
::ReleaseMutex(m_mtxParse.m_hObject);
return RetData;
}
*EDIT* Modified to actually protect the object you are protecting 
|
|
|
|
|
Thanks for the explanation! I see: I didn’t realize that ::WaitForSingleObject(…) not only waits for the mutex, but also acquires the mutex. However, this also means that only one thread at a time will be able to read the variable. I want multiple threads to be able to read the variable simultaneously, if it’s not being written, and to block, if the variable is being written. I guess, I should use both CMutex to protect the variable from simutaneous writes and CEvent to protect from simutaneous write+reads.
|
|
|
|
|
You can look for some good examples of reader-writer locks, using mutexes and semaphores.
I think there are some code articles posted here to CP for them too.
|
|
|
|
|
hello friends . i wrote a game with TC++ v3.0 and i want to develop it in linux . if is possible describe that how and with what kind of programming LANGUAGE i can work ?
a day without learning is a lost day
|
|
|
|
|
active66 wrote: . if is possible describe that how and with what kind of programming LANGUAGE i can work ?
i believe you are on Wrong forum.... you can find only Windows addicts here!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and you
|
|
|
|
|
Greetings:
I am trying to figure out how to create a very general window in MFC out of thin air.
Without getting into the grim details, I have a simple MFC application - no Doc/View. When the app launches, a naked CMainFrame is displayed with no child window over it. It is colored with COLOR_APPWORKSPACE. This is the way we wanted it for a variety of reasons.
Now, there is a menu item that must create a very simple window - like a minimal CView - and displays it in the Main Frame as a child window. I do NOT want to maximize this new window to fit the entire client area of the main frame. I would like the new window to have boarders and a caption and the option to maximize but not much else.
I cannot seem to make this happen under MFC. Can anybody help?
Thank you in advance.
Mark
|
|
|
|
|
MFC windows are created in two steps - one for the C++ CWnd object and one for the Windows HWND.
CWnd *pWnd = new CWnd();
pWnd->Create(NULL, _T("Window Name"), WS_CHILD|WS_VISIBLE|WS_OVERLAPPEDWINDOW, CRect(10,10,100,100),
pParentWnd, ID_CHILDWND, NULL);
If you want the window to do something useful you'll probably want to derive your own window class
from CWnd.
If you want to use extended window styles you can use the CreateEx() method.
Destruction of windows is generally two steps as well (CFrameWnd-derived windows are an
exception).
pWnd->DestroyWindow();
delete pWnd;
-- modified at 17:48 Thursday 28th December, 2006
Changed the WS_ styles.
|
|
|
|
|
Try this style in the sample code I posted (I changed it there as well) in the Create() call:
WS_CHILD|WS_VISIBLE|WS_OVERLAPPEDWINDOW
This will help you see the window better 
|
|
|
|
|
Hi Mark:
Thanks for your response. Its working except the window is displaying without a caption. I'm getting only a rectangular frame with no caption and no way to move it around. I AM able to resize it though...
Mark
|
|
|
|
|
Even with the WS_OVERLAPPEDWINDOW style added?
Can you post the line(s) of code calling Create()?
Mark
|
|
|
|
|
Hi Mark:
Sure, here it is:
<br />
CRuntimeClass* pRTC;<br />
pRTC = RUNTIME_CLASS( COneView );<br />
pWindow = (CWnd *)pRTC->CreateObject( ) ;<br />
pWindow->Create( (LPCTSTR)m_strTypeOneView, <br />
TEXT("One Little View"), <br />
WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW, <br />
CRect(0, 0, 400, 300), this, 4567 );<br />
The "mstrTypeOneView" string contains the result returned from an earlier call to
AfxRegisterWndClass:
<br />
try<br />
{<br />
m_strTypeOneView = AfxRegisterWndClass(<br />
0,<br />
::LoadCursor(NULL, IDC_CROSS),<br />
(HBRUSH)reinterpret_cast<HBRUSH>(COLOR_BACKGROUND+1),<br />
::LoadIcon(NULL, IDI_APPLICATION));<br />
}<br />
catch (CResourceException* pEx)<br />
{<br />
AfxMessageBox(_T("Couldn't register class! (Already registered?)"));<br />
pEx->Delete();<br />
}<br />
I'm sure that the window registration is working because I have made alterations to the background color and the ICON and the window responds as expected.
Thanks,
Mark
|
|
|
|
|
Jethro63 wrote: The "mstrTypeOneView" string contains the result returned from an earlier call to
AfxRegisterWndClass:
How much earlier. It's not safe to store the returned pointer. It should be copied into your own
buffer (a CString is easiest).
The title bar isn't hidden under a toolbar is it?
If so, adjust the CRect top and left params.
Mark
|
|
|
|
|
Hi Mark:
"m_strTypeOneView" is a CString member of CMainFrame. The call to AfxRegisterWindClass is carried out in CMainFrame::OnCreate. The string returned is copied to "m_strTypeOneView" at that point. So, I believe that the returned class name is protected and not volatile.
I thought of your second point shortly after I sent my last reply to you and moved the upper-left coordinates of the window to 40,40. The window moves but does not change in appearance.
Mark
|
|
|
|
|
Jethro63 wrote: "m_strTypeOneView" is a CString member of CMainFrame. The call to AfxRegisterWindClass is carried out in CMainFrame::OnCreate. The string returned is copied to "m_strTypeOneView" at that point. So, I believe that the returned class name is protected and not volatile.
Cool sorry about that 
Jethro63 wrote: I thought of your second point shortly after I sent my last reply to you and moved the upper-left coordinates of the window to 40,40. The window moves but does not change in appearance.
Hmm That's just not cool! What if you create it using the default class (pass NULL for 1st param
of Create())? In my little MFC tester app (that I use to test code I post here) I have this:
pWnd->Create(NULL, _T("Window Name"), WS_CHILD|WS_VISIBLE|WS_OVERLAPPEDWINDOW,
CRect(50,50,300,200), this, 12345, NULL);
And it creates as intended - caption, system menu, max/minimize buttons, etc.
|
|
|
|
|
CRuntimeClass* pRTC;
pRTC = RUNTIME_CLASS( COneView );
pWindow = (CWnd *)pRTC->CreateObject( ) ;
I haven't looked at the MFC source code in a while but if COneView is CView-derived then maybe
some style flags are getting stripped off by MFC since views are meant to be used in a frame.
|
|
|
|
|
I think you might be right about that and I am going to quickly try to create a different view derived directly from CWnd.
Unfortunately, I have to go and put my son to bed now, so I will not be able to continue this thread this evening (unless much later).
Thanks again for your advice. I will let you know what happens next.
Mark
|
|
|
|
|
Jethro63 wrote: I am going to quickly try to create a different view derived directly from CWnd.
You may like to derive it from CView instead of CWnd.
|
|
|
|
|
Hi Prasad.
Thank you for your response.
The original window that I am having trouble creating was derived from CView. The suggestion that Mark Salsbery is making is that this could be the problem. I am going to try creating a window derived from CWnd, just to see what happens.
Cheers,
Mark
|
|
|
|
|
Jethro63 wrote: The suggestion that Mark Salsbery is making is that this could be the problem
Mark was refering to certain styles like WS_OVERLAPPEDWINDOW, would be inappropriate for view class.
|
|
|
|
|
Probably, this is last post this year. Its friday 11:37 PM here. Can continue on your problem on tuesday.
Happy new year.
|
|
|
|
|
Hi
I am using LDAP protocol (OpenLDAP) to speak to a MS active directory server. I have a DN of a user, and wants to retreive this users msExchMailboxGUID attribute which is (as far as I can read) a octal 16 byte array.
After a little research, I discovered a way to convert this value to a GUID that looks like this (string representation)
{A64B2D95-B730-4F2A-8F74-C6A37C11B7E5} (38 characters)
This works now on my computer which is an Intel based computer WinXP 32bit.
Which is what I am used to when I view GUID entries in MS SQL or .NET language.
I read somewhere that the GUID in memory is presented as
DWORD-WORD-WORD-BYTE BYTE-BYTE BYTE BYTE BYTE BYTE BYTE
I am no expert on the little-endian vs big-endian, but to obtain the guid string above, I had to start with byte [3], byte[2], byte[1] and byte[0], to get the first DWORD correct.
Is there anyone who has any advice on how to do this easier, or any knowledge if the first 4 bytes will always be in this order when I use LDAP protocol?
How can I in c++, convert a 4 byte "number" to an ascii string of 8 hex characters?
I did it by using _snprintf, and %02X for each byte, but I had to pick the bytes in the correct order out of the 16 byte array to get the right GUID.
I'm just posting to see if anyone has some advice or comments.
Thank you for reading.
|
|
|
|
|
Use StringFromCLSID() and CLSIDFromString() to convert between the two formats.
|
|
|
|
|
Hi again,
Thanks for the advice. I didn't get StringFromCLSID to work, as I didn't quite understand what to place into the function, but for my need, I could just copy the 16 octet bytes onto a GUID struct and call StringFromGUID2, and it worked.
Cheers.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
