I am using static splitter frame (left CTreeCtrl right CTabCtrl) updating the right pane from the left. I am stumped with processing TVN_SELCHANGING and TVN_SELCHANGED. CTreeCtrl generates both notification messages after left mouse button click. I am not sure which one is correct to process in my case.
Could someone please point me to some kind a of code sample / tutorial on this.
So far all my searches were pretty dry and did not explain the purpose of two notification messages on same input.
Thanks for reading. Any help is as always appreciated.
In most cases, you want to process TVN_SELCHANGED - that's the notification you get after the selection is changed. The most common reason to implement TVN_SELCHANGING is when you want to control whether to allow the change of selection or not.
The purpose is that TVN_SELCHANGING is sent before the selection changes and the tree control updates its internal state. That's why the message is called changing. TVN_SELCHANGED is sent after the selection changes. Which one you need to handle depends entirely on what your code needs to do. In general, if all you need to do is "when the user selects something in the tree, do XYZ" then handle TVN_SELCHANGED.
Most MFC controls have a "Read Only" property so you can stop the user from making any changes to the value. However when you do this the control is displayed all in grey colours which makes it harder to read. Is there any easy way to make these controls "read only" but keep them obvious on screen, ie say in the default black and white ?
I am sure it can be done by overrding CEdit or similar and writing your own display code but this seems a bit to much like hard work.
Perhaps there is an easy was to make the controls read only which does'nt result in them becoming all grey ?
Most MFC controls have a "Read Only" property so you can stop the user from making any changes to the value. However when you do this the control is displayed all in grey colours which makes it harder to read. Is there any easy way to make these controls "read only" but keep them obvious on screen, ie say in the default black and white? I am sure it can be done by overrding CEdit or similar and writing your own display code but this seems a bit to much like hard work.
Nice question. Essentially, deriving your own class from CEdit would be the ideal way, but you say you don't want it. So, I have a silly hack for you.
Add a handler for EN_SETFOCUS and voluntarily give away the focus there. This way, the user won't be able to type anything into it or modify it. Because he just cannot set the focus. But, with a member variable for the control, you will be able to manipulate it from within your program, essentially making it "read only".
I like your strategy Rajesh as it seems to work at with one function connected to each control. Howewver my screen has about 25 controls on it of which some are read only and others are not. Also I have a mixture of Edit boxes, spin controls, tick boxes, buttons and radio buttons.
It looks like it will work for CEdit type controls but stuff like radio buttons don't seem to have such set focus handler functions available in the MFC Class Wizard. Is there a simialr way to do it with Radio Buttons ?
i am converting my project from vs-2003 to vs-2008..it is working properly in release
mode..but not in debug mode..i have checked all my settings...they are similar...
In the below two bolded commandline,i made the differences in italic to better understand
my settingd->linker->commandline looks like(in release mode):
I thought he wasn't able to get the program work under debug mode and it crashed in the release mode.
[Add] There's this thing of what does "not working" mean when the OP says it. With my previous reply, I was thinking that the code compiles and links, but resultant executable will crash. But, now I'm thinking if he isn't able to get past the linker or something like that. You'll never be able to guess all the "not working" posts correctly. [/Add]
It is a crappy thing, but it's life -^Carlo Pallini
No, if you read his OP he says that it works in "Release mode" (I think NDEBUG may be a better term), but crashes, or does not link, in DEBUG mode. However he has not really explained his problem very well.
Rajesh R Subramanian wrote:
You'll never be able to guess all the "not working" posts correctly.
I think a reasonable translation would be "I have no idea what I'm doing, urgent plz".
Something is necessary if removing it means that the system it is part of is no longer usable. Removing integrated debugger from Visual Studio does not mean we cannot program anymore, hence it is not necessary. It just means that it will take longer (potentially) to find bugs in the code. Just look at linux, there are no good integrated debugging enviornemnts (comparable to VS) but it hasnt stopped people from creating some really cool software.
In my opinion, we are just too much used to integrated debuggger.
Last Visit: 31-Dec-99 19:00 Last Update: 10-Feb-16 2:48