|
Interesting,
Can you give us fragments of the Code that resolved it, so that we all may learn?
Regards,
Bram van Kampen
|
|
|
|
|
In stdafx.h:
#define IDM_SLIDER_CHANGE WM_USER+8
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:
ON_MESSAGE(IDM_SLIDER_CHANGE, OnSliderChange)
And handler function:
LRESULT CGm36NewPatchDlg::OnSliderChange(WPARAM wParam, LPARAM lParam)
{
switch (wParam)
{
case IDC_VOLUME:
{
break;
}
case IDC_GAIN:
{
break;
}
}
LRESULT lr = 0;
return lr;
}
There are still aspects to tidy up which may not be best coding practice but that works at the moment.
|
|
|
|
|
As you are getting right down and dirty and away from the MFC framework there are more possibilities inside the Win32 API.
If you look at the WM_PARENTNOTIFY message
WM_PARENTNOTIFY message (Windows)[^]
If you are compiling for windows > VISTA you can actually stop the message going to the dialog at all and directly handle it within the slider using the extended flag WS_EX_NOPARENTNOTIFY style. Useful for making owner draw (skinned) sliders.
It isn't clear to me if you are trying to get the slider to change something directly on it's control (owner draw skin) or if you are changing something in the dialog viewport so it may or may not be useful depending what you are doing.
I know for example that WinTweaks has its thumb part of it's scrollbar animated, I used to love the flame one
A basic example of owner draw in MFC is on the site and it isn't simple (How to skin CListCtrl including scrollbars and column headers[^])
In vino veritas
modified 29-Aug-16 5:20am.
|
|
|
|
|
Thanks Leon that's great advice. What I'm actually doing is to replace the linear slider appearance with a custom rotary knob within my CRotarySlider class (inheriting from CSliderCtrl and based on simple bitmaps for the background, knob and marker dot). As usual, the user grabs and drags to reposition the knob. That part works absolutely fine. I then needed to handle the change of knob position in the dialog class so was trying to catch the VSCROLL, which as you know I can't seem to do.
As I now have it, the calculations to do with conversion from mouse position to control value are taken care of in the CRotarySlider class itself and the finalised control value needs to be passed out to the Dialog class. As I said I have managed to do this with a custom message.
I have used the basic DDX setup in the past but it was so long ago I couldn't accurately remember the ins and outs of it but it does occur to me that I may be missing something glaringly obvious in that direction.
I'll certainly look into your suggestions, thanks for the heads up, they are greatly appreciated.
|
|
|
|
|
Okay so the thing you are trying to make is a Radial Control or sometimes called a radial gauge (although gauge tends to imply display only)
Can't you just push out the messages as standard scrollbar messages using PostMessage with the handle being your parent window. I mean in standard native Win32 I would do this if I wanted to FAKE a WM_VSCROLL or WM_HSCROLL lets assume your dial is handle is hwnd and a position pos.
HWND myParent = GetParent(hwnd);
PostMessage(myParent, WM_VSCROLL, MAKEWPARAM(SB_THUMBPOSITION, pos), (LPARAM)hwnd);
As we are faking it I wouldn't use SendMessage as it might go re-entrant (you post off to the dialog and it posts back and around in circles it would go).
I can't see how MFC could get that wrong as there message pump is still using PeekMessage from the standard windows queue.
In vino veritas
|
|
|
|
|
I'd use spy and verify the window hierarchy is as you expect. Perhaps the dialog is not a direct parent of the slider.
Steve
|
|
|
|
|
Agree with Steve.
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.
Regards, and Success,
Bram van Kampen
|
|
|
|
|
Sorry Steve,
The Other Message was intended for the Original person Asking the Question. Cannot Delete or Move It.
Sorry.
Bram van Kampen
|
|
|
|
|
I haven't used SetHighlight before. I tried and got unresolved external (it compiles OK but does not link).
I'm using VS2013, MFC in a static library, 32 bit, platform toolset VS2013 v120.
Any ideas?
|
|
|
|
|
What does the error message say?
|
|
|
|
|
Error 1 error LNK2019 : unresolved external symbol "public: void __thiscall CEdit::SetHighlight(int,int)"
(? SetHighlight@CEdit@@QAEXHH@Z) referenced in function
"protected: void __thiscall CReceivedMessageEdit::OnLButtonDblClk(unsigned int,class CPoint)"
(? OnLButtonDblClk@CReceivedMessageEdit@@IAEXIVCPoint@@@Z) C : \...\ReceivedMessageEdit.obj
Error 2 error LNK1120 : 1 unresolved externals C : \...\123.exe 1 1 123
|
|
|
|
|
I would expect it to just send a message to the edit control and therefore be implemented as an inline function when reading CEdit::SetHighlight[^]:
Quote: This method sends the EM_SETHILITE message, which is described in the Windows SDK.
But getting a linker error assumes that there is a declaration in a header file but no definition (implementation).
Following the link from the above quote is even more extraordinary:
Quote: EM_SETHILITE message
This message is not implemented.
A quick research brought up this:
What’s the deal with the EM_SETHILITE message? – The Old New Thing[^].
So it looks like that the SetHighlight function uses a not implemented feature and can't be use therefore.
|
|
|
|
|
Yes I found that after posting my reply. However, I would still like to see the linker message.
|
|
|
|
|
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.
In vino veritas
|
|
|
|
|
So the method is unavailable.
Any thoughts on how to make an edit box highlight part of its text in a different colour?
I thought I would have to write a custom paint routine to do this when I saw SetHighlight.
|
|
|
|
|
If it is just the current selection and using the default selection colour is appropriate, use the CEdit ES_NOHIDESEL style to show the selection even when the control does not has the focus.
Otherwise you may use a CRichEditCtrl.
|
|
|
|
|
Just override the draw method and put the text onto the DC in whatever colors you want depending on the state.
In vino veritas
|
|
|
|
|
Thanks for the suggestions; ES_NOHIDESEL looks like it will do what I need.
|
|
|
|
|
Hi,
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.
|
|
|
|
|
There would be a solution by getting the lock count from the undocumented <code>_RTL_CRITICAL_SECTION structure.
But there should be no reason to do that when using locks as intended (for short periods). For longer periods use other mechanisms like events.
|
|
|
|
|
Hello,
I am tryint to use CPaneDialog for implementing dockable Dialogs, based on a Dialog resource.
I started with the GestureDemo from Microsoft's MFC samples. There is an option dialog bases on CPaneDialog.
The demo works as it is.
I added to the dialog resource a ListControl.
Here is my problem. The Control is not displaying any content!
I tested the same dialog inside a standard CDialog. So actually my control works fine!
Is there anything additionally, I need to do in a CPaneDialog to interact with dialog controls?
Unfortunately I cannot find further source code samples.
Seems, nobody is using CPaneDialog.
Any hints? Thanks a lot!
|
|
|
|
|
How do you create the dialog?
How do you initialize the list control?
PS: sorry, I do not have the MFC samples installed on my PC, so I cannot test it myself!
|
|
|
|
|
Member 8534035 wrote:
Here is my problem. The Control is not displaying any content!
How are you adding content? Where?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
sorry for the late reply...I was absent a while!
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
CListCtrl m_ListCtrl;
- in OptionPane.cpp in DoDataExchange
DDX_Control(pDX, IDC_LIST_INPANE, m_ListCtrl);
4. Added a Handler for WM_INITDIALOG
LRESULT COptionsPane::HandleInitDialog(WPARAM wParam,LPARAM lParam)
{
UNREFERENCED_PARAMETER(wParam);
UNREFERENCED_PARAMETER(lParam);
m_ListCtrl.InsertColumn(0,_T("Col1"),LVCFMT_LEFT,50);
m_ListCtrl.InsertColumn(1,_T("Col2"),LVCFMT_LEFT,50);
int nItem;
nItem = m_ListCtrl.InsertItem(MAXINT,_T("Item1"));
that's quite all!
Now, when I am starting the program, I will get an assertion in HandleInitDialog at the first access of m_ListCtrl. It seems m_hWnd is not valid at this moment.
What I need to do additionally in comparison to CDialog (where I initialize the control in OnInitDialog())
Is CPaneDialog::HandleInitDialog the wrong place for initialization of controls?
|
|
|
|
|
5 years later I have the same problem! Have you found the solution?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
