|
DavidCrow wrote: BTW, posting the same question barely two hours later is considered bad etiquette.
What about 4 times in < 22 hours 
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I am using a List box in my appln... When new items are added the new items are added down. I want the scroll bars to be always posistioned next to the last item being added.. Can any one help me how to achieve this ...
|
|
|
|
|
You can easily accomplish this selecting the last added item either with (MFC) CListBox::SetCurSel or (plain Win32) LB_SETCURSEL message.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Thanks its working . . . but
can we just avoid that selection part . .. i jus dont want it to be selected..
is it possible to posistion the scroll bar alone...
|
|
|
|
|
Hi,
I am trying to display images for tree control nodes. My bmp file is having 256 colors. Problem is that at run time of the application, tree control is displaying blurred images. So I want to know is it not possible to display the tree control node images with 256 colors? If it is possible then how do that? Please help.
Regards,
Raj
|
|
|
|
|
Rajkumar Rachoti wrote: So I want to know is it not possible to display the tree control node images with 256 colors? If it is possible then how do that?
It should be possible.
How are you displaying the images?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Thanks a lot Mark for your time.
This my code to display the images:
m_imageList.Create(IDB_TREE_IMAGES,16,1, RGB(255, 255, 255));
m_navigationTree.SetImageList( m_imageList, TVSIL_NORMAL );
m_navigationTree.SetItemImage(m_hDisplay, 0, 0);
And IDB_TREE_IMAGES is a 256 colors bitmap.
Raj
|
|
|
|
|
I don't know why the images would be "blurred" unless the buttons aren't enabled.
Are the buttons enabled? Is bright white the "transparent" color for the bitmaps?
You could try this (although your code always works for me )...
Note I'm assuming 16x16 bitmaps in the imagelist -
CBitmap bitmap;
bitmap.LoadBitmap(IDB_TREE_IMAGES);
m_ToolBarImageList.Create(16, 16, ILC_COLOR8|ILC_MASK, numberofimages, numberofimagestogrowby);
m_ToolBarImageList.Add(&bitmap, RGB(0xFF,0xFF,0xFF));
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Thanks a lot Mark. That worked. Issue was with Image List which default takes 4 bits for color.
Raj
|
|
|
|
|
Thanks a lot Mark. That worked. Issue was with Image List which default takes 4 bits for color.
Raj
|
|
|
|
|
Cool! Good to know I was thinking all my bitmaps (except the 24-bit ones) were 8 bit, so I
thought it should work, but they are 4-bit 
Cheers,
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Hello board, I have programmed more than four years with MFC and I'm comfortable with it but I like to know should I consider programming in .Net? I specially want to know whether .Net is significantly faster than MFC or not and are there other advantages?
Thanks alot
|
|
|
|
|
How could it conceivably be faster, considering its a quasi-interpreted environment.
|
|
|
|
|
I don't believe .Net code is any faster than C++ one (I believe the contrary), albeit there is a strong controversy about. Anyway, for the average programmer, that is absolutely irrelevant. On the other hand, passing to .Net programming (on big projects and IMHO) may speed up noticeably coding activity and this usually matters.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
.Net Code is intrisically slower in almost everything except heap memory management. Because managed code uses the managed heap it can perform 10x faster than poorly written but otherwise similar C++/MFC code. However if speed is the issue you can ~always optimise the C++ code to end up faster than the best .Net equivalent.
The highly simplified version but basically sound version of things as far as I can tell is:-
It's a trade off between -
Moving to .Net makes poor-average MFC/C++ a lot - a bit faster.
Moving to .Net makes really good or really simple (i.e. very little heap usage) MFC/C++ code a bit slower.
You pays your money and you takes your choice
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Matthew Faithfull wrote: Net Code is intrisically slower in almost everything except heap memory management. Because managed code uses the managed heap it can perform 10x faster than poorly written but otherwise similar C++/MFC code.
Even that is questionable - CRT is much smarter than .NET marketing wants us to believe.
|
|
|
|
|
Sure it is smarter than the average bear but the CRT is also a catclysmic mess. Seven levels of function calls to do one allocation is already a high price to pay for a few bytes before you get into actual heap management. Granted it's not as bad in release code as the view you get in the debugger.
I wrote my own page memory manager that buy's pages off Win32 on a private heap and it beats the CRT by >10x in 1Gb of random <1MB size, allocations deleted in random order (Which is pretty much worst case for my implementation). <1s on an old Athlon 2100+. Doesn't suffer badly from fragmentation either  .
It needs a hell of a lot more refining and tidying up before I post it to CP though and the average memory footprint at runtime is a little larger than with the CRT. Making that tunable is one of the refinements needed.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Electronic75 wrote: I specially want to know whether .Net is significantly faster than MFC
.NET is inherently slower than C++ (MFC or not) and, even worse, memory footprint of a .NET application is much bigger than the one of a similar C++ application.
|
|
|
|
|
|
CPallini wrote: Oh, where are you when some of CP gurus claimed, against my opinion, that C# was faster then C++, basing substantially their assumptions on a benchmark result?
Oh I believe it is possible to write a benchmark where C# would outperform C++. For instance, just use iostrem library a lot on C++ side, and here you are
|
|
|
|
|
Nemanja Trifunovic wrote: Oh I believe it is possible to write a benchmark where C# would outperform C++
I agree. Of course the proposed benchmark claimed to be a bit more general (if I remember well stressed on object creation/destruction)... But, again, unfortunately I can't remember the web page (maybe some of mentioned CP gurus remembers better than me).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
With your years of experience with MFC, who cares which is faster. C++ is the only language that
let's you leverage both lower level unmanaged C++ code and the rich .NET framework. You can
easily use your existing MFC code and add code that uses features of the .NET framework.
What is "fast" anyway?
When I first started adding managed code to a big multimedia-rich application I did a full
managed build. There was no perceivable difference in speed, with multiple audio and video
tracks capturing and playing. Note that I personally mix managed and unmanaged code - that first
full-managed build was specifically to test the speed because I was sceptical .
Maybe there's a performance hit when you run the app the first time and it gets JIT compiled, but
I've never noticed that either since most of my first runs are in the debugger, which is slow
anyway.
I have no idea why I responded to this question, but thanks for asking - the wide variety of
answers is always entertaining
As with any language or framework - use the best tool that provides the best solution for your
needs.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Hi all,
I'm currently loading a circular image onto a CBitmapButton which has the outside area of the bitmap coloured the same as the dialog so that the user is fooled into thinking it's a circular button. However the problem I have is that the user can still click on the part of the button that is outside of the circular bitmap.
One solution I found was when the button is clicked, get the mouse position and if it is outside of the circle then ignore the click, however and this is the tricky part, the button has two bitmaps associated to it (down and up) and these get processed before the ON_BN_CLICK event so the bitmap changes temporarily.
Here's what I want to happen:
User presses left mouse button down
Check that mouse pos is within circle
If mouse is within circle
load 'down' bitmap
User releases left mouse button
if mouse is within circle
load 'up' bitmap
do some clever stuff :laugh:
if conditions are met
load 'selected' bitmap
Looking at the button methods the only suitable one is the ON_BN_CLICK event but not a WM_LBUTTONDOWN event like on the dialog.
Does anyone have any ideas on how to do this? This is getting developed within Studio 2003 and is a Dialog based MFC app.
cheers,
Andy
|
|
|
|
|
There are several code project articles on irregularly shaped buttons. In general, SetWindowRgn is the Win SDK call you use to give any window (for example a button) an irregular shape. SetWindowRgn is acessible somehow through MFC, or if you're using managed code, thorugh that as well, I presume.
|
|
|
|
|
cheers, you were right, all I needed was:
HRGN rgn ;
m_MyButton.GetClientRect ( &button_rect ) ;
rgn = CreateEllipticRgn( 0, 0,
button_rect.Width(), button_rect.Height() );
int ret_val = m_MyButton.SetWindowRgn(rgn, true);
Andy,
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
