C / C++ / MFC

CSpinButtonCtrl and WM_VSCROLL

17-Sep-07 10:40

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Re: MFC related problem

ddspliting18-Sep-07 6:59

ddspliting

18-Sep-07 6:59

Sorry!
I read tht a bit late! and my problem is solved now! thanxx to u David and to the codeproject! Really Nice Service! top that!
Smile | :)

Californian217-Sep-07 6:06

17-Sep-07 6:06

I have a CSpinButtonCtrl in a dialog box and want to check changes to its value only after the user releases the mouse button. It seems that the spin control sends WM_VSCROLL messages with SB_THUMBPOSITION set even before the user releases the mouse button. Can anyone tell me how to process only the final message, and not all the ones in between (I don't think WM_LBUTTONUP would do it, since I need to determine which control it came from, and that message doesn't seem to tell me that.)

Thanks!

Cool | :cool:

David Crow17-Sep-07 6:51

17-Sep-07 6:51

Californian2 wrote:
...(I don't think WM_LBUTTONUP would do it, since I need to determine which control it came from, and that message doesn't seem to tell me that.)

How are you verifying this?

"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

Californian217-Sep-07 7:10

17-Sep-07 7:10

I have an OnVScroll handler in my dialog box procedure which checks whether nSBCode equals SB_THUMBPOSITION, and the part of the code that should only run if SB_THUMBPOSITION is set is being run before the mouse button is released.

OMG | :OMG:

David Crow17-Sep-07 7:22

17-Sep-07 7:22

Californian2 wrote:
I have an OnVScroll handler in my dialog box procedure...

And the third parameter of that override is (a pointer to) the control you are after.

"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

Californian217-Sep-07 8:08

17-Sep-07 8:08

You got mixed up! Laugh | :laugh:

I didn't ask how to find out which control sent the message. I asked how to process spin control messages only after the mouse button is released, and not for every WM_VSCROLL message!

Smile | :)

David Crow17-Sep-07 8:14

17-Sep-07 8:14

Californian2 wrote:
I didn't ask how to find out which control sent the message.

Actually, you did:

"I need to determine which control it came from..."

Californian2 wrote:
I asked how to process spin control messages only after the mouse button is released, and not for every WM_VSCROLL message!

Check out the difference between SB_THUMBPOSITION and SB_THUMBTRACK.

"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

Californian217-Sep-07 8:41

17-Sep-07 8:41

Look, here's my original question again:

I have a CSpinButtonCtrl in a dialog box and want to check changes to its value only after the user releases the mouse button. It seems that the spin control sends WM_VSCROLL messages with SB_THUMBPOSITION set even before the user releases the mouse button. Can anyone tell me how to process only the final message, and not all the ones in between (I don't think WM_LBUTTONUP would do it, since I need to determine which control it came from, and that message doesn't seem to tell me that.)

---------

What I said was that WM_LBUTTONUP was not the answer to my problem because I'm using information (given to me through OnVScroll) about which control sent me the message.

I want to know how to process a change to a value in a spin control only after the user releases the mouse button.

I already know the difference between SB_THUMBPOSITION and SB_THUMBTRACK. The use of SB_THUMBTRACK would be decidedly unhelpful. If you don't know the answer to my question, don't waste my time by pretending I asked some other, obviously stupid, question.

Poke tongue | ;-P

David Crow17-Sep-07 10:03

17-Sep-07 10:03

By deriving a class from CSpinButtonCtrl, you can easily handle the WM_LBUTTONUP message. No need to mess with the other SB_* notifications (unless you really want to).

"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

Californian217-Sep-07 13:04

17-Sep-07 13:04

Thanks, but see the answer from Mark Salsbery for the solution I was looking for.

Hmmm | :|

Mark Salsbery17-Sep-07 8:38

17-Sep-07 8:38

Californian2 wrote:
Can anyone tell me how to process only the final message, and not all the ones in between

What about the SB_ENDSCROLL scroll code?

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Californian217-Sep-07 8:55

17-Sep-07 8:55

Thanks so much, Mark! I somehow missed the SB_ENDSCROLL code in the documentation, but I tried it, and it is exactly what I needed!

Thank you, thank you, thank you!

Big Grin | :-D

Mark Salsbery17-Sep-07 9:10

VS2005 assertion when DoModal called from DLL

17-Sep-07 9:10

You're welcome, you're welcome, you're welcome!

Poke tongue | ;-P

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Russell Gantman17-Sep-07 5:57

17-Sep-07 5:57

I just upgraded my compiler from VS2003 to VS2005 SP1 and when I attempt to display
a modal dialog which is contained in a DLL, I get an assertion (in DEBUG only).

I have traced the problem to the following line of code :

#ifdef _DEBUG
	if ( AfxGetApp()->IsKindOf( RUNTIME_CLASS( COleControlModule ) ) )
	{
		TRACE(traceAppMsg, 0, "Warning: Creating dialog from within a COleControlModule application is not a supported scenario.\n");
	}
#endif

What I found is AfxGetApp() is returning NULL when I call it from my DLL, which causes the assertion in IsKindOf(...)
I also found that is is a "bug" with VS SP1.
Has anyone figured out how to make this call work.

BTW, I do make a call to "AFX_MANAGE_STATE(AfxGetStaticModuleState());" immediately after entering my DLL function.

Few other notes which might be of interest:
I am building MFC as a static lib (company requirement)
I am statically linking (not calling LoadLibrary) for the DLL

I skate to where the puck is going to be, not where it is. --Wayne Gretzky

Mark Salsbery17-Sep-07 8:48

17-Sep-07 8:48

Russell Gantman wrote:
I am building MFC as a static lib

So you're linking the DLL to the static MFC library and linking the app to the static MFC library, right?

In that case, you can't pass any MFC class (or derived) objects between the app
and the DLL.

Also, you need to make sure you initialize MFC for the DLL, and follow the rules
described here: Regular DLLs Statically Linked to MFC[^]

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Russell Gantman17-Sep-07 10:57

17-Sep-07 10:57

Mark Salsbery wrote:
So you're linking the DLL to the static MFC library and linking the app to the static MFC library, right?

That is correct

Mark Salsbery wrote:
In that case, you can't pass any MFC class (or derived) objects between the app
and the DLL.

I follow that rule also

Mark Salsbery wrote:
Also, you need to make sure you initialize MFC for the DLL, and follow the rules
described here: Regular DLLs Statically Linked to MFC[^]

The DLL I am linking to is an MFC DLL (MFC app statically linking to MFC DLL), do I need to follow the same rules (deriving from a CWinApp) in this case?

I have a small project where I was able to reproduce the issue I would be willing to share

I skate to where the puck is going to be, not where it is.
Wayne Gretzky

Mark Salsbery17-Sep-07 13:07

17-Sep-07 13:07

Russell Gantman wrote:
The DLL I am linking to is an MFC DLL (MFC app statically linking to MFC DLL), do I need to follow the same rules

Yes. There's no such thing as statically linking to a DLL.

DLLs are always linked dynamically, at runtime, so the same rules apply whether you use
early binding (ie an import library) or late binding (ie LoadLibrary()) to link an app to a DLL.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Russell Gantman18-Sep-07 9:00

18-Sep-07 9:00

Mark Salsbery wrote:
DLLs are always linked dynamically, at runtime, so the same rules apply whether you use
early binding (ie an import library) or late binding (ie LoadLibrary()) to link an app to a DLL.

I am doing early binding.
Could my problem be that I do not have a class which is derived from CWinApp?
I have a normal C++ class (as an interface to my exe) which then displaysthe dialog...
Here are the class declarations

As I stated before, this worked without a problem in VS2003, it just when I went to VS2005, I saw this problem

Here are the definition for the classes in my DLL
This class is the interface between my application and my dialogs:

<br />
#ifdef _DLGPWENTRY_<br />
#define CLASSSTATE __declspec(dllexport)<br />
#else<br />
#define CLASSSTATE __declspec(dllimport)<br />
#endif<br />
<br />
class CLASSSTATE CPasswordPrompt<br />
{<br />
   public:<br />
      CPasswordPrompt();<br />
      bool showDialog( int &lDialogReturn );<br />
};<br />

The dialog class (which is contained in the same DLL as the above class) is defined as follows:

<br />
class CPasswordPromptDlg : public CDialog<br />
{<br />
   DECLARE_DYNAMIC(CPasswordPromptDlg)<br />
<br />
public:<br />
   CPasswordPromptDlg(CWnd* pParent = NULL);   // standard constructor<br />
   virtual ~CPasswordPromptDlg();<br />
<br />
// Dialog Data<br />
   enum { IDD = IDD_PWPROMPT };<br />
<br />
protected:<br />
   virtual void DoDataExchange(CDataExchange* pDX);    // DDX/DDV support<br />
<br />
   DECLARE_MESSAGE_MAP()<br />
};<br />

From my main app (exe) I instantiate a CPasswordPrompt class and call showDialog()

It is in CPasswordPrompt::showDialog() where I instantiate my dialog class and call the
DoModal() after a call to: AFX_MANAGE_STATE(AfxGetStaticModuleState())

This is done to abstract the GUI work from the rest of execution,
now I can change how my GUIs are drawn by replacing the DLL and my code does not change.

Thank you for your help.

I skate to where the puck is going to be, not where it is.
Wayne Gretzky

Mark Salsbery18-Sep-07 9:34

18-Sep-07 9:34

Russell Gantman wrote:
Could my problem be that I do not have a class which is derived from CWinApp?

Yes, definitely and most likely Smile | :)

Since the DLL's UI is completely independent of the EXE's UI, there needs
to be a CWinApp object in the DLL.

Also note that since there's no message loop in the DLL, you need to
forward messages from the EXE's message loop as described in the docs
(linked to previously).

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Russell Gantman20-Sep-07 7:33

Migration of a VCPP program to Windows Vista

20-Sep-07 7:33

Mark Salsbery wrote:
Russell Gantman wrote:
Could my problem be that I do not have a class which is derived from CWinApp?

Yes, definitely and most likely

Thanks a lot for your help, that did it.

All I had to do was add another class derived from CWinApp and instantiate an object of that type and the assertion
went away. It really makes sense since there was no CWinApp object which means AfxGetApp has nothing to get Big Grin | :-D

I skate to where the puck is going to be, not where it is.
Wayne Gretzky

kchatterjee17-Sep-07 5:04

kchatterjee

17-Sep-07 5:04

Have any one of you migrate any VC++ (using MFC, ver 6.0) program from Windows 32 bit operating systems (XP, 2000, ME, 98SE) to Windows Vista? If so, can you please share some of the problems you have faced and there resolutions? (I heard that Vista has a memory issue if somebody uses malloc/calloc functions). Any additions to this list (with/without resolution)?

Re: Migration of a VCPP program to Windows Vista

David Crow17-Sep-07 5:50