I've added several strings into a combobox, but I did see only selected item
when I clicked the dropdown button. (please see below sorce code. I only see
"A-" when I clicked the droupdown button)
Why i didn't see any other string such as "A+", "A", and etc?
Could you please advise me?
Thank you.
Daum
BOOL CGradeDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// TODO: Add extra init
CString str = _T("A+");
m_Grade.AddString( str );
str = _T("A");
m_Grade.AddString( str );
str = _T("A-");
m_Grade.AddString( str );
str = _T("B+");
m_Grade.AddString( str );
m_Grade.SetCurSel(2);
m_Grade.SetTopIndex(20);
return TRUE; // return TRUE unless you set the focus to a control
// EXCEPTION: OCX Property Pages should return FALSE
}
Daum,
The usual problem is that the combo list is only 1 item deep. In the
dialog editor click the combo's drop button and resize the drop
section height.
Dave
I'd bet if you scrolled using the arrow keys you'd see the items change (if
they are really assigned to the combo).
You may want to turn off sorting too (in the properties) if you want the
items to display in the order you add them.
Tom
"Daum" <Da...@discussions.microsoft.com> wrote in message
news:11C722CA-7CE5-4B07...@microsoft.com...
I couldn't find "drop section" in the property window for the combo box.
Thank you.
"Tom Serface" wrote:
> .
>
Tom
"Daum" <Da...@discussions.microsoft.com> wrote in message
news:177673A7-0EBB-4C7C...@microsoft.com...
Thank you very very much; I follow your advice and it works.
I though that I need to input a number for the drop down hight.
Thank you.
Daum
"Tom Serface" wrote:
> .
>
That's the way more modern designers work. But the Win32 combobox is a HWND
which has one height. That height is the height of the dropped down combo
box, not the edit control. So when you adjust the height of the dropped
down list in the resource editor ("resource editor" is the old name for
"designer") you are really specifying the height of the HWND in dialog
units. Since when MFC was designed everyone thought in terms of HWND, this
was a natural thing to do, but it's not natural now that we have modern
frameworks which preserve the true concepts of a combobox instead of forcing
the implementation details onto the app programmer.
-- David
I keep forgetting the good old days when I dealt with issues such as
this and felt great that I knew why this happened.
--
Ajay
No doubt we're more productive now but I don't like the way .NET is going.
WPF/WCF/Silverlight/Linq are plain weird. I'm sticking with WinForms just
because it is sane.
-- David
> No doubt we're more productive now but I don't like the way .NET is going.
> WPF/WCF/Silverlight/Linq are plain weird. I'm sticking with WinForms just
> because it is sane.
We are using WinForms but people want to go to WPF for reasons like,
its new. I dont know any more than what I was told by Microsoft in a
week's worth of training: For high frequency data display, its
performance is not going to be as good as WinForms, which is worse
than native. No comment about silverlight as I have no idea how it
fits in for us. On the other hand, Linq seems reasonable as it lets
you query your datastructures. Dont know much about WCF either.
--
Ajay
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
I did a 10 month contract with WPF, I was lucky, the client paid for my
training. :-) The best part of WPF is it lets you have more freedom to
design non-gray, more than one font type of UI's. It's as easy to use
gradients and such as it is not to, and I dare say the UI was very
attractive (for someone with no artistic skills) and highly usable. Instead
of .rc files, you specify forms using XAML. That's OK, in fact XAML is
highly expressive and is better than .rc files.
But also in XAML you define things like data binding, animations, etc. This
is where it is very confusing. The exact XML to specify exactly what you
want is not well documented, you just have to google for an example close
enough to what you want and hope something turns up. I had a really hard
time with a tree view data bound to an internal class, and I wanted to
specify certain data members to appear in the first level of the tree and
other data members to appear in the second level, etc. but I think I ended
up ditching the data binding and just populated the tree with the text I
wanted. It doesn't help when the API names are really long and have
esoteric meanings either - the API is very far removed from computer science
fundamentals (they are nowhere to be found) so I could not leverage my
background. This is what I meant by "weird".
The API is also immature. For example, I wanted to scroll my view in a
custom way when the scrollbar arrow is clicked. But I was not getting any
event for that. I filed a bug on Connect and (wonder of wonders) actually
did get some feedback that it was a bug and the workaround was very low
level involving some XAML hack, I think.
All in all, WPF is not something an MFC programmer would fall in love with
(at least I didn't). That's why I'm so disappointed in .NET 3 and later.
Instead of continuing the evolution of lovable improvements such as the
migration of assembler -> C -> C++ -> Frameworks like MFC -> Managed
productivity (C# and WinForms), we end up with something not lovable.
-- David
Tom
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:32f282f5-cc21-4c49...@o31g2000vbi.googlegroups.com...
>"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
>news:jd3dh5tgg7kt7k83o...@4ax.com...
>> I'm curious. What do *you* mean by "weird"? I'm asked about WPF often by
>> my clients, who
>> think they may want to move some of their simple-GUI-task development to
>> it ("because it's
>> new") and don't know if it is worth investing in the retraining. And all
>> I can say is "I
>> have no idea, I know very little about it".
>
>I did a 10 month contract with WPF, I was lucky, the client paid for my
>training. :-) The best part of WPF is it lets you have more freedom to
>design non-gray, more than one font type of UI's.
****
I've never found using multiple fonts a challenge in MFC...
****
>It's as easy to use
>gradients and such as it is not to, and I dare say the UI was very
>attractive (for someone with no artistic skills) and highly usable. Instead
>of .rc files, you specify forms using XAML. That's OK, in fact XAML is
>highly expressive and is better than .rc files.
>
>But also in XAML you define things like data binding, animations, etc. This
>is where it is very confusing. The exact XML to specify exactly what you
>want is not well documented, you just have to google for an example close
>enough to what you want and hope something turns up.
****
See, you are being totally unreasonable again! You expect this to be *documented*, and
that violates Microsoft's new policy of product development!
(Why pay expensive people to write documentation when the end users of the product can use
google to find the answers on someone else's blog?)
The documentation is probably being written by the person who is documenting Manifest
files, so we should see it Real Soon Now.
****
>I had a really hard
>time with a tree view data bound to an internal class, and I wanted to
>specify certain data members to appear in the first level of the tree and
>other data members to appear in the second level, etc. but I think I ended
>up ditching the data binding and just populated the tree with the text I
>wanted. It doesn't help when the API names are really long and have
>esoteric meanings either - the API is very far removed from computer science
>fundamentals (they are nowhere to be found) so I could not leverage my
>background. This is what I meant by "weird".
****
The people who invent these names are probably not programmers. And why call a list a
list when you can call it "an ordered container"? (This renaming of basic concepts is not
limited to Microsoft; it seems to be the latest academic rage, and consist of either
renamings which are precise but so estoteric only a set theorist can comprehend them, or
"user-friendly" for poor naive students and therefore completely unintelligible to anyone
who studied CS longer than five years ago)
****
>
>The API is also immature. For example, I wanted to scroll my view in a
>custom way when the scrollbar arrow is clicked. But I was not getting any
>event for that. I filed a bug on Connect and (wonder of wonders) actually
>did get some feedback that it was a bug and the workaround was very low
>level involving some XAML hack, I think.
****
Another philosophy, which came from VB: never expose an interface if it is useful. It
will only confuse the poor innocent programmer, who will wonder what can be done with it,
and horror of horrors, might even USE it! I once scrapped a VB3 program and rewrote it in
MFC in three days, because the next thing the programmer needed to do was trivial in MFC
and impossible in VB3, and my client was already three months behind schedule. Oh, and in
another four days, I added all the database support and processing (the original
programmer had created a cool VB interface after a year of programming, but it had nothing
behind it!)
****
>
>All in all, WPF is not something an MFC programmer would fall in love with
>(at least I didn't). That's why I'm so disappointed in .NET 3 and later.
>Instead of continuing the evolution of lovable improvements such as the
>migration of assembler -> C -> C++ -> Frameworks like MFC -> Managed
>productivity (C# and WinForms), we end up with something not lovable.
****
But cool.
joe
****
It's not hard but manual and tedious, it discourages experimentation and so
people end up with just one font or one font + bold. When it's as easy as
in HTML to change the font, you get much more variation.
> See, you are being totally unreasonable again! You expect this to be
> *documented*, and
> that violates Microsoft's new policy of product development!
>
> (Why pay expensive people to write documentation when the end users of the
> product can use
> google to find the answers on someone else's blog?)
>
> The documentation is probably being written by the person who is
> documenting Manifest
> files, so we should see it Real Soon Now.
> ****
> But cool.
Yup, I don't think the .NET 3+ people care what people over 40 think. The
C++ people giving us C++0x incorporating Boost don't care what people
writing shipping products think. Since I am over 40 and ship products for a
living, I embraced Qt which actually gives a damn. Also I embraced Visual
WebGui which gives a WinForms experience to developing web apps (making it
easy to port VB6 apps to the web.) Funny how there is a market reinventing
the familiar!
-- David
Your bias is showing :o)
Tom
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:ujsfh5to2aalbquqi...@4ax.com...
> On Wed, 2 Dec 2009 09:40:31 -0800, "David Ching"
> <d...@remove-this.dcsoft.com> wrote:
>
>>"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
> ****
****
Sad, really. We expect our major vendor (Microsoft) to listen to customer needs and
respond, but instead they seem to be focused on "cool experiences" and screw the customers
(us).
I'm still able to deliver products with MFC, but it is clear that the SP1 add-ons were not
tested very well, and not really well thought out. I'd rather have nothing than to buy
into a collection of classes that support only what some 22-year-old programmer thought I
might want, but (a) never asked us and (b) won't listen if we tell them.
I just have this memory that when I was 22, I was really paying attention to the needs of
the "customers" (the users of our compiler and my libraries). In fact, the Bliss language
was invented in 1969, so at that time, I was supporting two languages, three runtime
systems, two text editors, and starting to invent publication-from-database technology
(which matured by 1972 and was used by hundreds of local users), and the top of the
priority was listening to users!
Sadly, "cool" sells; "working" is an unfortunate concept that sort-of-is-supported.
Documentation *doesn't* sell product, so isn't an expense worth investing in.
joe
*****