Since you're using an MFC app, you should probably be using command update handlers to deal with enabling/disabling menu items. See Mike Dunn's C++ FAQ section 7.1[^] for more information.

"We are the knights who say Ni" (The Knights Who Say Ni)

Favourite: Guinness, Wychwood brewery's Hobgoblin (that's the best of a very good bunch from Wychwood), Owd Roger (a tad pricey though) Worst: Nasty flavourless lagers.

"We are the knights who say Ni" (The Knights Who Say Ni)

The sensible way to terminate a thread is to make it terminate itself - generally by setting some sort of flag to signal that the thread should terminate. In its simplest form, the code looks something like this:

//assumes your bTerminateFlag variable is defined elsewhere - you'd
//probably actually do this with some sort of class, and pass a pointer
//to the class instance to your thread function, but I'm keeping this simple
extern bool bTerminateFlag;

int YourThreadFunction(LPVOID pParam)
{
while (!bTerminateFlag)
{
do_something...
}
return exit_code;
}

And your function to terminate the thread would look something like this:

int TerminateWorkerThread(HANDLE hWorker)
{
bTerminateFlag = true;
if (WaitForSingleObject(hWorker, INFINITE)!=WAIT_OBJECT_0)
{
//an error has occurred
//handle it somehow
}
else
{
return GetExitCodeThread(hWorker);
}
}

This is all very simplified - you'd want proper error checking, you probably shouldn't use a global variable as the terminate flag, and you shouldn't really use WaitForSingleObject in a thread with a message loop. But the principle is there. There's generally very little reason to use TerminateThread, and it can lead to all sorts of problems when your thread is doing something worthwhile, and holding resources open, because the terminated thread doesn't get to do any cleanup.

"We are the knights who say Ni" (The Knights Who Say Ni)

Have you tried handling LVN_ITEMCHANGING instead, and returning FALSE to prevent the change (see MSDN for LVN_ITEMCHANGING). I haven't tried this myself, so I don't know if it works. Your other option is to keep track of the currently selected item in a member variable, and only processing the ItemChanged notification if it's trying to select a different item to the one you think is currently selected.

YourClass::OnItemChanged(NMHDR* pNMHDR, LRESULT* pResult)
{
NMLISTVIEW* pNMLV = reinterpret_cast(pNMHDR);
//assuming you're only interested in the new selection, so check
//whether the LVIS_SELECTED state is set
if (!(pNMLV->uNewState & LVIS_SELECTED)) return;

//Make sure m\_CurrentSelection is initialised in the constructor to
//an invalid value like -1, so that this works for the first selection.

//This checks that we're not just resetting the selection back to the 
//current one.
if (pNMLV->iItem == m\_CurrentSelection) return;

if (whatever\_condition\_your\_checking\_is\_okay)
{
    //allow the new selection
    m\_CurrentSelection = pNMLV->iItem;        
}
else
{
    //go back to the old selection
    m\_List.SetItemState(m\_CurrentSelection, LVIS\_SELECTED, LVIS\_SELECTED);
}

}

N.B. Untested code - it's just an example of what I mean.

"We are the knights who say Ni" (The Knights Who Say Ni)

SetItemState might well be triggering several OnItemChanged calls - especially if you're changing the selection, because it might (depends if you've got multi-select enabled) unselect one item before selecting the next. Anyway, whatever is going on, the easy solution is to set your flag before your call to SetItemState, and unset the flag when the call to SetItemState has returned:

::OnItemChanged(...) {
static bool flag = false;
if (flag) return;

...

if (some condition)
{
    flag = true; //lock-out OnItemChanged
    list1.SetItemState(...);
    flag = false; //re-enable OnItemChanged
}

...    

}

"We are the knights who say Ni" (The Knights Who Say Ni)

I'm afraid that the answer is that you can't do it. You can't contain any of the common dialogs in a property page, because they're implemented as modal dialogs, not modeless child dialogs. The 'select filename' button that launches a separate CFileDialog is your only option. (This question is answered in the "Visual C++/MFC Frequently Asked Questions" article by Stingray Software in the MSDN Library, title "How do I embed a common dialog in a property page?")

"We are the knights who say Ni" (The Knights Who Say Ni)

I think the problem is that m_hScroll isn't actually the scroll-bar that you see in the window. When you set the style (cs.style() in PreCreateWindow to WS_VSCROLL | WS_HSCROLL the window creates its own scrollbars, and you need to use the member functions of CWnd to access them. For example, to get and set the position of the horizontal scroll-bar

void CChildFrame::some_function(int sb_pos)
{
//Setting the horizontal scroll position
SetScrollPos(SB_HORZ, sb_pos, TRUE);
//Getting the horizontal scroll position
int current_pos = GetScrollPos(SB_HORZ);
ASSERT(current_pos==sb_pos);
}

You'll also need to change your OnCreate function:

int CChildFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
SetScrollRange(SB_HORZ, 0, 50,TRUE);
SetScrollPos(SB_HORZ, 0,TRUE);
}

And take out the m_hScroll from your window. Hope that helps (and I hope it's right too!)

"We are the knights who say Ni" (The Knights Who Say Ni)

If nobody could answer it the first time, nobody can answer it after 5 times, 50 times, or 500 times. The only thing posting it more often will achieve is making everybody here less likely to read any of your questions in the future. The only thing that might help us give you an answer is if you provide more information, not just repost the same thing. For example, which objects leak, what is the Create function a member of... Oh, and learn what the <pre> tag does, it'll make reading your code a lot easier for the rest of us, and that might also help you get an answer. I promise you that spamming the board won't.

"We are the knights who say Ni" (The Knights Who Say Ni)

bob_000 wrote:_

void CAD_mouthDlg::StopNote()
{
if(m_Key_Press == FALSE)
{
MidiOutMessage (hMidiOut, 0x00, 0x90, m_Note2,0) ;
}
else
{
}
}

_Well, one of your problems is that the MIDI note off message code is 0x80 (to 0x8F for different channels), not 0x90 (0x90 - 0x9F are note-on messages for channels 0-15)). As you probably know, MIDI uses a Note On message to start a note and a Note Off message to stop it. [Edit] Oops - I just checked a MIDI spec, and a Note On message with velocity zero, which is what you're doing, should also work as a Note Off. Sorry![/Edit] However, you're still going to run into problems. Calling StopNote() immediately after PlayNote() (assuming m_Key_Press == FALSE) will result in a note too short for you to hear. But if m_Key_Press is TRUE (so the stop message doesn't get sent), the next time your timer triggers another note on will be sent (maybe with the same pitch) without you having sent a stop message. You might get the same note played again, which will sound wierd, or the previous note might stop - it kinda depends on the synth you're sending the MIDI messages to. Anyway, wind instruments are normally monophonic so you'd want to stop the previous note before starting the new one. But that's more an app-logic problem, and that all depends on what you're trying to do!

"We are the knights who say Ni" (The Knights Who Say Ni)

Try Sleep(time_in_milliseconds)

"We are the knights who say Ni" (The Knights Who Say Ni)

Ireland's kind of a long way from High Wycombe[^] for the amount of time normally needed to restore a Triumph! Although yours doesn't look like it's in particularly bad condition. Ever considered converting it into a Gitfire?

"We are the knights who say Ni" (The Knights Who Say Ni)

Me - a 2000 Ford Focus 1.6 (nice car, but not at the super-car levels that you guys are talking about!) However, my brother is driving a 1976 (I think) Triumph Spitfire Mk2 - in fact, it's the very Triumph Spitfire that is on the cover of this month's "Classic Car" magazine in the UK. It's his car, but it ain't him driving it on the cover of the magazine, just a pair of models (who really aren't very attractive for models...)

"We are the knights who say Ni" (The Knights Who Say Ni)

Oops! Sorry for the misunderstanding... Paul Watson wrote: Which is why I think maybe this Elton John one was a spoof. EJ would have known about Ali G and would either have refused or done a lot better in the interview as he would be forewarned and have his own ammo. I guess it depends when the interview was supposed to have been done, and when the first Ali G interviews were broadcast in the UK.

"We are the knights who say Ni" (The Knights Who Say Ni)

Ali G is as much a serious interviewer as he is black... I only caught the first stuff Ali G (real name Sacha Baron-Cohen I believe) did on UK TV (it was a sub-section of a comedy show - the '11 o'clock' show I think), but some of his interviews were fantastic. Nobody had heard of him so the interviewees all believed he was a real 'youf' presenter - the funniest bits were the lengths the victimsinterviewees would go to to pretend they were 'down with the kids'! Unfortunately after the first set of interviews he had to leave the country to find victims because everybody in the UK knew who he was.

"We are the knights who say Ni" (The Knights Who Say Ni)

If you're talking about the extra pages that Microsoft Office files show in the Explorer properties window (e.g. the Summary Page), that is achieved using a Property Set in an OLE Structured Storage file (otherwise known as a compound storage file) - it's a fairly complicated topic, so I suggest you read the following articles: OLE Property Sets Exposed (MSDN)[^] to find out what Property Sets are... And The Summary Information Property Set (MSDN)[^] to find out about the property set responsible for storing summary information. Hope that helps.

"We are the knights who say Ni" (The Knights Who Say Ni)

Not sure about Win2K, but it certainly backs up the registry in Win98.

"We are the knights who say Ni" (The Knights Who Say Ni)

WM_KILLFOCUS doesn't propagate up, but the button does send BN_KILLFOCUS to its parent window (if its BS_NOTIFY style is set) - so handling the BN_KILLFOCUS notification in the parent should work.

"We are the knights who say Ni" (The Knights Who Say Ni)

Just a guess, but according to the platform SDK, buttons must have the BS_NOTIFY style set if you want them to send BN_KILLFOCUS. Does your button have that style set?

"We are the knights who say Ni" (The Knights Who Say Ni)

If you use classwizard to insert a handler for HDN_BEGINTRACK in the list control, it incorrectly inserts a reflection handler, even though the notification is sent directly to the list control (ie not through the reflection mechanism). That's why the classwizard handler is marked =HDN_BEGINTRACK (= indicates a reflected notification). You need to replace the line ON_NOTIFY_REFLECT(HDN_ENDTRACK, OnEndtrack) in the message map with ON_NOTIFY(HDN_ENDTRACK, 0, OnEndtrack). (See the MSDN knowledge base article Q281155)

"We are the knights who say Ni" (The Knights Who Say Ni)

You need to handle the HDN_BEGINTRACK notification sent by the list's header control, and return TRUE to disable resizing. [edit]changed FALSE to TRUE above (whoops!)[/edit]

"We are the knights who say Ni" (The Knights Who Say Ni)