|
So add a handler. In the dialog editor double click the button, this will present you with a class::name() combo, normally you can accept it, but yiou can change the name if you like. CLick OK, then the code will be created for you (empty code, consisting of just the name and perhaps a return).
You then add the code you like to this handler to get it to do something interesting.
==============================
Nothing to say.
|
|
|
|
|
The text cannot be entered into CEdit control, no mouse cursor.
Just curious if this is normal in CDialog.
I just wanted to keep track of the dialog during the development, do not really need this.
Thanks for reading.
Vaclav
|
|
|
|
|
I'm not sure what you mean here, I have just tried this on a dialog of my own and have no problem adding to the text box after selecting the title bar.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
If I check the "Title bar" in dialog properties (resource) I cannot get the mouse pointer to show in the CEdit box. Hence I cannot enter any text into it.
The dialog is in tab control and the title bar is not highlited.
All of the buttons in the dialog still works normally.
I added tool tip into the CEdit control and it works with or without the title bar active.
|
|
|
|
|
Vaclav_Sal wrote: If I check the "Title bar" in dialog properties (resource)
I'm not sure I understand what you mean here; what has this to do with what happens when you run the dialog?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
This problem is using VC2010,a lthiugh I suspect the same issue would be present in VC6
I have an MDI view, within this view is a splitter window with 2 views. The pane on the right contains a propertysheet.
Some of the page of the sheet contain splitter windows, one such page has a 1 row by 3 columns, of this splitter panes 1 and 3 contain their own splitters of 2 rows by 1 column.
Visual representation:
+------++---------------------------------+
| pane ||+-------------------------------+|
| |||propertySheet ||
| |||+-----------------------------+||
| ||||PropertyPage |||
| ||||+---------------------------+|||
| ||||| Splitter ||||
| |||||+-------++--------++------+||||
| |||||| || || |||||
| |||||| Row1 || || Row1 |||||
| |||||| || || |||||
| |||||| || || |||||
| |||||+-------+| |+------+||||
| |||||| || || |||||
| |||||| Row2 || || Row2 |||||
| |||||| || || |||||
| |||||+-------++--------++------+||||
| ||||+---------------------------+|||
| |||+-----------------------------+||
| ||+-------------------------------+|
+------++---------------------------------+
If the main view is not maximized, dragging any of the internal splitters, everything re-sizes and works correctly.
If you resize the view by dragging one of its edges, everything but the panes lebelled row1/2 in the above diagram resize correctly. Row1/2 receive a WM_SIZE message, resize their controls, BUT those controls do not actually resize or redraw.
If you maximize the view, these panes do not receive a WM_SIZE message. A restore message, they do.
Clues:
I have a similar view layout for another document type. This one does not have the propertysheet, but does have the internal layout of the page within the propertysheet. All these views resize correctly on all events.
This leads me to beleive that the propertysheet/page is somehow killing the messages or locking the windows somehow (LockWindowUpdate), it could be down to parent/child window chains. It could even be down to the styles of the window(s) (or extended styles).
Basically I am looking for ideas/pointers in this area to try and get me out of the hole I am in.
Any suggestions or help appreciated.
If you vote me down, my score will only get lower
modified 2-Nov-11 13:50pm.
|
|
|
|
|
Well, after a day banging my head against the wall on this issue. I finally tracked down the issue.
Its not my code at all. Its the windows kernal.
Apparently, the stack used for nested windows is in the kernal memory and their is a max limit of the nesting depth at which a call to MoveWindow will fail to send a WM_SIZE message to the re-sized window.
To get around this my CSplitterWnd derived class (I already had one), just uses a PostMessage to itself to defer the call to RecalcLayout which does the MoveWindow calls. If I do this the windows get resized in stages down the window chain and they all work correctly as the kernal stack limit never gets hit.
If you vote me down, my score will only get lower
|
|
|
|
|
Mr. Dear friends,
First of all I wish good work come easy.
May I ask you a question about C + + builder?
The following questions in the writing programs in C + + or c + + builder can you help?
I am new software languages. Vey in C + + Builder C + + code, scripts, etc.. I do not know with no interest.
Dear friends help you if you would like to thank you now wish you good work.
question:
- The user's name, last name, phone, address, professional educational status, marital status of many of the sections in this form in a form designed for entering data.
- Also entered in our database, this data must be stored in the old records and see how a program will be reached if needed, this information is written? "
Best Regards
Thanks
Kenan
|
|
|
|
|
What exactly does this have to do with C++? Your question appears to be concerned with the layout of a form or the definition of a database table. Please try rewording your query.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Since I converted from VS6 to VS2010, I have found that lots of my dialog messages no longer work (e.g., BN_CLICKED, CBN_SELCHANGED).
I can Spy++ on the dialog and see the WM_COMMAND with the right notify code, by my dialogs handlers aren't getting the messages.
I expected some issues on upgrading, but this wasn't one of them!
Any suggestions on how to find out what is happening to my messages?
Cheers
|
|
|
|
|
You could try "Create New Project from Existing Code" if the conversion is problematic.
VC++ 10 is a lot better on conformance to the standard, so you may find the VC++ 6 source code no longer compiles even when you have a working project file (a good thing). Fixing such problems up is not generally too hard.
BTW Visual C++ 2010 Express does not have MFC. To compile MFC in Visual C++ 2010 Express read THIS.
|
|
|
|
|
I've done the conversion - it compiles, links and runs.
It just doesn't work.
|
|
|
|
|
I converted a dozen or so projects and never had this particular problem. So I'd check the basics.
1) does the BEGIN_MESSAGE_MAP() have the proper chain of derived and parent classes.
2) does the IDCs of the controls you are expecting map properly to the controls in the dialog you are displaying? I have seen things work by accident because older versions of Visual Studio allowed duplicate IDCs in separate dialogs but the code didn't expect that. Verify then against Resource.h.
3) are controls subclassed properly with DDX (if doing that)
There are a lot of things that need to be stitched together properly for the magic to work.
|
|
|
|
|
Chuck O'Toole wrote: 1) does the BEGIN_MESSAGE_MAP() have the proper chain of derived and parent
classes.
These are OK - or at least, they haven't changed.
Chuck O'Toole wrote: 2) does the IDCs of the controls you are expecting map properly to the controls
in the dialog you are displaying? I have seen things work by accident because
older versions of Visual Studio allowed duplicate IDCs in separate dialogs but
the code didn't expect that. Verify then against Resource.h.
I don't think this is it, I have no duplicate IDs.
Chuck O'Toole wrote: 3) are controls subclassed properly with DDX (if doing that)
I'm not doing this! 
This[^] exactly describes my symptoms, but doesn't give a solution (for me anyway).
The only other relevant thing is that I moved all my resources to a DLL (for reasons of internationalisation!). But they all still have the same IDs etc.
Thoughts (and thanks!)?
|
|
|
|
|
The suggestions on that forum page you referenced were pretty good. Especially the part about checking the actual .rc file to make sure all the symbols line up for the control in question.
It also suggested a place to put a breakpoint in the windows dispatch / search routine where it actually tries to match up your MESSAGE_MAP entry (IDC) with the IDC of the control that was clicked (RC file).
Lastly, and it's always a good suggestion, do a clean / complete rebuild to force a recompile of all the resource and source files to make sure everybody's using the same files. That may not have happened if you did a "convert in place" from the old to the new project.
Me, I'd do the full rebuild and the debug from the AFX dispatch to see where it's looking for MESSAGE_MAP entries and why it can't find yours.
|
|
|
|
|
Thanks for your help. I have found a way to fix it - but I wonder if this is a change required by VS2010, or if something deeper is wrong.
Lets say I'm on dialog A, which is a kind of dialog B. Currently, in A.cpp:
BEGIN_MESSAGE_MAP(A_Dlg, B_Dlg)
END_MESSAGE_MAP()
and in B.cpp:
BEGIN_MESSAGE_MAP(B_Dlg, C_Dlg)
ON_BN_CLICKED(IDC_MYBUTTON, OnMyButton)
END_MESSAGE_MAP()
This previously worked fine and allowed me to use IDC_MYBUTTON on all "B" dialogs to give me a generic B-dialog function.
If I add ON_BN_CLICKED(IDC_MYBUTTON, OnMyButton) to the A-dialog message map, the routing works. But why is this necessary? I added the function to the "B" base class so I WOULDN'T have to do this sort of thing.
|
|
|
|
|
I certainly don't do it that way. But if you think of it, if the button is in the "A" dialog, then the MESSAGE_MAP for "A" should be the place for it. I don't think polymorphism applies to controls.
It may be accidental that the RTLs for the older VS didn't check "ownership" where the newer RTLs do. Might even have been a bugfix for someone complaining that what you relied on was, in fact, a bug deserving of a fix.
Anyway, you've got the root problem figured out.
|
|
|
|
|
The documentation on processing message maps seems to support your concept of "virtual action routines" passing from derived window to parent/base class. So, I'd verify your hierarchy is correct first, then ask Microsoft if it's broken but I wouldn't hold up my application for a fix.
http://msdn.microsoft.com/en-us/library/6kc2tzde(v=VS.100).aspx[^]
The first argument names the class to which the message map belongs. The second argument provides a connection with the immediate base class — CView here — so the framework can search its message map, too.
The message handlers provided in a base class are thus inherited by the derived class. This is very similar to normal virtual member functions without needing to make all handler member functions virtual.
If no handler is found in any of the base-class message maps, default processing of the message is performed. If the message is a command, the framework routes it to the next command target. If it is a standard Windows message, the message is passed to the appropriate default window procedure.
|
|
|
|
|
Yeah, I created a little test MFC app to check, and it works fine there! 
|
|
|
|
|
It gets stranger and stranger!
I was paraphrasing my code before, it's more like:
BEGIN_MESSAGE_MAP(B_Dlg, C_Dlg)
ON_BN_CLICKED(IDC_ONE, OnFunctionA)
ON_BN_CLICKED(IDC_TWO, OnFunctionA)
ON_BN_CLICKED(IDC_THREE, OnFunctionA)
ON_BN_CLICKED(IDC_FOUR, OnFunctionB)
ON_BN_CLICKED(IDC_FIVE, OnFunctionC)
END_MESSAGE_MAP()
The message map IS actually working, but only for the first entry in the map! If I change the order, I can change what works and what doesn't...
|
|
|
|
|
Check to make sure that the IDC_ numbers aren't messed up in the resource file. If they're somehow the same, that would cause this behavior you're seeing.
|
|
|
|
|
I'm not 100% sure but I strongly suspect this is caused by changes to the message map macros.
Check out BEGIN_MESSAGE_MAP etc. in:
C:\Program Files\Microsoft Visual Studio\VC98\MFC\Include\AFXWIN.H
and compare with:
C:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxwin.h
|
|
|
|
|
It just occurred to me that if they changed how the macros generate the map tables, there'd be corresponding changes to the RTL to support it. So make sure the project conversion didn't leave some old libraries that you link with. You might have an explicit link in the project that should be updated for VS2010. Since you have both installed (I assume), you wouldn't get link errors but you'd see runtime oddities.
|
|
|
|
|
You may need to change whats being passed in the message map macros:
ON_BN_CLICKED(IDC_MYBUTTON, OnMyButton)
would become:
ON_BN_CLICKED(IDC_MYBUTTON, &CYourClass::OnMyButton)
If you vote me down, my score will only get lower
|
|
|
|
|
Ok ages ago in my conversion process I was trying to get rid of all the:
warning C4407: cast between different pointer to member representations, compiler may generate incorrect code
warnings from my dialog code. I added /vmg /vmv and forgot about it.
This caused all my function pointers in the dialog message maps to be 16 bytes long instead of 4, breaking everything while complaining about nothing! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
