|
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_SECTION s 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
|
|
|
|
|
Showing the MFC code doesn't really help us
What are you doing in your derived class OnInitDialog? How are you setting focus to a control?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
Mark:
Sorry about that.
Here's my app's function that's called by the MFC code. I'm adding my own supplementary comments.
BOOL CSetupDlgMyApp::OnInitDialog()
{
CDialog::OnInitDialog();
UpdateMyNames(); // updates class object parameters
GetDlgItem(IDC_RENAME_ACCOUNT)->SetFocus(); // Here I'm trying to set my dialog page's
// focus to its first control
return FALSE; // return TRUE unless you set the focus to a control
// EXCEPTION: OCX Property Pages should return FALSE
}
Thank you for your assistance.
Michael A. Rinaldi
Michael A. Rinaldi
|
|
|
|
|
Maybe try this instead:
//GetDlgItem(IDC_RENAME_ACCOUNT)->SetFocus(); // Here I'm trying to set my dialog page's
GotoDlgCtrl(GetDlgItem(IDC_RENAME_ACCOUNT));
Mark
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
MRCres wrote: GetDlgItem(IDC_RENAME_ACCOUNT)->SetFocus(); // Here I'm trying to set my dialog page's
// focus to its first control
Is IDC_RENAME_ACCOUNT the first non-static control in the dialog's z-order?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Yes, it is.
Michael A. Rinaldi
|
|
|
|