|
Hi,
I was wondering if anyone else has seen this problem:
When I right click and open up a context menu in a CWnd sub-classed dialog, then go into a submenu my mouse cursor goes from the arrow to the hourglass and never reverts back to the arrow cursor until after I close the dialog box.
It doesn't seem to matter which way I create the menu (either through resources or purely by code) and I have tried overwritting the OnSetCursor function which always sets the mouse to the arrow.
I know that OnSetCursor is being called because outside of a menu the cursor is not an arrow.
Here is the sample of my code:
for cursor override:
BOOL CCMFrame::OnSetCursor(CWnd* pWnd, UINT nHitTest, UINT message)
{
if (message == 0)
{
HCURSOR hCursor = LoadCursor(NULL, IDC_ARROW);
SetCursor(hCursor);
return TRUE;
}
return CWnd::OnSetCursor(pWnd, nHitTest, message);
}
for menu creation:
CMenu mnuTop;
mnuTop.LoadMenu(IDR_POPUP_MENU);
CMenu* pPopup = mnuTop.GetSubMenu(0);
ASSERT_VALID(pPopup);
pPopup->TrackPopupMenu(TPM_RIGHTBUTTON |
TPM_LEFTALIGN, Point.x, Point.y, this, NULL);
Thank you for any insight into what could be causing this!!
Crystal
|
|
|
|
|
dWorkVan wrote:
When I right click and open up a context menu in a CWnd sub-classed dialog, then go into a submenu my mouse cursor goes from the arrow to the hourglass and never reverts back to the arrow cursor until after I close the dialog box.
Seems to mimic how Windows 2000 Explorer.exe and its Property dialog behaves - seems you are in good (or bad, depending on how you look at it) company.
Have you registered a cursor for your dialog? Do you handle all the WM_* messages as you should?
To give you a hint: The problem isn't with the manu code (no matter what it does) - the problem is with setting the right cursor when the focus returns to the dialog. If the hCursor is NULL, guess what it *can* set it (or *not* set it) to.
|
|
|
|
|
Thanks for the insight.
To answer your questions:
The cursor is registered for the dialog and its owner and I am almost positive that all the WM_* messages for both are handled correctly. Actually, the dialog the menu appears on isn't the owner of the menu, but both the owner of the menu and the dialog handle the WM_SETCURSOR messages which *should* cover the case when focus returns to the dialog.
So I am still at a loss of how to fix / overcome this problem.
|
|
|
|
|
How do I correct this error in VC++6.0?
"utils.c(125) : fatal error C1010: unexpected end of file while looking for precompiled header directive"
along with all other imported c files
I created a win32 console app "hello world" and inserted C files from
ftp://ftp.cs.brown.edu/pub/nlparser/nlparser.tar.gz
Thanks
Later,
JoeSox
www.humanaiproject.org
"Dream as if you'll live forever; live as if you'll die tomorrow."
- James Dean(ISTP)
|
|
|
|
|
You probably have either /Yu or /YX set. In Project Settings in VC 6.0, go to the C++ tab and select Precompiled Headers from the Category drop-down. Select the 'Not using precompiled headers' radio button and choose OK. It's best to do this for all project types - choose All Configurations in the Settings For drop-down before making the setting.
Precompiled headers are a way to collect common headers for your project in a single file that the compiler generates once; it can then reload a pre-compiled version of the common headers and speed up compiling each source file, because it only has to read and process the headers that source file includes that aren't in the PCH, and compile the code in the source file. You typically see that 'stdafx.cpp' takes ages to compile, then everything else takes fractions of a second on a fast machine.
The AppWizard assumes you want to do this and configures your project for /YX (automatic use of PCH) if it's an empty project, or with /Yc"stdafx.h" (create PCH through stdafx.h) for stdafx.cpp and /Yu"stdafx.h" (use PCH through stdafx.h) for all other source files.
When any of the /Y{cuX} options are specified, the compiler looks for #include "headername", where headername is the header specified as the argument. If no argument is specified, the default name is based on the source file name (/Yc) or is MSVC.PCH (/YX). The compiler also looks for #pragma hdrstop directives. If it doesn't find either in the source file, it generates a C1010 error.
/YX creates the precompiled header only if it doesn't already exist; in practice, this means that the first source file compiled is the one which will cause the PCH to be generated. It's usually better to specify /Yc on a file which only generates the PCH, and /Yu on everything else.
--
Mike Dimmick
|
|
|
|
|
thanks that worked. but now I have 345 errors to debug
am I not supposed to compile C files in MSC++6.0 
I guess the files were not meant to be converted to C++, darn I need Part of Speech tagger in C++. It will probably take me a while to figure out the errors. Thanks!![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Later,
JoeSox
www.humanaiproject.org
"Dream as if you'll live forever; live as if you'll die tomorrow."
- James Dean(ISTP)
|
|
|
|
|
If the file extension is .c, and the /Tp or /TP switch is not specified, the code should be compiled as C.
In the header files, ensure there's an extern "C" block around all the function declarations, so that the compiler doesn't decorate the names, or, rather, uses the C rules for name decoration. If this happens, the linker will complain that it can't find a funny name like ?a@@YAHD@Z, which is the decorated name for int __cdecl a(char).
This should allow your code to be written in C++, with the libraries you're using in C.
I've done this when porting a DOS application to Pocket PC, which has no console library, therefore I had to emulate a console myself. The emulation layer was written in C++, while the original application was written in, and was compiled as, C.
--
Mike Dimmick
|
|
|
|
|
|
thanks, I forgot about that page
Later,
JoeSox
www.humanaiproject.org
"Dream as if you'll live forever; live as if you'll die tomorrow."
- James Dean(ISTP)
|
|
|
|
|
1) Goto project->settings.
2) Under Settings For: Select the file or files that generate the error.
3) Select the C++ tab.
4) Select Catagory: Precompiled headers.
5) Check "Not using precompiled headers".
INTP
|
|
|
|
|
thanks, that worked
John R. Shaw wrote:
INTP
Later,
JoeSox
www.humanaiproject.org
"Dream as if you'll live forever; live as if you'll die tomorrow."
- James Dean(ISTP)
|
|
|
|
|
I'm relatively new to Visual C++, C++ altogether even. I know enough and have been going through some tutorials on code project. At the minute I'm working through an introduction to using dialogs and forms. Followed the instructions and made a pretty simple app, but every time I try to run it I get and error:
The ordinal 5076 could not be located in the dynamic link library MFC42D.DLL
I'm using the MFCAppWizard in Visual C++ 6.No matter what kind of program I try to run that uses a form or dialog, I keep getting an ordinal error. CAn anyone tell me what this is. I'm running VC++ on XP Pro.
The more we think we know, the less we understand
|
|
|
|
|
I just looked at ordinal 5076 and in MFC42.DLL it refers at CView::OnUpdate, while in MFC42D.DLL it refers at CWnd::WindowProc (ordinals in these two files are not supposed to match anyways). I really don't know why this is happening but what happens if you try to build and run the release version? I couldn't find CWnd::WindowProc in MFC42.DLL that's why I am asking.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
It's there, it's just at ordinal 6374 in the release build (look at MFC42.DEF in C:\Program Files\Microsoft Visual Studio\VC98\MFC\SRC\Intel [typically]).
Since the linking is done by ordinal, if you somehow had the wrong version under the wrong name, you'd get erroneous behaviour by the app, not an error like this.
MFC42.DLL is supposed to be compatible from version 4.2 of MFC right up to version 6.0 (i.e. new functions were added at the end, semantics are meant to be identical, and structure and class sizes remain the same).
I think you may have a corrupted copy of MFC42D.DLL, or possibly one from an older version of MFC (although the ordinal numbers should be the same). Try reinstalling it from the Visual Studio CDs, or reinstalling the service pack - you did apply Service Pack 5[^], didn't you?
My version of MFC42D.DLL (from SP5) is version 6.00.8665.0, dated 2000-07-15, size 929,844 bytes.
Sidenote: MFC uses ordinals rather than names because nearly 7000 decorated names, averaging about 40 characters long, would take up 280Kb (guesstimated) in the final DLL. Quite a hit for a DLL that's already nearly 1Mb in size. It would take the loader a bit longer to fix up the import table, too.
--
Mike Dimmick
|
|
|
|
|
Mike Dimmick wrote:
It's there, it's just at ordinal 6374 in the release build
You are right. I don't know why my search didn't return 6374.
Your reply makes perfect sense though.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Thanx Mike, found the problem. Didn't have Service Pack 5 lol. Everything's working fine now, plain sailing.
Later
The more knowledge we gain, the less we understand
|
|
|
|
|
It sounds like your app is not using the DLL you link with. What the version of the MFC42D.DLL your app is using?
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
|
 I was thinking the same thing and I came back to ask that question but you beat me.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
For some reason you don't have up to date dlls in your system directory. Download and install service pack 5 and all should be well.
John
|
|
|
|
|
MFC42D.DLL是安装VC++时的可选安装，所以你将光盘放入，重新安装它即可！
|
|
|
|
|
I have a program that utilizes SAPI 5.0 to handle voice recognition to
execute a set list of commands. The grammar is currently being handled by a
static XML grammar file but I would like the user to be able to specify the
terminology to execute each command.
This is the current XML file
--------------------------------------------------------------
<GRAMMAR LANGID="409">
<DEFINE>
<ID NAME="VID_LDblClk" VAL="14"/>
<ID NAME="VID_LDrag" VAL="15"/>
<ID NAME="VID_LSglClk" VAL="16"/>
<ID NAME="VID_RDblClk" VAL="17"/>
<ID NAME="VID_RDrag" VAL="18"/>
<ID NAME="VID_RSglClk" VAL="19"/>
<ID NAME="VID_ReleaseDrag" VAL="20"/>
<ID NAME="VID_CmdType" VAL="255"/>
<ID NAME="VID_Commands" VAL="257"/>
</DEFINE>
<RULE ID="VID_Commands" TOPLEVEL="ACTIVE">
<O>Please</O>
<RULEREF REFID="VID_CmdType" />
</RULE>
<RULE ID="VID_CmdType" >
<L PROPID="VID_CmdType">
<P VAL="VID_LDblClk">left double <O>click</O></P>
<P VAL="VID_LSglClk">left <O>single</O> click</P>
<P VAL="VID_LDrag">left drag</P>
<P VAL="VID_RDblClk">right double <O>click</O></P>
<P VAL="VID_RSglClk">right single <O>click</O></P>
<P VAL="VID_RDrag">right drag</P>
<P VAL="VID_ReleaseDrag">release drag</P>
</L>
</RULE>
</GRAMMAR>
--------------------------------------------------------------
Right now to execute a left double click the user must say "left double
click" but they might want to say "double left click" or anything else, so I
want to give them the ability to change the grammar while using the program.
Is this possible?
Thanks in advance,
~Logan
|
|
|
|
|
Has anyone attempted to develop a VST host? I'm keen to have ago for a granualar synthesis program i writing, but everyone I know has run in fear of attempting it.
If there's any brave soles out there who have given it a go with little or no success would you mind sharing your source with me? I guess if folks succeeded they probabley wouldn't want to share!
If I succeed (and that a big if) I'll do tutorial on here to "share the knowledge".
Ta.
Email:
boutatrain@yahoo.co.uk
|
|
|
|
|
Hi all...
First off, I'd like to thank all whom contribute to this board - it has been an extremely valuable resource for me - a non-programming expert.
I'm a mechanical engineer by trade but have written Visual C++ apps for quite some time; sometimes for fun, sometimes for timesaving. Right now, I'm developing an application that performs some extensive linkage analysis on motorcycle suspensions. As such, I'm using primarily "double" variables.
In the past, when I needed to display these values in my window, I could convert them to a string and write them to a text box and control their format. This time, however, I have simply set the on screen edit box variables as doubles and have direct relationships between my screen variables and my calculation variables to make screen updates and retrieving data from the screen easier/quicker.
However, now when I display the values on the screen, they're written out to some god-awful number of decimal places. Is there an easy way of limiting an edit box's number of decimal places when you do an UpdateData ?
Sorry that this is probably a very lame question, but your assistance is much appreciated.
-Chris
http://www.slideruleracing.com
|
|
|
|
|
In DoDataExchange(), look for the call to DDX_Text() which has the ID of the edit box you're entering. Replace with something like the following:
if ( pDX->m_bSaveAndValidate )
{
DDX_Text( pDX, IDC_EDIT1, m_flData )
<font color="green">
}
else
{
CString sRep;
<font color="green">
sRep.Format( _T( "%.3f" ), m_flData );
SetDlgItemText( IDC_EDIT1, sRep );
}Obviously it's not as tidy as simply calling DDX_Text.
You could add your own overload of DDX_Text if you're going to be doing this a lot. Look at the implementation in the MFC source code in DlgFloat.cpp for an example.
--
Mike Dimmick
|
|
|
|
|
I'd eliminate the use of UpdateData(). For each edit control, assign a CString member variable. When it comes time to update a control, do something like:
CString strSuspension;<br />
strSuspension.Format("%.3f", m_dSuspension1);<br />
m_edit.SetWindowText(strSuspension);
If you need to get the value from a control, use:
m_edit.GetWindowText(strSuspension);<br />
m_dSuspension1 = atof(strSuspension);
There are many ways to tackle this problem.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
