For those new to message boards please try to follow a few simple rules when posting your question.
Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
Keep the subject line brief, but descriptive. eg "File Serialization problem"
Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode HTML tags when pasting" checkbox before pasting anything inside the PRE block, and make sure "Ignore HTML tags in this message" check box is unchecked.
Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
Please do not post links to your question in one forum from another, unrelated forum (such as the lounge). It will be deleted.
Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
No advertising or soliciting.
We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
I have a custom rotary slider control inheriting from CSliderCtrl. Its own behaviour is fine, it displays as I want, responds to mouse dragging and rotates just as it should. Then I want to interact with it from its parent dialog and the problems start.
I had imagined that I would just have to trap the ON_VSCROLL message to obtain its value as it changes. (It is set up with Orientation: Vertical though I have tried Horizontal too.) I can't trap ON_VSCROLL or ON_HSCROLL with either setting. I have tried catching NM_RELEASEDCAPTURE and can't get that either. I have:
declared and defined in my dialog .h and .cpp files. They exist as temporary function stubs with a little junk code in there to just see whether I can hit breakpoints in the functions. None get hit.
In the dialog editor the wizard shows only four control events available for the control, NM_CUSTOMDRAW, NM_OUTOFMEMORY, NM_RELEASEDCAPTURE, NM_THEMECHANGED. I expected to see more than that! I would have thought at least I could have accessed ON_VSCROLL via the wizard though a standard CSliderCtrl shows the same four options.
I know sometimes these controls can be a little eccentric but I thought this would be pretty plain sailing. I've dug around and found a couple of suggestions that I'm not the only person to have this issue with a Custom slider but no one seems to have a solution, only to use ON_HSCROLL or ON_VSCROLL which I can't seem to do. This must be something very simple I am seeing wrong. Can anyone suggest what I am missing?
I found that Richard, MSDN is the first thing I go to. There is a wealth of stuff with examples (that actually are only part complete) in there. None of it seems to work!
From your link:
A slider control notifies its parent window of user actions by sending the parent WM_HSCROLL or WM_VSCROLL messages, depending on the orientation of the slider control. To handle these messages, add handlers for the WM_HSCROLL and WM_VSCROLL messages to the parent window. The OnHScroll and OnVScroll member functions will be passed a notification code, the position of the slider, and a pointer to the CSliderCtrl object.
It just seems to back up everything I have done so far. I am trying unsuccessfully to catch the ON_HSCROLL and ON_VSCROLL messages in the parent wiondow just as MS says. I know I can parse out the info once I have caught the message, it's getting the message to land that I can't do even though I seem to be doing exactly what they say.
Looking at CDialog, it does not look like it implements the OnXScroll methods, so one wonders whether it just ignores scroll messages. I'm not sure quite how to get round that (years since I did MFC), but in Win32 I would probably subclass the Dialog control and use my own message handler.
I seem to have at least found a way of doing what I want, even though it does not explain to me what I am really doing wrong here. I have defined a custom message and can send this on to the dialog from within the custom slider at an opportune point. I pass the ID and the value I want as its parameters. I can then catch the custom message in my dialog message handler just as I should be able to and process it from there.
I would still like to know why I can't get to grips with the ON_VSCROLL way of doing this as every link I find tells me I should be able to do this as the standard method. I take your point that CDialog doesn't seem to support OnXScroll, but it's a mystery as to why everyone seems to tell you that is the way to do it. Thanks for your time and efforts Richard, even though we still seem to have only half a picture it's greatly appreciated.
The linker message is just going to say no body for prototype function found.
The ".H" file contains a prototype header, however the ".c"/".cpp" file contains no body code for that prototype.
So the compiler will basically see a forward declaration of a prototype which it will connect but when it gets passed to the linker it can't match the forward declaration to a code body and so it will report that accordingly.
The MSDN blog describes the problem they forgot to cull the prototype header before they got locked for compiler release.
I am using CCriticalSection and CSingleLock for synchronization purpose.
Is there a mechanism to test the synchronization object to know whether it is locked from another thread?
That is, I don't want to enter the lock, but just want to know whether the synchronization object is locked or not without blocking my code.
MFC is weird in a number of areas it isn't equivalent to the WIN32 API in a great many respects.
You have run across this a number of times with things like it is a singular thread, it's modal dialogs are in fact not WIN32 modal in MFC they become modal via the message loop. You seem to have identified MFC static text has got some different behaviour as well.
The thing about SS_OWNERDRAW on a true Win32 static class is you don't override it on the static itself but rather the dialog owner is sent the WM_DRAWITEM message and it is expected to handle it for the static class
By using the SS_OWNERDRAW style, an application can take responsibility for painting a static control. The parent window of an owner-drawn static control (its owner) receives a WM_DRAWITEM message whenever the static control needs to be painted. The message includes a pointer to a DRAWITEMSTRUCT structure that contains information that the owner window uses when drawing the control.
My biggest reason for not ever using MFC is that you can't mix pure Win32 code with MFC easily and reliably. The newer WPF framework allows Win32 Interoperation with only a limited few restrictions. For example in your case it would have been nice to have just written a nice pure Win32 dialog code to do what you want but MFC can't call a native Win32 dialog process because it has its own message pump loop and it's dialogs aren't really modal.
If you want to look at the message pump which is very MFC specific goto CWnd::RunModalLoop function and you can see how it pumps messages into the framework via
If you are using MFC you need to ignore native Win32 it won't always work. Probably use it as a guide as how it might work if MFC not as how you should do it on MFC. From you prior answer it is also obvious MFC window frames aren't exactly like Win32 native frame either.
If your project isn't large I think you have now reached a level of understanding of Win32 you could dispense with the MFC framework and just have a pure Win32 application. You seem to spend more time fighting the framework than actually coding new stuff. So the question I would put to you would be what do you like about the MFC framework, what positives do you have.