In the derived CRotarySlider class at a relevant point in my positioning calculation:
int iID = ::GetDlgCtrlID(::GetFocus());
GetParent()->SendMessage(IDM_SLIDER_CHANGE, iID, nPos);
In the Dialog class that the control is used in:
Added to the message map:
And handler function:
LRESULT CGm36NewPatchDlg::OnSliderChange(WPARAM wParam, LPARAM lParam)
// DO WHAT IS NEEDED
// DO WHAT IS NEEDED
// ADD MORE AS REQUIRED
LRESULT lr = 0;
There are still aspects to tidy up which may not be best coding practice but that works at the moment.
I use VS98 with MFC42, which is badly documented on advance features. However, it gets me trough most issues. Spy can show you which function dumps your message into the 'BitBin' underneath your Desk.
You are apparently of a generation that is un-aware of the Windows SDK.
In the SDK, messages were handled in the Actual Window Procedure, or, bounced to the Parent or Child Window Procedure.
This was reflected in that Unhandled Messages were referred to the 'DefaultWndProc(...)'
That Parent-Child relation is Similar To, but Incompatible with, the CPP Inheritance Model.
MFC Simplifies all this with thin but, powerful wrappers.
These Wrappers do as much of the hard work, as can be expected.
Now, when things go wrong, VS98 was provided with Powerful Tools.'Spy' is just One of them. Do Not forget, At One stage these compilers and Tools were used by Microsoft to develop code for the various Windows Versions.
In order to use MFC correctly, I suggest reading books about the Windows SDK.
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.
in the meantime I lost my first trail project and did it again, somehow differently
but it is still not working!
My steps in detail:
1. Using the original source code from VS Gesture Demo
2. Adding a ListControl to the IDD_OPTIONS Dialog resource (report style) ID: IDC_LIST_INPANE
3. doing the same what the framework would do automatically for a standard dialog:
- in OptionPane.h I added
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.