|
A CListBox is a list of string items.
That having said, if you want to have check box buttons instead of string items, then the best way would be to derive a new class from the CListBox and override the DrawItem member function. This function is safe to use: by selecting a certain type of return value, you can tell Windows what type of drawing you did. For example, if draw it completely yourself, then windows doesn't need to draw it anymore. If you don't want to draw a particular cell, you can let Windows do it.
Here is a CodeProject link to help you get started: Michael Dunn's article[^]
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
I would poke around the Visual C++ section under comboboxes and listboxes someone has probably already written such a control.
Cheers 
The word of the day is legs, let's go back to my house and spread the word 
|
|
|
|
|
|
hi!,
i have put a CTreeCtrl in my view class,
i create it on my View::OnCreate and insert some items in
my View::OnInitialUpdate().
i would like to handle messages when i click on treeCtrl items
but how will achieve this?
should i subclass this treeCtrl or is there another way?
what will i do for the future controls user actions.(like Buttons, Edits...)?
thanks for ur help,,,
atilla.
just listening to you...
|
|
|
|
|
You can capture notification events (WM_NOTIFY) from the tree control in your parent window class's message map.
The implementation of the message map entry is as follows:
ON_NOTIFY( <notification message>, <control ID>, <member fxn> ) The above is a message-map entry in the parent window's message map which owns the tree control.
You then declare a member function member fxn that handles the notification message.
For more information about notifications and how they work, visit this link on the MSDN site.
For a list of notification messages sent by a tree control, see this site, again on the MSDN.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Hi !
The project I'm working on is being made with Visual Studio 6. I used to have my project on a specific location on my disk, and some weeks ago, I changed the location.
We are using CVS as the soruce control.
I have the following problem with some classes : if I try to add a new method, I get this error message :
D:\Work\sylvie\src\Utilities\JSUtility.cpp(579) : error C2039: 'applyTransformationToList' : is not a member of 'JSUtility'
c:\scripts\sylvie\src\utilities\jsutility.h(45) : see declaration of 'JSUtility'
As you can see, instead of looking at the header file of JSUtility in D:\Work\sylvie\src\Utilities, the compiler looks at c:\scripts\sylvie etc...
This is an old location. To get rid of this message, the only way I found is to do a 'rebuild all' of the project.
I tried to look in the .dsp and .dsw files if this old location was still written somewhere but didn't find anything !
Have you got an idea on what's going on and how I could solve this problem ?
Thanks for your help !
Jerome
|
|
|
|
|
This information is kept in precompiler header file (.pch). Rebuild All helps because it removes this file.
|
|
|
|
|
I'm not generally known as a stupid guy, but I'm really confused by this. I've been programming for 25+ years, but I've only recently tried to add C++ to my list of proficiencies, and I'm embarrassed to ask, but I'm going to anyway.
I see code that uses the . operator to reference member functions as often as I see the -> operator used for what appears to me to be the same purpose. What the heck is the difference? Can someone explain to me, without the utterly useless Microsoft technical babble, what the difference in usage is? I know it's trivial to you experts, but I have a (hopefully) temporary blind spot that is blocking me from progressing on my journey of discovery on the path of C++ enlightenment.
Please use small words appropriate to my small understanding for your reply... And, Thank you, for helping me to overcome this silly mental block. I'm usually good at spotting patterns, but this one has me stumped.
"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.
|
|
|
|
|
The . operator is for non-dynamic variables. The -> operator is used for pointer variables.
I think you know what a pointer is, don´t you?
"Have no fear, the saint is here!"
|
|
|
|
|
well the . and the -> actually do the same thing they server the same purpose but the difference is that the '.' (dot operator) is used when are dealing with a NORMAL object while the -> operator is used for a POINTER object like check this little snippet below
class foo
{
public :
int i;
};
when making an object of this class
foo myobject;
myobject.i = 0; //this is the normal way to access the i variable
now look at this object
foo *pobject; //now this is a pointer to object
pobject->i = 1; //this is way i will be accessed
|
|
|
|
|
ok
small words? you got em
// a header file
class A
{
public:
A();
~A();
void foo();
};
// a source file
int main(int, char**)
{
A a_object;
A* a_[ointer_to_the_object = new A();
a_object.foo();
a_pointer_to_the_object->foo();
return 0;
}
you see? when you deal with a pointer - you use -> operator......
debug - is my life style
|
|
|
|
|
Roger Wright wrote:
see code that uses the . operator to reference member functions as often as I see the -> operator used for what appears to me to be the same purpose. What the heck is the difference?
To the best of MY understanding
The member selection operator -> is used whenever the expression before is coupled with an indirection operator *
CMyObject myObj;
myObj.Test();
CMyObject* myObj;
myObj->Test();
You can acheive the same thing using
CMyObject myObj;
(*myObj).Test();
Basically when you use -> or *. are accessing members indirectly with a pointer.
The word of the day is legs, let's go back to my house and spread the word
|
|
|
|
|
Thank you for the only marginally comprehensible answer of the lot. Frankly, pointers drive me over the edge, and make me long for the resurgence of Pascal, the only language that's made any sense in the past 20 years or so. Indirection was handy in the ASM days, and I loved using it. But it seems an absurd layer of obscurity when applied to modern languages. I really hate that part of C++.
"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.
|
|
|
|
|
Well, perhaps I'll add my knowledge to the heap.
Consider the following: you have an object of some type. Let's name this type 'Roger', and let it have an attribute called 'Age' (No sarcasm intended !)
Now, if in your code, you created a static object, you would use Roger MyRoger declaration. This would create a static object for you. You would then access the member variable by using MyRoger.Age = 30, for example.
Let's take a step beyond and consider a pointer. See in front of yourself a 3D-space. In this space, you see the MyRoger-object standing at some point. Then, you create a pointer of type Roger using a declaration Roger* pToMyRoger = &MyRoger. Now, the pToMyRoger pointer points towards the MyRoger object, just like an extended finger.
A static object is aware of two things: what it is, and where it resides. A pointer to any object is aware of two things as well: where it resides, and what is to be found in that location.
For a more in-depth scenario, consider that your Roger-object (MyRoger) reserves a place for itself in memory (&MyRoger). If you issued MyRoger.Age, the compiler would get the address of MyRoger, move forwards from there to the Age variable, and retrieve it's contents. If you used a pointer, then the compiler would take the address you give to that pointer, and ASSUME that the object found from that address is the one specified by the type of the pointer (Roger*). It would then search for the Age variable again, and retrieve it.
Then to the term 'dereferencing'. When you have pointer to the object Roger (pToMyRoger), you can dereference it to an OBJECT of type Roger by using the asterisk (*) operator. For example, this declaration (*pToMyRoger).Age is the same thing as MyRoger.Age. As you might guess, *pToMyRoger equals to MyRoger hence leading us to the following conclusion: the dereferencing operator (*) can sometimes be named as the 'contents-of' operator. Thus, the contents of pToMyRoger (*pToMyRoger) equals to the object MyRoger (MyRoger). Does this make sense ?
In the conclusion, the '.' and the '->' operators behave similarly, but they are used in different contexts. For example, the following declarations do all the same things
MyRoger.Age = (*pToMyRoger).Age = pToMyRoger->Age = (&MyRoger)->Age
I am not sure about the final declaration, as I have never tested it. But, it should work according to the C++ language syntax, to which we will not dive right now 
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thanks! That helps clarify things quite a bit.
"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.
|
|
|
|
|
I just finished writting a bunch of verbage and an error occurd when I sent it 
And I don't think it sent...sux when that happens
Anyways...you've helped me more often then not during my times here at CP so any time I can help back i'm more then happy.
Cheers
The word of the day is legs, let's go back to my house and spread the word
|
|
|
|
|
The feelings you are having towards c++ are normal and understandable for a person trying to learn the language. Once you fully grasp the concepts and advantages (as well as disadvantages) of pointers you will view them in a much different light for sure.
|
|
|
|
|
I suppose so, though I haven't yet found any use for a pointer, nor any need to use one other than to comply with the declaration of some class or other.
"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.
|
|
|
|
|
Roger Wright wrote:
But it seems an absurd layer of obscurity when applied to modern languages. I really hate that part of C++.
Technically, pointers existed long before C++.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Not knowing the difference between . and -> does not make you a stupid guy
and Knowing the difference between . and -> does not make us any smarter either
you are OK ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
|
|
|
|
|
Hi,
Is anyone knowing if there is being code to do filter rules like the Outlook Express? Is a nicely way to building informations, and I would liking to do this.
Thanking you with flipping toes
|
|
|
|
|
hi everybody!
i was asking this question in "general" forum, but got no replays...
----
i've got an opportunity to upgrade my system to amd 64 3200+. it's preaty cheap and it would be stupid to miss it, but... i do developing under windows and linux and MOST clients of mine are the users of 32-bit architecture. in the specs of the cpu i found misterious phrase "supports both simulteniously 32 and 64 arc's" huh? so, my dilema is - miss or not miss good chance for the upgrade. What are the issues will i face after upgrade to 64 (with regard to developing under win .NET studio)? What are the consiquences for my end-users? I mean only windows users, if they have win2k (just for example!) and 32-bit cpu (pIII), and they try to run a binary that was built on my winXPpro 64-bit cpu, will they have problems?
please, share your opinion and experience, i really need it!
thanx
alex
debug - is my life style
|
|
|
|
|
It's been a while since I read my A+ book so forgive me if i'm wrong.
I believe 32 and 64 bit arc's are usually determined by the following factors:
1) Register size
2) Number of bits computer can transer per MOV instruction...your bus bandwidth I guess 
Anyways, most computers now are 32 bit because the internal registers are all 32 bit with I believe the exception of a few floating point registers which are 48 or 128 or something...
So you shouldn't have any backwards incompatiability issues when developing on a 64 bit arc becuz so long as your compiler compiles using common 32 bit instruction set it should run on your 64 bit machine or my 32 bit one. Kind of like how I could use 16 bit MOV instruction on my computer, but I could only move 16 bits at a time, whereas I could also use a 32 bit MOV instruction, but now be able to move 32 bits.
.NET uses an intermediate language...I can't remember what it's called... IL maybe...?
Anyways...the .NET interpreter would determine which actual instruction to send the processor (I believe thats the idea behind .NET) so you shouldn't get any exception becuz of a bad instruction when you compile apps using .NET.
Cheers
The word of the day is legs, let's go back to my house and spread the word
|
|
|
|
|
right, thanx
the scenario you've gave requires .NET being installed on the user's computer. or not?
debug - is my life style
|
|
|
|
|
If you write an app in .NET and give it to somebody on a Windows 98 machine, I believe they would have to download the .NET framework in order to run you apps on their machine. I remember having to download the win32 SDK on win 3.1 back in the day inorder to run some neat program, I don't image this situation is much different.
Cheers
The word of the day is legs, let's go back to my house and spread the word
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
