|
The crux of the matter is that I want to display a popup menu, but the CMenu class has limitations making it unsuitable for my needs. Someone suggested that I use a Listbox instead of a Menu. From this I assumed that a Listbox could exist independently of a dialog box. Realizing that this is not the case makes everything fall into place.
As for not knowing what to do with a Listbox once it was created, in the context of my question I meant how to cause it to interact with the user. It seems to me that it could be attached at run time to any window, such as a FrameWnd, but perhaps it must be part of a dialog as you indicate.
As far as examples being everywhere, if what you say is true, there are no examples of doing what I wanted to do, as it can't be done. I don't need an example of creating a Listbox on a dialog, a monkey could figure that out without an example.
Yes, I am aware of handling ON_LBN_SELCHANGE, but I was hoping that there was a "modal" alternative.
Regards
|
|
|
|
|
gokings wrote:
...but the CMenu class has limitations making it unsuitable for my needs.
What is it that you are needing that a popup menu cannot provide? I'm just curious if there are some other options that can also be explored.
gokings wrote:
It seems to me that it could be attached at run time to any window, such as a FrameWnd, but perhaps it must be part of a dialog as you indicate.
I don't think a dialog is a requirement, but it is the most common.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
I was able to make a CMenu work, thank you.
The issue was that the entries to be placed in the menu were dynamically determined at run time. Having a method for each possible message didn't seem clean, and would have limited me to a maximum number of entries in the menu. cmk suggested that I use a method which handled a command range. Being an MFC neophyte, I was unaware of this possibility (and specifically that the command id was a parm to the method). This solved the problem. Thanks.
|
|
|
|
|
In context with your previous question and my reply ...
Probably the easiest way for you would be to derive a new control from CListBox that handles the various selection (or return, escape, ...) messages and have them set a variable to the selected value then destroy or hide the window.
Hiding/showing the window may be preferable if the list has many items, but requires a little more code to set up.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
I am having the problem to get the area of the frame window except the status bar, and docking bars if any.
Anil
|
|
|
|
|
Quick DUMB  question.
I know that an (int array[]) which was not given values for all elements
fills them with zeroes.
Say an int array[3] = {1, 4} would have array[0] = 1, array[1] = 4;
and array[2] = 0 (that is assigned by compiler).
A think thats how it is  !
Now if I got a (char array[]) is the empty element given a integer 0 or some char. And if I was to check for it would I use simple if (... == 0) or
if (... == '0').
Thanks in advance.
|
|
|
|
|
If you don't define all elements of the array then they will be undetermined and can be anything. It will be pure chance that they are 0.
If you want the array elements to default to NULL you need to NULL the array first.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
First of all, you cannot trust on compiler about filling all assigned memory with 0's. In VC++, it is initialized with garbage, so be sure to call a function to initialize array, for example, ZeroMemory or memset.
Now to your question. If you declare char array[] you have an array of bytes, so you have to compare against 0, not '0' (comparing with '0' is like comparing with 0x30)
Jaime
|
|
|
|
|
Well.
When an array is declared, its content is undefined unless you give it an initial value.
Initial values are assigned to an array by listing values withing {}. If your array is larger than your initialization list, the remaining elements will be assigned 0 by the compiler.
<br />
int a[4];
int b[4] = {1,2};
/Per
|
|
|
|
|
Also note that NULL and 0, '0' are NOT the same.
0 = a value
NULL is nothing, nada, ...
"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix
|
|
|
|
|
NULL is often defined as 0 or 0L. It is implementation specific.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
The only time the value is required to be zero is if the array is a global variable. Otherwise the value can't be predicted.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Also, not mentioned before, is that static arrays are always initialized with zero for each value. I wouldn't recommend making a variable static for that reason alone, but it is interesting to remember that for future reference.
If you have an array that is in a global function and you don't want it to be reallocated on the stack every time the function is called, you could make an array static. The values are all zero the first time the function executes and after that, the values will stay in memory. The initialization only takes place once, even though the function call could be made many times.
|
|
|
|
|
Someone on the VCF forums posted this, which I found a little strange, and was wondering if anyone here knew anything more:
"Also, when iterating an STL iterator, pre-increment (++it) should be preferred to post-increment (it++) as the latter creates a copy of the iterator."
Is this really true?
If I have code like:
vector<int> vec;
vector<int>::iterator it = vec.begin();
while ( it != vec.end() ) {
int& i = *it;
i = i * 45;
it ++;
}
Should I change it to:
vector<int> vec;
vector<int>::iterator it = vec.begin();
while ( it != vec.end() ) {
int& i = *it;
i = i * 45;
++ it;
}
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
Yes this is true. Similarly with the pre and post-decrement.
post-decrement makes a copy of the iterator.
Basically post-increment and post-decrement move the itterator by one position (forwards or backwards) and return an unmoved copy.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
In addition to Antony's reply, I myself have gotten into the habit of using pre-increments as well, but as I recall from a previous post on this topic, you will only see any performance benefit (if at all), on complex structures. Basic data types such as integers, characters and possibly simple class structures may not improve the performance either way.
I Dream of Absolute Zero
|
|
|
|
|
Well, based on what Andrew Koenig says here[^], I would suggest you do this:
vector vec;
vector::iterator it = vec.begin();
while ( it != vec.end() )
{
int& i = *(it++);
i = i * 45;
}
This way you increment the iterator AND use the result of the post-increment in one step. 
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
That's a good example and I agree. I've always had a problem with those who say that you're going to get some huge benefit to using pre-increment. But I will admit, by default, I always think pre-increment first, but if a post increment allows me to combine two lines of code into one I'll do that. In the example, post increment is critical. If you did a pre increment in that example, the behavior would be totally wrong as the increment would occur before the multiplication!
It's such a crapshoot to try and figure out what the compiler is going to do for you with all of the advanced compiler options. Make your code work correctly, first and foremost and if your performance meters indicate problems you can always refactor a bit during testing.
Regards,
Shawn
|
|
|
|
|
In general it doesn't matter. But the problem is that you would have to know the implementation to be 100% sure.
Here is the p-code for a pre and post increment
post:
value v = ix;
ix = ix + 1;
return v;
pre:
ix = ix + 1;
return ix;
In 99.99% of the cases, the compiler isn't stupid and realizes it doesn't even need the return type and thus never even saves it. However, if your iterator is complex (something more than just a pointer), then the compiler might not be able to optimize away the extra constructor.
Get use to pre-increment. However, as someone pointed out, it isn't always the best thing either.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
When you use POD then its ok to use i++, but if you use objects that supports pre-increment its best to use ++i as this does not create a temporary copy while i++ does, like stl iterators are best suited to ++i.
|
|
|
|
|
|
That's OK! 
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
yingkou wrote:
I have made a mistaken
Yeah that happens sometimes. I made one back in 1987.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
Sorry to interupt you,it is said that two programs in different computer can communicate by named piped in the book of Programming Application For Windows,
can you tell me the details?
thanks a lot
|
|
|
|
|
yingkou wrote:
can you tell me the details?
Apart from the book, a good source is MSDN.
Also, Google can be a great help.
Bikram Singh
I believe we should all pay our tax with a smile. I tried - but they wanted cash.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
