|
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.
|
|
|
|
|
Thanks for reply. It just does not adds up. Both messages are posted on same button action, only the TVN_SELCHANGING comes up first. I'll try to use just TVN_SELCHANGED.
|
|
|
|
|
Vaclav_Sal wrote: It just does not adds up. Both messages are posted on same button action, only the TVN_SELCHANGING comes up first. I'll try to use just TVN_SELCHANGED.
Why do you say it does not add up? If you handle TVN_SELCHANGING you can prevent the selection change to take place. If you don't prevent it, you'll see both messages.
|
|
|
|
|
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.
--Mike--
Dunder-Mifflin, this is Pam
|
|
|
|
|
Using VC6 & MFC
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 ?
|
|
|
|
|
You can derive your own class from CEdit. Reflect the CtlColor notification using ON_WM_CTLCOLOR_REFLECT() and return a standard window brush in the reflected notification handler:
HBRUSH CEditReadOnly::CtlColor(CDC* pDC, UINT nCtlColor)
{
return GetSysColorBrush(COLOR_WINDOW);
}
This will be enough for default (white) back color and default (black) text color.
If you want some arbitrary color for the background see this[^] article.
Nuri Ismail
|
|
|
|
|
Neil Urquhart wrote: 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.
Hi,
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".
void CTestDlg::OnEnSetfocusEdit1()
{
::SetFocus(m_hWnd);
}
void CTestDlg::OnBnClickedSetText()
{
m_Edit.SetWindowText(_T("Sample text"));
}
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
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 ?
|
|
|
|
|
Try handling WM_CTLCOLOR[^] or WM_CTLCOLORSTATIC[^] (possible reflected) or maybe use rich-edit, i believe that doesn't change its background color even when it is read-only.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
hai everybody,
i am a beginer in VC++, any one please help me how to transfer a folder using socket programing in VC++ ....?
i'm waiting for your answer.....
thank u........ 
|
|
|
|
|
Hi,
Take a look at TransmitFile()[^] API.
The doc says this: This function uses the operating system's cache manager to retrieve the file data, and provides high-performance file data transfer over sockets.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
As a beginner, socket programming using VC++ is usually not recommended. There are way too many issues that will come up that you have not grasped yet. Why such an ambitious project?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
hi..
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):
/OUT:"./../../Production Releases/Phoenix32.exe" /INCREMENTAL /NOLOGO /LIBPATH:".\..\..\lib"
/LIBPATH:"..\..\sybase\lib" /MANIFEST /MANIFESTFILE:".\Release\Phoenix32.exe.intermediate.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /NODEFAULTLIB:"libc.lib" /NODEFAULTLIB:"msvcrt.lib"
/NODEFAULTLIB:"msvcprt.lib"
/DEF:".\PHOENIX.DEF" /DELAYLOAD:"OleAcc.dll" /PDB:".\Release/Phoenix32.pdb" /MAP:".\Release/Phoenix32.map"
/SUBSYSTEM:WINDOWS /DYNAMICBASE:NO /ERRORREPORT:PROMPT winmm.lib libsybdb.lib IEngine.lib fwfip.lib fwstruct.lib
fwpip.lib fwpfg.lib dbl32.lib dom32.lib csdlib32.lib csdfw32.lib csdxtra32.lib oldnames.lib version.lib
"..\..\dom\lib\dom32d.lib" "..\..\dbl\lib\dbl32d.lib" "..\..\lib\fwfipd.lib"
"..\..\csdfw\lib\csdfw32d.lib" "..\..\lib\iengined.lib" "..\..\lib\fwpipd.lib" "..\..\lib\fwstructd.lib"
"..\..\lib\fwpfgd.lib" "..\..\csdlib\debug\csdlib32d.lib" "..\..\csdxtra\lib\csdxtra32d.lib" DelayImp.lib
But in debug mode it is looking like this:
/OUT:"Debug/Phoenix32.exe" /INCREMENTAL /NOLOGO /LIBPATH:".\..\..\lib" /LIBPATH:"..\..\sybase\lib"
/MANIFEST /MANIFESTFILE:".\Debug\Phoenix32.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker'
uiAccess='false'" /NODEFAULTLIB:"libcd.lib" /NODEFAULTLIB:"msvcrtd.lib" /NODEFAULTLIB:"msvcprtd.lib"
/DEF:".\PHOENIX.DEF" /DELAYLOAD:"OleAcc.dll" /DEBUG /PDB:".\Debug/Phoenix32.pdb" /SUBSYSTEM:WINDOWS
/DYNAMICBASE:NO /ERRORREPORT:PROMPT winmm.lib libsybdb.lib IEngined.lib fwfipd.lib fwstructd.lib fwpipd.lib
fwpfgd.lib dbl32d.lib dom32d.lib csdlib32d.lib csdfw32d.lib csdxtra32d.lib oldnames.lib version.lib
"..\..\dom\lib\dom32d.lib""..\..\dbl\lib\dbl32d.lib" "..\..\csdfw\lib\csdfw32d.lib"
"..\..\csdlib\debug\csdlib32d.lib" "..\..\csdxtra\lib\csdxtra32d.lib" DelayImp.lib
But i have given every library through linker settings.......
can anybody suggest in this regard......
modified on Monday, September 21, 2009 11:05 AM
|
|
|
|
|
Vetukuri Raju wrote: .it is working properly in release
mode..but not in debug mode
Would you care to explain what is not working?
|
|
|
|
|
There is no "Release Mode" until you get it to work under the debugger. Take a look at this excellent article: Debug vs Release[^] which explains the subtleties involved.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: There is no "Release Mode" until you get it to work under the debugger.
I think he probably means Release Configuration within Visual Studio. Or do I misunderstand what you are saying?
|
|
|
|
|
Never mind.
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". 
|
|
|
|
|
I disagree. Debug configuration and debugger is a luxury not a necessity.
-Saurabh
|
|
|
|
|
Saurabh.Garg wrote: debugger is a luxury not a necessity.
Interesting opinion. However, I think that the debugger is a necessity, and not a luxury.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
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.
-Saurabh
|
|
|
|
|
Saurabh.Garg wrote: 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.
Yeah? I think that I'd do myself a favour and continue to think of the debugger to be an essential part of my day to day development.
Saurabh.Garg wrote: It just means that it will take longer (potentially) to find bugs in the code.
With 3000+ source files in a projects, I think that it would take "a bit" longer to locate bugs, leave alone fixing.
Saurabh.Garg wrote: In my opinion, we are just too much used to integrated debuggger.
Fair enough! Everyone is entitled to have an opinion. In my opinion, I need the debugger and I think that it plays a very crucial role in my daily development activities.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: In my opinion, I need the debugger and I think that it plays a very crucial role in my daily development activities.
Yes debugger is crucial in development and I am not saying that I dont use it. I completely agree with you.
What prompted me to this dicussion was your reply to OP about there is no release mode until program works in debug mode. That implies it is a bad practice to not use a debugger during development. I think it is perfectly fine to work in release mode and swtich to debugger only when a bug needs to be fixed.
-Saurabh
|
|
|
|
|
Saurabh.Garg wrote: I think it is perfectly fine to work in release mode and swtich to debugger only when a bug needs to be fixed.
Again, *you* think that.
I think that it is imperfect to start working right away in release mode. The debug mode means a lot (it does a lot of work for you) and several bugs will go unnoticed in the release mode, which the debug mode is capable of detecting.
It is assumed that you have fixed all the bugs and that you are heading to optimise the program now, when you start to build in release mode. Please read the Debug vs Release article I pointed out earlier; it explains everything in great detail.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
