|
How does the debugger find it?
If I put the line
CRITICAL_SECTION cs;
in my code, it's uninitialized. In a debug build at runtime, the entire struct is filled with
0xCC bytes. The only way I see to check for validity is initialize the struct to some values that
can never occur when the CS is initialized.
Maybe:
CRITICAL_SECTION cs;
memset(&cs, 0xFF, sizeof(CRITICAL_SECTION));
It's hard to "Leave the programming techniques" when this shouldn't be an issue if it's used
properly.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
imagine a multiprocessor machine. The object which has a critical section member is deleted just before another thread tries to lock it. And on the destructor of this object delete_critical_section is called. I know to have a global synchronisation object and to resolve this issue, but that sync object would cost me lot time. And would be my last choice.
|
|
|
|
|
Right. I'm following you.
No thread should be deleting the critical section, except for a thread that's in charge of the
lifetime of the critical section.
The problem here is an object shouldn't be accessible by a thread when it's being destructed or
after it's destructed.
If an object has its own CS for access that's fine.
In your scenario you also need synchronized access external from the object to control access to
the object's scope/lifetime.
Make sense?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
IMHO you are trying to solve the wrong problem.
xcavin wrote: The object which has a critical section member is deleted just before another thread tries to lock it use it.
Your problem appears to be in your management "use model" of that object. The fact that it has a critical section member is irrelevant or perhaps even a bad design on it's own.
|
|
|
|
|
led mike wrote: IMHO you are trying to solve the wrong problem.
True, I agree. But can't help, need to fix this way. Cannot afford to reduce the speed any more 
|
|
|
|
|
A critical section should be regarded as an opaque data structure. See here[^] for a description of what this means. Even if you did find a way to validate it you could only do so by ignoring the opaqueness: such techniques could break in a future OS or even after applying a service pack. David and Mark are giving you sound advice and my advice is to follow it.
Steve
|
|
|
|
|
See this[^] article does any help?
|
|
|
|
|
Quite frankly the only reason to call DeleteCriticalSection is if you're containing a critical section within some dynamically allocated object. In which case, the code that deletes that object should delete the critical section.
At process exit time, why waste the time to free the critical section? Windows is only going to throw away the whole address space anyway. Indeed, why free the contents of the heap?
All DeleteCriticalSection really does is close the handle to the event object that was allocated if a thread ever had to block on entering the critical section. Windows closes handles that were still open when a process exited.
|
|
|
|
|
Mike Dimmick wrote: At process exit time, why waste the time to free the critical section?
Process should never exist. But unfortuantely another thread is hung after trying to use this deleted hence uninitialized criticalsection !
|
|
|
|
|
This is need not be the case. Here's what critical sections currently look like:
typedef struct _RTL_CRITICAL_SECTION_DEBUG {
WORD Type;
WORD CreatorBackTraceIndex;
struct _RTL_CRITICAL_SECTION *CriticalSection;
LIST_ENTRY ProcessLocksList;
DWORD EntryCount;
DWORD ContentionCount;
DWORD Spare[ 2 ];
} RTL_CRITICAL_SECTION_DEBUG, *PRTL_CRITICAL_SECTION_DEBUG, RTL_RESOURCE_DEBUG, *PRTL_RESOURCE_DEBUG;
typedef struct _RTL_CRITICAL_SECTION {
PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
LONG LockCount;
LONG RecursionCount;
HANDLE OwningThread;
HANDLE LockSemaphore;
ULONG_PTR SpinCount;
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;
See here[^] for a description. In short all CRITICAL_SECTIONs are linked together link-list style and doing what you're suggesting may compromise the list and is thus likely to end in tears.
As much as possible you should just follow the rules and try not to make any assumptions.
Steve
|
|
|
|
|
I have to draw some real-world coordinates on a Device Context (screen only).
I have a "view" with a size of 500x500 pixels, to be able to decide that this 500x500 pixel actually represent a 20mx20m view, I have to use CDC::SetMapMode(MM_HIMETRIC) and CDC::SetViewportOrg(aPoint) to switch the mapping and the viewport origin ?
I have created a simple sample to test this out:
void CModelView::OnPaint()
{
CPaintDC dc(this);
CRect rect;
GetClientRect(rect);
CPoint origin;
origin.x = rect.left;
origin.y = rect.bottom;
dc.SetMapMode( MM_HIMETRIC );
dc.DPtoLP(&origin);
dc.SetViewportOrg(0, rect.Height());
dc.DPtoLP(&rect);
dc.FillRect( rect, &m_Brush);
dc.Rectangle(CRect( 100, 100, 200, 200 ));
}
Some questions:
I create my CModelView with a fixed size in pixels, but if I set the size to be square, my CModelView does not look like a square, I assume I have to compensate by the resolution of the screen ?
Is there a way to make the viewport a fixed size ? MSDN says that the SetViewPortExt and SetWindowExt are ignored for MM_HIMETRIC ? How do I make my "view" behave like it's 20m x 20m ? (This is the part I have not yet figured out).
Thanks in advanced if you have links to articles (here or elsewhere), or hints and tips
Max.
|
|
|
|
|
MM_ISOTROPIC
(Ensure your calculating your square in world coordinates to ensure a square is a square and a circle is a circle. Also, MM_ISOTROPIC will force your extents to preserve aspect ratio in case you deviate off course a bit. MM_ANISOTROPIC would allow distorting the output but I've never found it of much value.
|
|
|
|
|
I am using midiOutLongMsg() to send message to H/W through MIDI port and H/W is sending the acknowledgement through same port.
I am having doubt, the WindowProc() function I am using for getting acknowlegement from H/W is missing some message. Is there chance for WindowProc() missing MIDI message? If so, how to increase the precision?
Best Regards,
Suman
|
|
|
|
|
rp_suman wrote: and H/W is sending the acknowledgement through same port
WindowProcs don't get messages from a "port". Is there some driver that's getting the
acknowledgement and sending/posting a message to a window?
Are you using Windows Multimedia APIs??
Mark
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
I am not sure, but the USB driver may get the message and broadcast.
Application is getting the message MM_MIM_LONGDATA when acknowledgement comes from H/W.
The code for opening the MIDI port is:
MMRESULT mReturnCode=MMSYSERR_NOERROR; <br />
CWnd* pMainDialog = (CWnd*)AfxGetApp()->m_pMainWnd;<br />
HWND hWnd = pMainDialog->m_hWnd;<br />
mReturnCode = midiInOpen(&hdlMidiIn,uhInID,(DWORD)((LONG_PTR)hWnd),(DWORD)NULL,CALLBACK_WINDOW|MIDI_IO_STATUS);
My application is Dialog-based.
Best Regards,
Suman
|
|
|
|
|
You stated you're using a windowproc? How are you doing this with an MFC window?
Have you tried getting the message in your maindialog class using the message map?
ON_MESSAGE(MM_MIM_LONGDATA, OnMIMLongData)
...
LRESULT CMainDialog::OnMIMLongData(WPARAM wParam, LPARAM lParam)
{
MIDIHDR *pMIDIHdr = (MIDIHDR *)lParam;
...
return 0L;
}
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
Mark Salsbery wrote: You stated you're using a windowproc? How are you doing this with an MFC window?
The declaration is in Dialog's header file as follows:
virtual LRESULT WindowProc(UINT message, WPARAM wParam, LPARAM lParam);
And the implementation is in Dialog's cpp file as follows:
LRESULT CYSPController1Dlg::WindowProc(UINT message, WPARAM wParam, LPARAM lParam) <br />
{<br />
ubyt ubMidiData;<br />
switch( message ) {<br />
case MM_MIM_DATA: <br />
<br />
break;<br />
case MM_MIM_LONGDATA: <br />
ReceiveLongMsg( lParam ); <br />
break;<br />
}<br />
return CDialog::WindowProc(message, wParam, lParam); <br />
}<br />
Mark Salsbery wrote: Have you tried getting the message in your maindialog class using the message map?
Yes, I have also tried your suggestion but the result is same.
I confirmed the message is missing by running the USB monitoring software(Device Monitoring Studio by HHD), while printing the message from H/W in file by MFC application. the monitoring tool getting all the messages from H/W but the application is missing a single message. I am looking in the problem. Thanks for your great help.
Best Regards,
Suman
|
|
|
|
|
Functionality of WindowProc() and message map seems same, but is there any difference between them?
Best Regards,
Suman
|
|
|
|
|
Overriding the WindowProc method is fine but generally with MFC apps you'd use the message
map mechanism.
Either way, if your window isn't getting the message then the problem is elsewhere. 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
Hey guys, I have a form with two list boxes on it, both are inside a scroll box. I have multi select on, as I need the user to be able to click and drag the mouse to select multiple items without holding ctrl or shift. If I select any item in listbox #1, then select one in listbox #2, scroll down so neither are visible any longer. Now, if I click on anything that's not in the same listbox that was last clicked, (ie following the example above I click on an item in listbox #1 after scrolling down), the scroll box (which the listboxes are in) automatically scrolls all the way to the top, highlighting every item in that listbox from the one I clicked up to the item that is at the same mouse position as before scrolling. I believe it is a problem with losing focus, and I tried doing
On Mouse Down: ListBox->SetFocus(), but that didn't help (don't know if that's the right format). Any help would be appreciated, sorry if this is a really simple question. Thanks,
I found out the exact problem (I think)...now...just how to fix it :P The focus changes from one listbox to the next when it's clicked (both are within the scroll box). I need a way to have two separate focuses (foci?), one for each listbox. And when the scroll box moves all the way up, it's always a set amount : the number of times you clicked down (so...the number of vertical increments). So if I select something in one of the listboxes, then click one something in the other, then scroll down twice. After clicking on the first listbox, the scroll bar will move 2*increment of the scroll bar up and select all items within that range, in that listbox.
Alex
-- modified at 6:46 Tuesday 17th July, 2007
|
|
|
|
|
Hi to all,
How to create a (ActiveX) Control in VC++6 as collection of multiple MFC Controls?
I want to create a (ActiveX) Control that can have a 2 Static Control, 1 EditBox & multiple Buttons in it. And using that (ActiveX) Control, i want to create multiple instaces of it on Dialog.
|
|
|
|
|
The following MFC code calls my own OnInitDialog function which in turn sets focus to my dialog window's first control and then returns a boolean value of FALSE. However, the focus is NOT set and tabbing fails when my dialog page appears. WHY?????? Is there a problem with MFC?
The focus setting works when a dialog in initiated via the MFC "DoModal()" command.
Thank you for your assistance.
/////////////////////////////////////////////////////////////////////////////
// AfxDlgProc - does nothing since all messages are handled via AfxWndProc
INT_PTR CALLBACK AfxDlgProc(HWND hWnd, UINT message, WPARAM, LPARAM)
{
if (message == WM_INITDIALOG)
{
// special case for WM_INITDIALOG
CDialog* pDlg = DYNAMIC_DOWNCAST(CDialog, CWnd::FromHandlePermanent(hWnd));
if (pDlg != NULL)
return pDlg->OnInitDialog();
else
return 1;
}
return 0;
}
Michael A. Rinaldi
|
|
|
|
|
You do not need to post your question more than once. Please read the forum guidelines.
_____________________________________________
Flea Market! It's just like...it's just like...A MINI-MALL!
|
|
|
|
|
See here[^]. In short calling SetFocus should not be calling in dialogs: instead WM_NEXTDLGCTL should be used.
Steve
|
|
|
|
|
The following MFC code calls my own OnInitDialog function which in turn sets focus to my dialog window's first control and then returns a boolean value of FALSE. However, the focus is NOT set and tabbing fails when my dialog page appears. WHY?????? Is there a problem with MFC?
The focus setting works when a dialog in initiated via the MFC "DoModal()" command.
Thank you for your assistance.
/////////////////////////////////////////////////////////////////////////////
// AfxDlgProc - does nothing since all messages are handled via AfxWndProc
INT_PTR CALLBACK AfxDlgProc(HWND hWnd, UINT message, WPARAM, LPARAM)
{
if (message == WM_INITDIALOG)
{
// special case for WM_INITDIALOG
CDialog* pDlg = DYNAMIC_DOWNCAST(CDialog, CWnd::FromHandlePermanent(hWnd));
if (pDlg != NULL)
return pDlg->OnInitDialog();
else
return 1;
}
return 0;
}
Michael A. Rinaldi
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
