|
Yup , I did the same with my Add() function but incremented the iterations up to 900000
and CString& - s ended in 100 seconds while CString -s in 190
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
|
|
|
|
|
Maybe the extra level of indirection when you are using references overrides the performance cost of passing it by value?
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
(Back in the old days...)
CString is reference counted object. This means that when you pass the CString to another routine by value, all it does is increment the ref count of the REAL data. This means that you don't allocate a new buffer for the CString.
As already shown, by using empty routines, const & is faster. But when you add back in all the other code, the extra dereference required to access the CString by reference might cost more than the cost of passing the string by value.
(Doh, what the previous post said.) :->
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
-- modified at 9:56 Friday 7th October, 2005
|
|
|
|
|
Hi,
I am having some problems with drawing a transparent bitmap into a CStatic derived object. I am drawing inside the OnPaint handler using Graphics ( GDI+ ) object. Since Its a transparent image, the first time when the control is drawn, I am getting the image properly. From next time onwards, when OnPaint in invoked, I am getting a black border for the image, which becomes thicker and thicker as the OnPaint in invoked ( I have to call Invalidate in Mouse over).
Graphic object is attached to a Bitmap object and thats Bitmap object is used to draw to the CDC using DrawImage function. when I saved that Bitmap to a file, the image looks alright. So I guess its the DC of the CStatic control which is crating the problem. Also this CStatic control is placed in CDialog, and whenever, the dialog is minimized and restored, the image will be rendered correctly.
I would appreciate any help on this behaviour.
Looking forward for an answer
Thanks
Jugs
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
Does any one know how to remove the menu border or at least create a flat one (without MFC)?
Thank veeeeeeeeeeery much !!!!!!!!
-- modified at 7:44 Friday 7th October, 2005
|
|
|
|
|
|
I did, but there are only mfc samples 
|
|
|
|
|
yes, sorry, i didn't see the point. put know this : MFC are just wrappers for Win32 functions (as Roger Allen explains in his introduction to menus[^]). so if you can find back which functions are use, you've got it...
see here[^] for Win32 related functions...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
-- modified at 8:00 Friday 7th October, 2005
|
|
|
|
|
Thank you for your help my friend, but I'am looking for a working sample. this is my fourth day on the subject and I searched all over the Internet but without any result 
|
|
|
|
|
I am working on MFC SDI Application. I hav attached two dialogs. Both hav one editbox control.
In these text boxes, file names are to be displayed. They can be edited in them as well as browsed using the browse button on the same dialog. Browse button is working.
I also want that, the second dialog, which has the editbox for destination file path , should show the path of the source file, after changing the file extension. how to do it???
Now, the problem is , it es showing "Enter Source File", even if, the source file is already entered.
Thanx for ur valuable time.
|
|
|
|
|
swaapu wrote:
I hav attached two dialogs.
How are the dialog boxes displayed? Are they both modeless, or is one modal and the other modeless?
swaapu wrote:
I also want that, the second dialog, which has the editbox for destination file path , should show the path of the source file, after changing the file extension. how to do it???
This question leaves a lot to the imagination. What is the "source file" and "file extension" of which you refer?
Explain a bit better as to how these two dialog boxes work in the overall scheme. Do they send information back and forth to each other?
swaapu wrote:
Now, the problem is , it es showing "Enter Source File", even if, the source file is already entered.
What is "it?"
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
hi!
I read ur reply. following points will clear ur doubts about my application:
Both the dialog boxes are modal.
Then you asked me: What is the "source file" and "file extension" of which you refer?
The extension of source file is .yak. It is an "ini file".
Then the name which has to be displayed in the second edit box will be the same but the extension is changed to ".config".
Then u said: "Explain a bit better as to how these two dialog boxes work in the overall scheme. Do they send information back and forth to each other?"
These dialog boxes don`t send inforation back and forth to each other. But, on clicking OK button in the first dialog box, the second one gets opened, and by default shows the same file name(as was entered in the first one) in the edit box , with the extension changed.
Thanx a lot
|
|
|
|
|
I am working on MFC SDI Application. I hav attached two dialogs. Both hav one editbox control.
In these text boxes, file names are to be displayed. They can be edited in them as well as browsed using the browse button on the same dialog. Browse button is working.
I also want that, the second dialog, which has the editbox for destination file path , should show the path of the source file, after changing the file extension. how to do it???
Now, the problem is , it es showing "Enter Source File", even if, the source file is already entered.
Thanx for ur valuable time.
|
|
|
|
|
Hi,
I have been struggling for some time with a problem experienced by a customer of our product. We have a reporting facility, which allows users to output information to a printer. We have found, on Windows 98, that when a block of text goes over a page, we are losing some text down the gap.
To print the text across pages we are using DrawTextEx, and getting the returned uiLengthDrawn to see how much fitted up to the bottom of a page, so we can continue the text from where we left off. This works perfectly on the screen, and also on NT/XP, but the uiLengthDrawn value is always wrong when going to any printer on Windows 98.
Has anyone else experienced this problem, and if so, do you know of any solution?
Paul.
P.S. It's my birthday today! 
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
-- modified at 7:26 Friday 7th October, 2005
|
|
|
|
|
![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif) ! Happy Birthday!
do you use MFC? If so, maybe you could use CDC::GetTextExtent(...) to know the size of the text to draw/print? To output text I generally use CDC::TextOut(...) and don't recall having any clipping problem with this method.
(the corresponding win32 api are ::GetTextExtentPoint32 and ::TextOut)
HTH,
K.
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil
Fold with us! ¤ flickr
|
|
|
|
|
Thanks! 
Using GetTextExtent/TextOut is all very well, but that doesn't tell me how much of my text will fit into a given rectangle. Once I've drawn my clipped text onto the bottom of my page, I need to know where in my text string I need to start drawing on the next page.
(I do use MFC BTW, but I don't think that's relevant.)
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
|
|
|
|
|
Paul S. Vickery wrote:
GetTextExtent/TextOut is all very well, but that doesn't tell me how much of my text will fit into a given rectangle
Yes, but not directly. GetTextExtent will give you the size required to draw the given text. Knowing where you begin to write the text, you should then be able to say if the text will go outside a given rectangle or not.
IMO? you should use it before drawing. Here's a sample how I use it:
CClientDC dc(this);
CFont *pFont = CFont::FromHandle((HFONT)::GetStockObject(DEFAULT_GUI_FONT));
CFont *pOldFont = dc.SelectObject(pFont);
CRect clientRect;
CSize textSize = dc.GetTextExtent(sTitle);
GetClientRect(&clientRect);
int iWidth = clientRect.Width() - 12;
CString strNewTitle(sTitle);
while(textSize.cx > iWidth){
sTitle = sTitle.Left(sTitle.GetLength() - 1);
strNewTitle = sTitle + _T("...");
textSize = dc.GetTextExtent(strNewTitle);
}
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil
Fold with us! ¤ flickr
|
|
|
|
|
Mmmm. That's what I was afraid I may have to resort to. It's not very efficient for huge chunks of text, which is why I didn't really want to do it this way in the first place (our reports are often very long, with large chunks of text), but I guess I can optimise it by splitting the string up and testing it using a binary method if it's over a certain length. I guess as it's only a problem on Windows 98, I'll just do it this way for that - maybe that'll teach them to use a real(-ish) OS!
Thanks for your time looking at this!
Paul.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
|
|
|
|
|
Yes, it is probably not very efficient, even if is it plausible it can be improved (using dichotomy seems good, making assumption on font width then on likely text length could perhaps also help).
Limiting this solution to Win98 users, by detecting the OS, could also limit the damage.
Paul S. Vickery wrote:
I guess as it's only a problem on Windows 98,
Is the problem not occuring on Win95? (I have to deal with this sh*tty OS, some of our customers still use this big bag of #$ù*#.
Also, the problem may come from the implementation of the printer driver on Win9x. Maybe an update of them, with a lot of luck...
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil
Fold with us! ¤ flickr
|
|
|
|
|
Just looked at source for CEditView printing, as suggested by Jack Squirrel in his reply[^], and it seems that MFC uses a similar method, by having a guess, and then adjusting the string until it best fits. They do that for all platforms (MFC doesn't use DrawTextEx anywhere as MFC pre-dates the function). Looks like that's what I'm going to have to do after all  , but at least our customer will be happy! 
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
-- modified at 5:05 Monday 10th October, 2005
|
|
|
|
|
Yep, avoiding DrawTextEx seems the good thing to do, jack's advice is the good one. I just have a look to CEditView printing too, very interesting. I learned something, there is an undocumented fucntion _AfxClipLine which may be useful sometimes.
Thanks for the feedback!
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil
Fold with us! ¤ flickr
|
|
|
|
|
There's code in the CEditView class that clips/fits text based on a rectangular boundary. Should be a primary function and a couple of helpers - just copy it to your project, tweak it if need be, and away you go.
"When you know you're going to eat crow, it's best to eat it while it's still warm." - Reader's Digest
|
|
|
|
|
Mmm. Just looked at that. It uses a method similar to the one I was avoiding  by guessing how many might fit, then decreasing/increasing the length of the string until it fits best. Oh well, looks like that's the way to go.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
|
|
|
|
|
how do i get the font name used by the system ,or more precisely i need to fill the LOGFONT structure how do i do.
thanx in advance
Farpointer
|
|
|
|
|
You can use the ::GetStockObject function.
If using MFC, the code would be
LOGFONT logFont;
CFont *pFont = CFont::FromHandle((HFONT)::GetStockObject(SYSTEM_FONT));
pFont->GetLogFont(&logFont);
HTH,
K.
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil
Fold with us! ¤ flickr
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
